Security Threats for Next Steps in Signaling (NSIS)
draft-ietf-nsis-threats-06

From ops directorate by Pekka Savola regarding draft-ietf-nsis-threats-05.txt:

It seems that a few more of the NSIS documents should be normative
references, e.g., the framework ?

Reviewed by Mary Barnes, Gen-ART

Her review:

Summary: 
-------- 

Both drafts are ready to publish as Informational with the correction of the following editorial nits. 

Nits (nsis-threats): 
-------------------- 

- Section 3.1: There's a formatting problem in this section with the
 identation OR the phrase "following two cases:" on the top of page 10
 should read "following three cases:"

- Section 3.1: First paragraph following the idented parts (page 11),
  beginning with "Finally, we conclude a description". The word
  "conclude" needs to be changed to "include" or "conclude with".

 - Section 3.1: Page 11, Last paragraph, last sentence. "A malicious
   NSIS can be detected..." needs to change to "A malicious NSIS node
   can be detected..."

- Section 4.10: Page 24. Reference to "Figure 3" should be "Figure
  4".



Nits (nsis-fw): 
--------------- 

- Abstract: It's longer than the guidelines recommendation of typically
5-10 lines, but no more than 20 lines. I would suggest a change from:

 "The Next Steps in Signaling working group is considering protocols 
 for signaling information about a data flow along its path in the 
 network. Based on existing work on signaling requirements, this 
 document proposes an architectural framework for such signaling 
 protocols. 

 This document provides a model for the network entities that take 
 part in such signaling, and the relationship between signaling and 
 the rest of network operation. We decompose the overall signaling 
 protocol suite into a generic (lower) layer, with separate upper 
 layers for each specific signaling application. An initial proposal 
 for the split between these layers is given, describing the overall 
 functionality of the lower layer, and discussing the ways that upper 
 layer behavior can be adapted to specific signaling application 
 requirements. 

 This framework also considers the general interactions between 
 signaling and other network layer functions, specifically routing, 
 mobility, and address translators. The different events that impact 
 signaling operation are described, along with how their handling 
 should be divided between the generic and application-specific 
 layers. Finally, an example signaling application (for Quality of 
 Service) is described in more detail." 



to (adding the second sentence for clarity) and removing alot of unnecessary detail: 
   "The Next Steps in Signaling working group is considering protocols 
   for signaling information about a data flow along its path in the 
   network. The NSIS suite of protocols is envisioned to support various 
   signaling applications that need to install and/or manipulate state 
   in the network. Based on existing work on signaling requirements, this 
   document proposes an architectural framework for such signaling 
   protocols.  

    This document provides a model for the network entities that take 
   part in such signaling, and the relationship between signaling and 
   the rest of network operation.  We decompose the overall signaling 
   protocol suite into a generic (lower) layer, with separate upper 
   layers for each specific signaling application." 

- Section 2 Terminology - Signaling application.  I think the term
  "service" should be "signaling application" ?

 - Section 3.2.6 - Per the statement in 3.1.2 that path de-coupled is
   out of scope at this time, it would be useful to re-iterate that
   the information in this section is provided for completeness and to
   capture for future reference. I would suggest adding a statement
   something like the following to the beginning of this section:

 "Although, support of path de-coupled operation is not part of the
 initial goals of this NSIS Framework, this section is included for
 completeness and to caputure some initial considerations for future
 reference."

- Section 5.1.2: last paragraph, page 36. Change "traffic))" to
  "traffic)"

The security analysis and considerations sections (4.7 and 7) in draft-ietf-nsis-fw  are weak.  This is a framework document, so that's (marginally) acceptable, but there's a lot of hard work ahead in this security arena.  In particular, you're likely going to need a separate security mechanisms document that relates back to the threats document.

[2004-09-24] in the Framework document, section 3.1.5  says

  A session is an application layer concept for a (unidirectional) flow
  of information between two endpoints, for which some network state is
  to be allocated or monitored.  (Note that this use of the term
  'session' is not identical to the usage in RSVP.  It is closer to the
  session concept of, for example, the Session Initiation Protocol.)

While I don't doubt that a higher-layer concept for the set of
flows that makes up one half of an exchange is useful, I don't think session
is the right term here, and I think suggesting it maps to that may do
harm as further development in the applications' interaction with the
signalling plane.  The Session of SIP, for example, seems to
me explictly the full exchange "There are many applications of the Internet 
that require the creation and management of a session, where a session is 
considered an exchange of data between an association of participants."
(3261, Section 1).  I wish I had a catchy phrase for the concept you
do want; I don't.  But I am concerned about re-using session here,
and I'd like to discuss it.