Subject: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 9 Feb 2004 11:09:58 +0100

Dear all

Last Friday we have submitted the following draft to the IETF (NSIS):
"RMD (Resource Management in Diffserv) QoS-NSLP model",
draft-bader-RMD-QoS-model-00.txt.

It will probably take some time to be announced.
Therefore, I am sending you the URL where
you, temporarily, can  find it:

http://wwwhome.cs.utwente.nl/~goering/draft-bader-RMD-QoS-model-00.txt

This draft describes an edge-to-edge local QoS model, called Resource
Management in Diffserv (RMD),
which uses the stateless/reduced state operation mode of QoS-NSLP protocol.
The model provides
scalability and uses simplified NSIS operation.

The specification of this QoS model includes description of QSpec
parameters, as well
as how that information should be treated and interpreted in the network. In
that sense,
this QoS model goes beyond the QoS-NSLP protocol level and describes
underlying
assumptions, conditions and appropriate provisioning mechanisms.

If you have any comments or questions please reply to this
e-mail (on the NSIS mailing list).

Best Regards,
Georgios

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

---

From: "Thanh Tra LUU" <[email-masked]>
Date: Tue, 17 Feb 2004 14:14:22 +0100

hi  Attila,

i've read your draft. i see it as the continuation of rmd model, an one of
many models that qos-nslp can support. i find it very interesting and i have
some questions to understand better your model.

1. How to translate a resource request into resource units request? The
translation ensures all qos parameters of the original request ?  (e.g.
delay)

2. There is a timer for each reservation per flow in interior nodes , so an
interior node charge will linearly increase following the number of per flow
sessions?

3. In the last paragraph of 2(protocol model), 'they are not able to
establish and maintain security associations with their neighbors, which
means, they can only be applied in a trusted domain'. The stateless does not
mean no security association.  In rsvp, the sa is not specified how it can
create (maybe by ike, manual) and which node is the next rsvp-aware node.

4. you didn't introduce what TIME_VALUES object is. Just because i'd like to
know it more clearly.

5. an interior node can be an edge node of other flows ?

6. it seems that an ingress node must know the egress node before making the
local reservation. Can it be done at the same time ? tell me the reason why
you don't integrate the e2e reservation and local reservation in a same
message. I might see the reason in rfc3175, but it's not the answer in your
case.

thanks & regards

Nary Tra,
ENST, Paris

---

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 17 Feb 2004 14:28:13 -0000

hi.

