Subject: [NSIS] New version of Req submitted

From: Marcus Brunner <[email-masked]>
Date: Tue, 12 Aug 2003 11:33:01 +0200

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: [email-masked]
WWW:    http://www.ccrle.nec.de/
Phone: +49 (0) 6221 905 11 29
Mobile: +49 (0) 163 275 17 43
personal home page: http://www.brubers.org/marcus

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

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 15 Aug 2003 06:36:46 -0700

Marcus,
thanks!

--On 12. august 2003 11:33 +0200 Marcus Brunner <[email-masked]> 
wrote:

> (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
>
> 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.
>
> 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
>
> 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.
>
> requirements via modular components or capabilities, which are optional
> to implement or use in individual nodes.

This one is fine with me. It's now clear that it's an informal definition, 
and the "first hop" thing has entirely gone.
> 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.

This one works for me, too.
> individual routers (except in the special case that the domain contains
> one link). Domains are assumed to be administrative entities, so security
> 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.
>
> 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,
> 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
>
> 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.

note: the last sentence does not parse. If you drop "Since", it both parses 
and makes sense (I think). If this is the only problem in -09, it can be 
fixed with an RFC Editor's  note.
>
> 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.