Subject: Re: [NSIS] AD Review comments on draft-ietf-nsis-req-07.txt

From: Scott Bradner <[email-masked]>
Date: Mon, 9 Jun 2003 07:15:06 -0400 (EDT)

allison suggests:
> Suggestion:  "Signaling might also be used as a communication protocol
> to set up the state in middleboxes."

setup and maintain?

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

---

From: [email-masked]
Date: Tue, 10 Jun 2003 11:06:41 +0300

Hi Allison,

Thanks for the comments.  I think that the comments below can be adopted
in the document.  I will discuss with Marcus a plan to make the changes
and get the document submitted so that this can be sent to the IESG.

As there is already WG consensus on this draft, we should avoid major
discussion of the points, unless there is serious disagreement on them.

thanks,
John

> -----Original Message-----
> From: ext Allison Mankin [mailto:[email-masked]]
> Sent: 09 June, 2003 09:30
> To: [email-masked]
> Cc: Loughney John (NRC/Helsinki); [email-masked]; [email-masked]
> Subject: AD Review comments on draft-ietf-nsis-req-07.txt
> 
> 
> Marcus, John and WG,
> 
> Here are my AD Review comments on the NSIS requirements.  Overall
> it is a good document.  I have a few problems on charter, technical
> or clarity points.  Discussion welcome.
> 
> Allison
> 
> -------- 
>    However, QoS is not the only field where signaling 
>    is used in the Internet. Others might be the use for middlebox 
>    communication [RFC3234]. 
> 
> It would be helpful to clarify the manner in which signaling would be
> used for middlebox communication (in one sentence) - this is 
> so terse, that
> only if a reader has been in the working group would they 
> understand the
> sentence.
> 
> -------- 
>    There are several areas related to networking aspects which are 
>    incomplete, for example, interaction with host and site multi-
>    homing, use of anycast services, and so on. These issues should be 
>    considered in any future analysis work. 
> 
> Incomplete in the sense of requirements analysis?  This 
> paragraph suggests
> a different kind of analysis.  Also anycast in particular 
> seems very unlikely 
> to be a significant element in signaling requirements 
> analysis - it seems 
> like it should not be mentioned in the same sentence with a 
> common issue 
> like multihoming.  
> 
> Suggestion:  "This document does not cover requirements in 
> relation to some
> networking areas, in particular, interaction with host and 
> site multihoming.
> We leave these for future analysis. "
> 
> -------- 
> 
> NSIS Initiator - needs to say, in parallel with the NSIS Responder, 
> it interacts with applications  (Definition does not say so).
> 
> -------- 
> 3. Something that terminates the signaling path, the NSIS Responder.
> 
>    The NSIS responder might be in an end-system or within other
>    equipment. The distinguishing feature of the NSIS Initiator is that
>                                                      ^^^^^^^^^
>    it responds to requests at the end of a signaling path.
> 
> Typo? s/Initiator/Responder/
> 
> -------- 
>    The host to first 
>    router part includes all the layer 2 technologies to access to the 
>    Internet.
> 
> Consider a home network with a wireless router and a DSL 
> router accessing
> the Internet.  The topology definition is less crisp than 
> host to *first*
> router.  I suggest you add a sentence after this one:  "This 
> part of the
> division is especially informal and may incorporate several 
> access segments."
> -------- 
> 
> 5.2.2 NSIS MUST support path-coupled and SHOULD NOT exclude path-
>      decoupled signaling.  
> 
> SHOULD NOT is very strong, given that the WG is not chartered 
> to work on
> this technology.
> 
> The language needs to be "MAY support path-decoupled signaling." 
> 
> -------- 
> 
> 5.3.2 Automatic release of state after failure SHOULD be possible 
>     
>    When the NSIS Initiator goes down, the state it requested in the 
>    network SHOULD be released, since it will no longer be necessary. 
> 
> An important feature of RSVP was its soft-state character, in part to
> ensure that critical resources in the net were not 
> fate-shared for too long.
> Given this is about release after _failure_, these SHOULDs 
> should be MUSTs,
> if not going so far as to preserve the soft-state 
> architecture.  Comments?
> 
> -------- 
> 
> 
> 5.4.3 State MUST be addressed independent of flow identification 
>     
>    Addressing or identifying state MUST be independent of the flow 
>    identifier (flow end-points, topological addresses). Various 
>    scenarios in the mobility area require this independence because 
>    flows resulting from handoff might have changed end-points 
> etc. but 
>    still have the same service requirement. Also several proxy-based 
>    signaling methods profit from such independence. 
> 
> Add to the last sentence "though these are not chartered work 
> items for
> NSIS".
> 
> This is a tough requirement since it has to be globally 
> unique.  It may
> turn out to be best met by the NI's authentication token, requiring an
> early integration of authentication design into the protocol. 
>  No request
> to change this, but just noting how hard this is - WG is _sure_
> the mobility requirements are really so important?
> 
> -------- 
> 
> 
> 5.4.1 Mutability information on parameters SHOULD be possible 
>     
>    It SHOULD be possible for the NSIS initiator to control the 
>    mutability of the signaled information. This prevents them from 
>    being changed in a non-recoverable way. The NSIS initiator 
> SHOULD be 
>    able to control what is requested end to end, without the request 
>    being gradually mutated as it passes through a sequence of 
> domains. 
>    This implies that in case of changes made on the parameters, the 
>    original requested ones must still be available.  
>     
>    Note that we do not require anything about particular parameters 
>    being changed.  
>     
>    Additionally, note that the provider of the particular requested 
>    services can still influence the provisioning but in the signaling 
>    message the request should stay the same. 
> 
> The requirement is not expressed well.  Do you mean "It SHOULD be
> possible to have nodes modify parameters to interact with the
> signaling message, while still retaining an intact copy of the
> original form of the signaling message"?  
> 
> This requirement seems like it would vary a great deal 
> depending on what
> the signaling application was, and as it is written here it 
> is very close
> to a protocol design rather than a requirement.  Could you omit
> it from this document?
> 
> -------- 
> 
>                                                        One of the 
>    reasons is that the protocol handling should have a minimal impact 
>    on interior (core) nodes. 
> 
> Suggest adding that NSIS MAY also have a feature allowing core nodes
> to ignore it (though I hope it will be more elegant than RSVP's as
> document in RFC 3175 :)
> 
> -------- 
> 
> 5.7.5 Hop-by-hop security 
>     
>    Hop-by-Hop security SHOULD be supported. It is a well known and 
>    proven concept in Quality-of-Service and other signaling protocols 
>    that allows intermediate nodes that actively participate in the 
>    protocol to modify the messages as it is required by processing 
>    rules. Note that this requirement does not exclude end-to-end or 
>    network-to-network security of a signaling message. End-to-end 
>    security between the initiator and the responder may be used to 
>    provide protection of non-mutable data fields. Network-to-network 
>    security refers to the protection of messages over various 
> hops but 
>    not in an end-to-end manner i.e. protected over a 
> particular network. 
> 
> Without minimum mandatory to implement channel security for 
> the signaling, 
> you can't be sure the other security features will be 
> untampered with -
> this needs to be a MUST implement (it's not a MUST use).  
> Suggest changing
> the first sentence to "Channel security between signaling entities
> MUST be implemented'?
> 
> -------- 
> 
> 
> 5.9.5 SHOULD interwork with seamless handoff protocols 
> 
> 5.9.6 MAY interwork with non-traditional routing 
>     
>    NSIS assumes L3 routing, but networks, which do non-traditional 
>    routing, should not break it. 
> 
> NSIS should not be complex and interworked in ways that make 
> it less modular.
> Both of these requirements are complications.  The first one, 
> because it poses
> a certain environment and particular protocols, would make 
> NSIS less modular.
> It is probably improved by changing SHOULD to MAY.  The 
> second one may sound
> worse than it is - does it mean NATs?  Suggest this might have meant:
> 
> 5.9.6. MAY operate in varied routing environments
> 
>      NSIS assumes L3 routing, but it MAY be designed to operate in
>      varied routing environments, such as those with L4 
> switches and NATs.
> 
> But if not, do explain...
> -------- 
> 
> Scenarios -
> 
> 's' as an abbreviation is not explained.
> 
> -------- 
> 10.2
> 
> The 3G Scenario is somewhat too specific to 3GPP and 3GPP2 
> still - IMS is
> mentioned without being expanded or explained.  All the terms 
> are specific.
> Try to make it a bit more abstract - say it is an All-IP 
> multimedia system.
> 
> -------- 
>      This part of the wireless network has different 
>      characteristics when compared to traditional IP networks: 
>     
>          1. The network supports a high proportion of real-time 
>             traffic.  The majority of the traffic transported in the 
>             wired part of the wireless network is speech, which is 
>             very sensitive to delays and delay variation (jitter). 
> 
> Two things about IP networks - they carry whatever they carry, so
> it's not out of tradition to be a voice IP network.  Second, speech in
> Internet phones is quite a lot less sensitive to delays and 
> jitter than
> often thought, due to the many good engineering designs in playout and
> speech cover that are known.  So this material places a 
> context of more
> difference on the environment than most general transport experts view
> as necessary, seeing more continuum, while not disagreeing 
> that signaling
> and resource reservation are valuable.
> 
> So drop sentence 1, but leave the rest alone (I just wanted 
> to make my point :)
> 
> -------- 
> 
> 
> 10.10  Application request end-to-end QoS path from the network 
>     
>    This is actually the easiest case, nevertheless might be 
> most often 
>    used in terms of number of users.
> 
> Few believe that ordinary applications signaling for QoS is 
> an easy matter for
> the network - RFCs 2961, 2996 and 3175 are all about 
> mitigating the unscalability
> of edge signaling.  Probably this would go better if you 
> substitute the term
> "conceptually simplest" for "easiest" and note that there are 
> these issues with
> scaling.  
> 
> 
>     Additionally, we assume no mobility and standard devices. 
> 
> Note: the end system application and NSIS do not know about the 
> distinction between 10.10 and the other scenarios :), unless 
> NSIS is not 
> a modular Internet protocol.
> 
> -------- 
> 
> QoS for Virtual Private Networks - section needs a number
> 
> IP-Sec -> IPSec
> 
> The discussion of NSIS in VPNs ignores the whole world of the 
> PPVPN WG.  
> Cite draft-ietf-ppvpn-framework-08.txt early on in the 
> section (it is in the 
> RFC-Editor Queue).  
> 
> 
> 
> Allison
> 
>     
>