so far as i can tell, (it's certainly what is in my head),
it could probably be made a MUST for GIMPS implementations
that it should be possible to configure a node policy that

- no NSLP data is carried in datagram mode;
- connection mode must be secured.

in the case that the QoS-NSLP is prepared to rely entirely
on GIMPS for its security services (*which is of course an
issue for discussion at the moment*), this would therefore
seem to address the concern below, at least partially.

[of course, the node would no longer have the performance/
scalability properties that some people apparently desire,
because of the GIMPS behaviour when this type of policy is
in place; however, the NSLP behaviour would not need to be
redefined.]

robert h.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, February 17, 2004 14:50
> To: [email-masked]; [email-masked]
> Subject: RE: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS
> 
> 
> Hi Attila,
> 
> Nary Tra's email also raised a question in my mind:
> 
> In an IESG review of a SIGTRAN document of mine, the IESG 
> (specifically
> the Security Area Director) said that the IESG will not standardize 
> anything with the 'trusted domain' concept.  The Security AD commented
> that compromised nodes in a 'trusted network' have caused far more
> serious problems than is always documented.  For example, a 
> disgruntled
> employee with a key to the server room can do a lot of 
> hacking.  With this
> in my mind, I think that you will have to rethink this part of your
> draft.  You need to be able to provide a mechansims of how neighbors
> can establish & maintain security associations.  This does not mean
> that a security association always must be used, but the the 
> possibility
> for creating a security association is mandatory, in my opinion.
> 
> thanks,
> John
> 
>

---

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 17 Feb 2004 14:42:01 -0000

hi sven,

[snip]
> Sven>> Imho, the QoS NSLP should rely on GIMPS for some/most of its
> security services but GIMPS alone is not sufficient because 
> it does not
> protect against compromised QNEs, only against their interconnection.
> 

fair enough. but protecting against a compromised QNE is a
much harder topic (and not the focus of John's comment, AFAICT).
if someone can compromise the QNE they can probably legitimately
request practically anything from the neighbours. securing
against this sort of attack is much more a matter of making
sure that damage does not propagate, operating gracefully under
overload conditions, and so on.

r.

---

From: Tschofenig Hannes <[email-masked]>
Date: Tue, 17 Feb 2004 15:53:18 +0100

hi all, 

thanks for raising this issue. it would be important to state very clearly
that some signaling messages in gimps cannot be secured (or at least with
some degree of difficulty). i have proposed this addition. 
(i was actually surprised that michael richardson did not mention anything
along these lines in his comments.)

relying on gimps to provide security for the upper layer is, per default,
not a bad thing for some scenarios but some additional assumptions need to
be spelled out (as robert said). 

i also agree that the concept of a 'trusted domain' (as pointed out by Nary
Tra's mail) cannot be a justification for not providing security. 

mechanisms need to be in place to allow protection of signaling messages.
hence it would be good to find some use cases for signaling applications
which need NO security protection. 

ciao
hannes

> From: Hancock, Robert [mailto:[email-masked]]
> Sent: Tuesday, February 17, 2004 3:28 PM
> To: [email-masked]'; [email-masked]; [email-masked]

---

From: Tschofenig Hannes <[email-masked]>
Date: Tue, 17 Feb 2004 15:57:11 +0100

hi all, 

a discussion of mechanisms to prevent compromised intermediate nodes can
also be found in the "rsvp security properties" draft. some people proposed
mechanisms but they have never reached the standardization (i guess) since
you can do a number of things at a compromised node other than "only"
changing qos signaling messages

ciao
hannes

> Sent: Tuesday, February 17, 2004 3:42 PM
> To: [email-masked]'
> Cc: [email-masked]'; [email-masked]; [email-masked]

---

From: Tschofenig Hannes <[email-masked]>
Date: Tue, 17 Feb 2004 15:59:31 +0100

hi Nary Tra, 

you might want to take a look at the latest qos nslp draft. we have included
a description in there which might help. 
please see http://www.tschofenig.priv.at/cgi-bin/nsis.cgi

ciao
hannes

> From: Thanh Tra LUU [mailto:[email-masked]]
> Sent: Tuesday, February 17, 2004 3:53 PM
> To: [email-masked]
> Subject: Re: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS
> 
> 
> hi Sven,
> 
> do you mean QoS-NSLP would support authentication policy 
> elements (as rsvp)
> and NTLP would support integrity elements (in rsvp) or 
> QoS-NSLP may do all
> in some cases ?
> 
> Nary Tra,
> ENST, Paris.
> 
>

---

From: Attila Báder (IJ/ETH)<[email-masked]>
Date: Tue, 17 Feb 2004 16:04:21 +0100

Hi John,

Probably this is not good news for us, in our concept edge nodes should be treated as nodes responsible for security and interior nodes are hidden from outside.

Best regards, Attila

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Tuesday, February 17, 2004 2:50 PM

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

---

From: Tschofenig Hannes <[email-masked]>
Date: Tue, 17 Feb 2004 16:06:33 +0100

hi sven,

the policy object is certainly needed in some scenarios. 

ciao
hannes

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Tuesday, February 17, 2004 4:01 PM
> To: Thanh Tra LUU
> Cc: [email-masked]
> Hi Nary,
> QoS NSLP has POLICY_DATA in its current version of the spec. 
> Even if GIMPS
> provides integrity, I am not sure it is unneeded in QoS NSLP 
> (e.g. if QoS
> NSLP is carrying information that is opaque for (some) 
> intermediate nodes).
> 
> Sven
> 
> 
> 
> 
> 
> 
> "Thanh Tra LUU" <[email-masked]>@ietf.org on 17/02/2004 15:53:29
> 
> Sent by:    [email-masked]
> 
> 
> To:    <[email-masked]>
> cc:

---

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 17 Feb 2004 15:33:03 -0000

hi all,

just in case there is any unclarity:

> some degree of difficulty).

the version -00 draft (basically unchanged in -01) states:

on page 5

"Datagram mode: A mode of sending GIMPS messages between nodes without
      using any transport layer state or security protection."

and on page 6

"Here, with details discussed later, "easy" messages are those that
[...] do not need transport or network-layer security support."

and on page 7

"The datagram mode uses a lower-layer unreliable unsecured datagram
   transport mechanism, with UDP as the initial choice."

and on page 14

"The main decision is whether the message must be sent in
 connection mode or datagram mode. Reasons for using the former
 could be:

      *  NSLP requirements: for example, the signaling application has
         requested channel secured delivery, or reliable delivery;"

and so on.

if people think this needs to be emphasised more clearly, please
let me know.

r.

---

From: Tschofenig Hannes <[email-masked]>
Date: Tue, 17 Feb 2004 16:39:50 +0100

hi robert, 

a possible reason for confusion might be 
- many pages in the draft talk mention it here and there 
- 'no security' is vague (what we call cookies in the the discovery message
exchange would be classified as weak authentiction by others)
- nslp applications which need no security have not been discussed (maybe a
traceroute would provide it)
- the terminology of c-mode and d-mode is new (and, as you know, not the
best choice - my opinion only). 

ciao
hannes

> Sent: Tuesday, February 17, 2004 4:33 PM
> To: Tschofenig Hannes; [email-masked]'; [email-masked];
> [email-masked]
> -- 
> Registered Office: Roke Manor Research Ltd, Siemens House, 
> Oldbury, Bracknell,
> Berkshire. RG12 8FZ
> 
> The information contained in this e-mail and any attachments 
> is confidential to
> Roke Manor Research Ltd and must not be passed to any third 
> party without
> permission. This communication is for information only and 
> shall not create or
> change any contractual relationship.
>

---

From: Tschofenig Hannes <[email-masked]>
Date: Tue, 17 Feb 2004 17:15:40 +0100

hi, 

in the two party authorization model it does not need more than that. 
for the three party scenarios, however, it is necessary to provide
additional information at the qos nslp. 

ciao
hannes

> Sent: Tuesday, February 17, 2004 5:09 PM
> To: [email-masked]
> > GIMPS can only provide integrity protection between adjacent
> > QNEs. if a QNE needs to send a message with a policy object
> > and have it received with intact integrity protection several
> > QNEs away, this integrity protection must be provided within
> > the QoS NSLP.
> 
> does QoS-NSLP really need to require NTLP more than it 
> (integrity protection
> between adjacent QNEs) ?
> 
> Nary Tra,
> ENST, Paris.
> 
>

---

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 25 Feb 2004 11:07:13 -0000

dave,

this is a reasonable question.

i would perceive there are being three points (roughly in 
increasing order of importance, in my perception anyway...)

1. yes, bulk encryption is useful anyway. (one of the points
raised by Steve Bellovin during the requirements review was
that signalling data is actually more sensitive than 'ordinary'
data, and so protection of it was worth making possible almost 
as a default, without depending on each signalling application
to design their own method.)

2. in some (many?) cases, it is *only* adjacent signalling application
peers which need direct security associations. in that case,
the signalling application doesn't need to specify additional
security measures (this depends on how much GIMPS exposes the 
details of the peer authentication the signalling applications,
which is still somewhat open). 

[A point to note, maybe: as GIMPS develops, we are getting closer
to the goal of ensuring that multiple xNEs use the same transport
*only* if there is an instance of each xNE at each end of that
transport. (This is basically the 'intermediary' discussion,
and is one reason to try to get rid of them.) In other words, 
the situation that you raise of "the xNE topology which processes 
these elements is not congruent" should be prevented from happening 
by the way the GIMPS peer discovery process and C-mode setup 
actually works.]

3. we are keen to prevent signalling applications being DoS'ed
with (for example) fake messages, including messages which 
require a significant computational effort to validate (e.g.
traversing a certificate chain and verifying signatures). 
the GIMPS-level security protection allows you to reduce the
number of nodes through which such messages can be sent (only
the GIMPS authenticated peers) and to do source authentication
to ensure that the messages really have come from those peers.
in that sense, the lower level security protection complements
(but would not be replaced by) higher level CMS-like methods in 
the signalling applications.

it isn't pretty, I accept. but protecting signalling applications
from DoS attacks from random off-path nodes without requiring them
all to implement their own message-by-message cookie exchanges (or
whatever) is a significant issue (in my view), as well as the 
other points.

cheers,

robert h.

> From: David Oran [mailto:[email-masked]]
> Sent: Tuesday, February 24, 2004 13:21
> To: Hancock, Robert; [email-masked]';
> [email-masked]
> Cc: Thanh Tra LUU; [email-masked]
> --On Tuesday, February 17, 2004 3:40 PM +0000 "Hancock, Robert" 
> <[email-masked]> wrote:
> 
> > hi all,
> >
> and once you have this requirement, what exactly does the 
> security provided 
> by the transport level buy you? Bulk encryption? It seems if 
> multiple xNE 
> protocol elements are to be multiplexed over the same 
> transport, but the 
> xNE topology which processes these elements is not congruent, 
> I wonder if 
> the transport level security (e.g. TLS) can be relied on for much of 
> anything.
> 
> I must be missing something here, since one of the strongest 
> motivations 
> for a C-mode transport was exactly this.
> 
> Confused, Dave.
> > r.
> >
> >> From: [email-masked]
> >> [mailto:[email-masked]]
> >> Sent: Tuesday, February 17, 2004 16:30
> >> To: [email-masked]
> >> Cc: Thanh Tra LUU; [email-masked]
> >> nary,
> >> QoS-NSLP POLICY_DATA object carries policy elements for 
> authorization
> >> purposes between two policy-capable nodes. like what was 
> done in RSVP.
> >>
> >> how far QoS-NSLP relies on NTLP for the so-called integrity objects
> >> (RSVP terminology) is the issue.
> >>
> >> yacine
> >>
> >>
> >>
> >> [email-masked] wrote:
> >>
> >> > Hi Nary,
> >> >
> >> > QoS NSLP has POLICY_DATA in its current version of the
> >> spec. Even if GIMPS
> >> > provides integrity, I am not sure it is unneeded in QoS
> >> NSLP (e.g. if QoS

---

From: Tschofenig Hannes <[email-masked]>
Date: Wed, 25 Feb 2004 13:58:15 +0100

hi dave, 

you addressed different issue in your mail:

1) existing security protocols
existing security protocols provide sophisticated authentication and key
exchange mechanisms. typically these protocols are split into two phases:
one which performs authentication and key exchange and the second phase
applies security protection (integrity, confidentiality protection)

you need to know to which entity to send a message before you apply security
protection. 

the availability of these security protocols has an impact on the choice of
the transport layer protocol (but this is not the only criteria for
selection of a transport protocol). 

2) security at the nslp layer vs. ntlp layer
you need to secure payloads at the nslp layer (some specific qos objects,
for exampe) most likely only between non-neighboring nodes. you can compare
this functionality with security mechanisms in sip or diameter. cms usage
for protection of key transport was suggested in diameter. end-to-end
security mechanism in SIP is other example. these mechanisms are used in
addition to security protection between neighboring peers due to some
specific requirements (with the corresponding semantics). what would you
think if i would suggest to protect every diameter or every sip message
between neighboring nodes with cms or s/smime? you would, most likely, argue
that i am completely crazy. 

ciao
hannes

> Sent: Tuesday, February 24, 2004 2:21 PM