[NSIS] RE: New version of NSIS Req submitted

[[e-mail]]

Hi Marcus,

Thanks for updating the document.  I hope the text changes
are sufficient for Harald & Steve.

Allison, as long as there are no objects, can the updated
document be considered at the next IESG call?

thanks,
John

> -----Original Message-----
> From: ext Marcus Brunner [mailto:[e-mail]]
> Sent: 12 August, 2003 12:33
> To: Loughney John (NRC/Helsinki); Allison Mankin
> Cc: [e-mail]; Harald Tveit Alvestrand; Steve Bellovin
> Subject: New version of Req submitted
> 
> 
> 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