---

From: [email-masked]
Date: Tue, 10 Jun 2003 11:08:48 +0300

Hi Alejandro,
 
I think that as we've already passed WG last call, there isn't a strong reason to make the changes you propose.
 
thanks,
John

-----Original Message-----
From: ext Avella, Alejandro [mailto:[email-masked]]
Sent: 09 June, 2003 17:38
To: [email-masked]'; [email-masked]
Cc: Loughney John (NRC/Helsinki); [email-masked]
Subject: RE: [NSIS] AD Review comments on draft-ietf-nsis-req-07.txt

Allison Mankin wrote: 
>Second, speech in Internet phones is quite a lot less sensitive to delays and jitter than 
>speech cover that are known.  

From draft-ietf-nsis-req-07.txt, Page 27. 

Comment on Requirements document: 
Consider being more specificic on the sentence above.  Voice requirements for toll-quality are: 
a) One way delay < 150 ms from ITU-T G.114 (Round Trip delay < 300 ms) 
b) Jitter < 50 ms 
c) Packet Loss < 10^-5 

I obtained the above values from section 3.1 of the following paper. 

M. Karam, F. Tobagi, "Analysis of Delay and Delay Jitter of Voice Traffic in the Internet", Computer Networks 40 (2002) 711-726 http://www.stanford.edu/class/ee384b/reading/KaramTobagi.pdf

