Skip to main content

Last Call Review of draft-ietf-nsis-tunnel-

Request Review of draft-ietf-nsis-tunnel
Requested revision No specific revision (document currently at 13)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2010-06-25
Requested 2010-06-10
Authors Sung-Hyuck Lee , Jong Bang , Charles Shen , Henning Schulzrinne
I-D last updated 2010-06-20
Completed reviews Secdir Last Call review of -?? by Yaron Sheffer
Secdir Telechat review of -?? by Yaron Sheffer
Assignment Reviewer Yaron Sheffer
State Completed
Review review-ietf-nsis-tunnel-secdir-lc-sheffer-2010-06-20
Completed 2010-06-20
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.

This draft discusses the problem of NSIS messages (particularly, QoS 

reservation flows) being encapsulated into various IP tunneling 

protocols, which prevent the correct QoS setup from being performed. The 

draft proposes a solution for NSIS tunnel-aware tunnel endpoints, which 

basically adds an NSIS signaling flow between the tunnel endpoints, but 

outside of the tunnel.


The draft presents the problem, and the solution, reasonably well.

The draft goes for the "no new security issues" approach. I think this 

is incorrect, and in fact a number of security issues should be analyzed 

and possibly resolved. In addition, as a complete outsider to NSIS, I 

have identified one major unspecified piece, leading me to believe that 

the draft has not had enough review.


The main security issue is that the draft fails to consider 

security-oriented tunnels. IPsec tunnels (and the commonly used 

GRE-over-IPsec) provide security services: normally encryption and 

integrity protection with ESP, less commonly integrity-protection only 

with AH, ESP with null encryption, or the new WESP (RFC 5840). The 

proposed solution raises at least three major security issues related to 

these tunnels:

1. A so-called covert channel that results from NSIS flows in the 

protected networks directly triggering NSIS protocol exchanges in an 

unprotected network (i.e. between the tunnel endpoints). Please see 

Appendix B.1 of draft-ietf-tsvwg-ecn-tunnel-08 for treatment of a 

similar issue.

2. A more serious interaction in the other direction: unprotected NSIS 

flows outside the tunnel interact with NSIS flows in the protected 

networks and inside the tunnel, and so, an attacker in the unprotected 

network can possibly influence QoS behavior in protected networks.

3. A practical result of (2) is that the NSIS protocol stack on the 

tunnel endpoint is now exposed to unprotected networks and therefore 

suddenly becomes security-critical.


The draft defines extra UDP encapsulation in some cases ("the tunnel 

entry-point inserts an additional UDP header"), but the format 

(specifically, the port number) is not specified. This omission is 

strange, because the protocol cannot be implemented in the absence of 

this information!