[NSIS] Re: New version of NSIS Req submitted

[Harald Tveit Alvestrand <[e-mail]>]

Marcus,
thanks!

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

> 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.

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

This one works for me, too.
>
> ============================
> 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.

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.


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