Alejandro Avella 

*************************************************************************
This e-mail transmission, and any documents, files, or previous
e-mail messages attached to it may contain information that is 
confidential or legally privileged. If you are not the intended 
recipient, or a person responsible for delivering it to the 
intended recipient, you are hereby notified that you must not 
read this transmission and that any disclosure, copying, printing,
distribution, or use of any of the information contained in or 
attached to this transmission is strictly prohibited. If you have 
received this transmission in error, please immediately notify the 
sender by telephone or return e-mail and delete the original 
transmission and its attachments without reading or saving them 
in any manner. Thank you.
*************************************************************************

---

From: [email-masked]
Date: Tue, 10 Jun 2003 11:12:29 +0300

Hi Scott,

> allison suggests:
> > Suggestion:  "Signaling might also be used as a 
> communication protocol to set up the state in middleboxes."
> 
> setup and maintain?

Yes, probably so.

John

---

From: Tschofenig Hannes <[email-masked]>
Date: Tue, 10 Jun 2003 10:22:29 +0200

hi allison, 

thank you for pointing to a security issue in the document. 

> the first sentence to "Channel security between signaling entities

you are fully right. i have no idea how this modification sneaked into the
draft. i looked a previous versions of the document and found that it
contained a must. 

i also suggest to change the first sentence from 

