[NSIS] New version of Req submitted

[Marcus Brunner <[e-mail]>]

John, Allison,

I have a new version of the requirements submitted 
(draft-ietf-nsis-req-09.txt). The comments from Harald and Steve have been 
addressed (see below for the difference between the 08 and 09 of the draft.

Marcus

Section 5 (Harald's comment #1)

OLD

5 Requirements

This section defines more detailed requirements for a signaling solution, 
respecting the framework, scoping assumptions, and terminology considered 
earlier. The requirements are in subsections, grouped roughly according to 
general technical aspects: architecture and design goals, topology issues, 
parameters, performance, security, information, and flexibility.

Two general (and potentially contradictory) goals for the solution are that 
it should be applicable in a very wide range of scenarios, and at the same 
time lightweight in implementation complexity and resource consumption 
requirements in NSIS Entities. One approach to this is that the solution 
could deal with certain requirements via modular components or 
capabilities, which are optional to implement or use in individual nodes.

In order to prioritize the various requirements we informally define 
different 'parts of the network'. In the different parts of the network a 
particular requirement might have a different priority.

The parts of the networks we differentiate are the host-to-first router, 
the access network, and the core network. The host to first router part 
includes all the layer 2 technologies to access to the Internet. This part 
of the division is especially informal and may incorporate several access 
segments. In many cases, there is an application and/or user running on the 
host initiating signaling. The access network can be characterized by low 
capacity links, medium speed IP processing capabilities, and it might 
consist of a complete layer 2 network as well. The core network 
characteristics include high-speed forwarding capacities and inter-domain 
issues. These divisions between network types are not strict and do not 
appear in all networks, but where they do exist they may influence 
signaling requirements and will be highlighted as necessary.

NEW

5 Requirements

This section defines more detailed requirements for a signaling solution, 
respecting the framework, scoping assumptions, and terminology considered 
earlier. The requirements are in subsections, grouped roughly according to 
general technical aspects: architecture and design goals, topology issues, 
parameters, performance, security, information, and flexibility.

Two general (and potentially contradictory) goals for the solution are that 
it should be applicable in a very wide range of scenarios, and at the same 
time lightweight in implementation complexity and resource consumption 
requirements in NSIS Entities. We use the terms 'access' and 'core' 
informally in the discussion of some particular requirements to refer to 
deployment conditions where particular protocol attributes, especially 
performance characteristics, have special importance. Specifically, 
'access' refers to lower capacity networks and fewer users and sessions. 
'Core' refers to high capacity networks with a large number of users and 
sessions.

One approach to this is that the solution could deal with certain 
requirements via modular components or capabilities, which are optional to 
implement or use in individual nodes.

====================================================
Req 5.5.1 Scalability (Harald's comment #2)

NEW added the following paragraph at the end of req 5.5.1

Specifically, NSIS MUST work in Internet scale deployments, where the use 
of signaling by hosts becomes universal. Note that requirement 5.2.4 
requires the functionality of transparently signal through networks without 
interpretation. Additionally, requirement 5.6.1 lists the capability to 
aggregate. Furthermore, requirement 5.5.4 states that NSIS should be able 
to constrain the load on devices. Basically, the performance of the 
signaling MUST degrade gracefully rather than catastrophically under 
overload conditions.

============================
section 3, last paragraph (Steve Bellovin comment #1)

OLD
5. We can see the network at the level of domains/subdomains rather than 
individual routers (except in the special case that the domain contains one 
link). Domains are assumed to be administrative entities, so security 
requirements apply to the signaling between them.

NEW
5. We can see the network at the level of domains/subdomains rather than 
individual routers (except in the special case that the domain contains one 
link). Domains are assumed to be administrative entities. So security 
requirements might apply differently for the signaling between the domains 
and within a domain. Both cases we deal with in this document.

============================
Requirement 5.7.8 (Steve Bellovin comment #2)

OLD

5.7.8 Confidentiality of signaling messages

Based on the signaling information exchanged between nodes participating in 
the signaling protocol an adversary may learn both the identities and the 
content of the signaling messages. To prevent this from happening, 
confidentiality of the signaling message in a hop-by-hop manner MAY be 
provided. Note that the protection can be provided on a hop-by-hop basis 
for most message payloads since it is required that entities which actively 
participating in the signaling protocol must be able to read and eventually 
modify the content of the signaling messages.

NEW

5.7.8 Confidentiality of signaling messages

Based on the signaling information exchanged between nodes participating in 
the signaling protocol an adversary may learn both the identities and the 
content of the signaling messages. Since the ability to listen to signaling 
channels is a major guide to what data channels are interesting ones.

To prevent this from happening, confidentiality of the signaling message in 
a hop-by-hop manner SHOULD be provided. Note that most messages must be 
protected on a hop-by-hop basis, since entities, which actively participate 
in the signaling protocol, must be able to read and eventually modify the 
signaling messages.


--------------------------------------
Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: [e-mail]
WWW:    http://www.ccrle.nec.de/
Phone: [phone]
Mobile: [phone]
personal home page: http://www.brubers.org/marcus





_______________________________________________
nsis mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/nsis