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

[Ballot comment]
[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.

[Ballot comment]
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.

[Ballot comment]
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)"

[Ballot comment]
Document: draft-ietf-nsis-fw-06.txt

  Top of page 20:
      application level.  In this sense, up/down notifications are
      advisories which allow faster reaction to events in the network,
      but shouldn't be built into NSLP semantics.  (This is essentially
      the same distinction - with the same rationale - as SNMP makes
      between traps and normal message exchanges.)

  Would be better to s/traps/notifications/

[Ballot comment]
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 ?

[Ballot discuss]
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.

[Ballot discuss]
Section 4.6 of draft-ietf-nsis-threats-05 calls for non-repudiation.
  I am not convinced by the discussion in that section that a non-
  repudiation service is needed.  Non-repudiation is needed when proof
  is to be provided to a third party.  Yet, the discussion in this
  section do not include a third party.  The ability to present an
  authentic request to the other party for their own validation is
  sufficient for the scenarios discussed.

[Ballot discuss]
The security considerations section of draft-ietf-nsis-fw says this:

"These functions can most likely be provided by some kind of channel
security mechanism using an external key management mechanism based on
mutual authentication."

I found the document to be extremely well written and detailed, but this
looks like a bit of hand waving.  Does this imply that there are no
appropriate security protocols that can be used today?  I can understand
if that's the case given what's written in draft-ietf-nsis-threats.  Some
additional text to explain why no such mechanism is described in the document
would be helpful.