Security Threats for Next Steps in Signaling (NSIS)
RFC 4081
Yes
No Objection
No Record
Note: This ballot was opened for revision 06 and is now closed.
(Allison Mankin; former steering group member) Yes
(Alex Zinin; former steering group member) No Objection
(Bill Fenner; former steering group member) No Objection
(David Kessens; former steering group member) No Objection
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 ?
(Harald Alvestrand; former steering group member) No Objection
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)"
(Margaret Cullen; former steering group member) No Objection
(Russ Housley; former steering group member) (was Discuss) No Objection
(Scott Hollenbeck; former steering group member) (was Discuss) No Objection
(Steven Bellovin; former steering group member) No Objection
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.
(Ted Hardie; former steering group member) (was Discuss) No Objection
[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.
(Bert Wijnen; former steering group member) No Record
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/