"Hop-by-Hop security SHOULD be supported."

to 

"Channel security between signaling entities MUST be implemented. "

ciao
hannes

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, June 10, 2003 10:07 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: [NSIS] RE: AD Review comments on draft-ietf-nsis-req-07.txt
> 
> 
> Hi Allison,
>

---

From: [email-masked]
Date: Thu, 12 Jun 2003 07:25:19 +0300

Hi Marcus,

In general, all of the comments look good, one concern, however -
> > mentioned without being expanded or explained.  All the terms are
> > specific. Try to make it a bit more abstract - say it is an All-IP
> > multimedia system.
> 
> expanded the IMS, but being specific is on purpose it should be the 3GPP 
> scenario. A less specific version has been complained about.

The one problem is that the IETF is not 3GPP, and it may be
seen as the IETF imposing its view upon 3GPP.  We should be 
careful not to imply that this is the way that the IETF or
the NSIS WG thinks 3GPP should do things.

John

---

From: "Geib, Ruediger" <[email-masked]>
Date: Mon, 16 Jun 2003 09:46:08 +0200

Hello Allison,

during my design efforts on a new backbone signaling protocol 
I came to the same conclusion as formulated by the requirement 
below. I don't think that it is mobility specific. Please note 
that also RFC 3175 simplifies the state addressing slightly 
(two IP addresses and a DSCP instead of RSVPs 5 tuple). It's 
a general requirement and should be kept unchanged.

Regards, Rudiger

| Allison Mankin writes:
|> 5.4.3 State MUST be addressed independent of flow identification 
| [snip]
|> No request
|> to change this, but just noting how hard this is - WG is _sure_
|> the mobility requirements are really so important?
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: [email-masked]
Date: Tue, 17 Jun 2003 11:20:24 +0300

Hi Georgios,

> You are right, but there are situations where security can be provided,
> without adding additional functionality into the protocol.

What we are requiring is not that NSIS develop new mechanism, but support
existing ones.  

> For example, the security threats within a trusted administrative domain are
> different then the security threats in a inter-domain communication. Therefore, the
> security features required in these two situations are different.

Can you give me a pointer to where a 'trusted administrative domain' is
defined, especially in IETF literature?  As I understand, trusted
domains are not accepted in the IETF as proper security mechanisms.

We have had this discussion in the SIGTRAN wg, and the IESG told us
that trusted networks was not a good model, and asked us to reconsider this.
The result can be found here:

http://www.ietf.org/internet-drafts/draft-ietf-sigtran-security-02.txt

br,
John

---

From: [email-masked]
Date: Tue, 17 Jun 2003 14:57:50 +0300

Hi Georgios,

> > We are designing this for the Internet (see the 'I' in the
> > IETF).  This being so, security is extremely important and
> > is needed to ensure a robust protocol that is resistant
> > to DoS attacks; protects infrastructure, etc.  In this
> > way:
> 
> You are right, but there are situations where security can be 
> provided, without adding additional functionality into the protocol.
> 

Currently, the suggested text is:

	"Channel security between signaling entities MUST be implemented."

As one cannot implement or mandate use in a trusted admin domain,
I am not sure how to capture your concern.

If there exists certain deployment scenarios where interior nodes don't
have security associations, that is life.  However, I doubt the security
area will let us have a SHOULD for this requirement, as they have not
let other working groups do that.

John