Subject: RE: [NSIS] About GIMPS!

From: Attila Báder (IJ/ETH)<[email-masked]>
Date: Tue, 6 Apr 2004 17:46:37 +0200

Hi Elena,

I do not think so, GIMPS supports sender-initiated signaling application as well. There is an example of operation in 3.3.

As I understand, messaging association is needed for connection mode and may be used also for datagram mode transport. But these states can be set for both directions and used in both sender and receiver initiated case.

Storing backward routing states are needed for receiver initiated reservation (RSVP-like case). In sender-initiated case storing routing states are probably not needed, unless backward messages have to follow the same path as forward messages.

Please tell me if I am not right, best regards, Attila

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Elena
Scialpi
Sent: Tuesday, April 06, 2004 3:54 PM
To: nsis
Subject: [NSIS] About GIMPS!

Hi all, 

In the framework of NSIS there are 2 approaches:

-sender-initiated approach is when the sender of the data flow requests and maintains the 
treatment for that flow;
-receiver-initiated approach the receiver of the data flow requests and    maintains the treatment 
for that flow. 

I think that in  GIMPS (http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-01.txt ) 
there is  only the second approach ( the same approach used in RSVP).

What's "Routing State and Messaging Association Maintainance" in sender-initiated approach ?

Thanks for your replies,
Elena

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

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

---

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 7 Apr 2004 09:48:31 +0100

dear all,

if people want to see the reasoning which went into the current
framework split, it is still written down in
http://www.watersprings.org/pub/id/draft-hancock-nsis-sender-receiver-00.txt

the essential points are:
a) does a protocol have any asymmetry in operation (i.e. client/server,
initiator/responder, whatever)
b) if so, does that asymmetry have any coupling to the direction of
the data flow

the argument of the above i-d (reflected in the framework and the
subsequent protocol designs) is that these questions have to be
considered independently for the NTLP (GIMPS) and NSLPs (signalling
applications).

Specifically for GIMPS, there is asymmetry in the discovery phase,
because only the upstream node can initiate the process (that's a
consequence of IP routing) as Cheng says below. (Whether you want
to call this sender or receiver initiated is just a terminology
issue.) If we can think of ways to make discovery possible in both
directions, we might incorporate them. However, once the message
routing state is set up, GIMPS tries as hard as possible to hide
this asymmetry from the signalling applications. They can make their
own decisions about whether aspects of their protocol should be 
directional and whether to tie that to data flow direction.

What is definitely the case is that GIMPS punts on what initiates the
discovery process in the first place. This is a trigger from the
OS or a particular signalling application, or network management,
or whatever. Signalling application developers need to say what
kicks off this part of the process.

Does this answer the question?

r.

> From: Cheng Hong [mailto:[email-masked]]
> Sent: Wednesday, April 07, 2004 03:52
> To: 'Tschofenig Hannes'; 'Elena Scialpi'; 'nsis'
> Subject: RE: [NSIS] About GIMPS!
> 
> 
> Hi Hannes,
> 
> 
> <Snip>
> > if you decouple the authorization aspects from the signaling 
> > aspects then
> > the concepts of sender- vs. receiver-initiated "something" 
> > are less obvious
> > in a path-coupled signaling protocol. i personally think that the
> 
> I think if we further decouple the messaging association establishing
> procedure (GIMPS) from the actual signaling (NSLP signaling), the
> sender-init vs. receiver-init would be less important. With 
> the current text
> in GIMPS, there is still a subtle difference, e.g. in D-mode, 
> sender-init
> could send NSLP message with the "GIMPS-query" message. 
> 
> As for the messaging association establishment, it is a GIMPS level
> signaling. According to the text in section 4.3, it has to be 
> initiated from
> upstream. What is lacking is how this process is triggered 
> (maybe out of
> scope). What I am not so sure is that if it is triggered by a 
> message sent
> by the receiver, e.g. a BU from a MN, could we call it 
> receiver initiated?
> 
> 
> > definitions of these two terms is rather fuzzy (even in the 
> > framework). with
> > path-coupled signaling only the sender is able to start signaling.
> 
> Do you mean the GIMPS signaling described above? I feel it 
> depends on what
> we took as "signaling": NSLP or NSLP+NTLP. But, overall (for 
> NTLP and NSLP),
> it is quite true.
> 
> 
> cheers
> 
> Cheng Hong 
> 
> 
> > 'maintaining the treatment for a flow' is also difficult to 
> > understand in
> > the light of our mobility discussions or the recently 
> > discussed preemption
> > issues. 
> > 
> > ciao
> > hannes
> > 
> > 
> > > 
> > > Thanks for your replies,
> > > Elena
> > >  
> > > 
> > >

---

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 7 Apr 2004 10:20:03 +0100

hi,

i guess you are referring to nsis-fw 3.3.1. it's true that
it is not very precise, but that is because the issue it is
trying to describe is very broad. it just tries to point out
that there will be choices to be made in signalling application
design and these choices will have some consequences; and that
the NTLP will not constrain those choices. (Which is all that
the framework can say anyway.)

(anyway, it still isn't too late for people to suggest clarification
text!)

r.

> From: Tschofenig Hannes [mailto:[email-masked]]
> Sent: Wednesday, April 07, 2004 10:11
> To: Hancock, Robert; 'Cheng Hong'; 'Elena Scialpi'; 'nsis'
> hi robert, 
> i guess we all agree that there is asymmetry in the discovery phase. 
> i only have problems with the "original definition" of sender- vs.
> receiver-initiated reservations. the do not fit into the nsis 
> picture. 
> 
> ciao
> hannes
> 
> 
> > From: Hancock, Robert [mailto:[email-masked]]
> > Sent: Wednesday, April 07, 2004 10:49 AM
> > To: 'Cheng Hong'; Tschofenig Hannes; 'Elena Scialpi'; 'nsis'
> > -- 
> > Visit our website at www.roke.co.uk
> > 
> > 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: Wed, 7 Apr 2004 11:02:24 +0200

hi cheng, 

please find some comments inline:

> Hi Hannes,
> 
> Please see a few more comments inline:
> 
> > > <Snip>
> > > sender-init vs. receiver-init would be less important. With the 
> > > current text in GIMPS, there is still a subtle 
> difference, e.g. in 
> > > D-mode, sender-init
> > i still cannot get used to the d-mode vs. c-mode terminology. 
> > anyway, the d-mode vs. c-mode issues are also orthogonal to 
> > this discussion.
> 
> True. This has nothing to do with D-mode vs C-mode. It is 
> rather sender-init
> vs. receiver-init. For a sender-init case, it could send NSLP message
> directly using a GIMPS-query message without a messaging 
> association to be
> setup beforehand. For receiver-init signaling, it is not 
> possible to do so.

this issue effectively boils down to a security question: 
- in which cases can you attach a nslp payload to the "discovery" message?
- how do you secure messages where you do not know the next node processing
this message?
- what nslp applications do not require security mechanisms?
- do you know your next peer? 
- if you know him then why don't you address him. 

> > > initiated from upstream. What is lacking is how this process is 
> > > triggered (maybe out of
> > this is part of our mobility discussions. i don't know 
> > whether we should call something receiver-initiated only if 
> > the data receiver triggers some actions (after an initial 
> > exchange already took place). in the mobility case we even 
> > have scenarios where nodes in the middle could trigger something. 
> 
> With mobility scenarios, this would be more intersting. There could be
> different triggers flying around. The issue would be "do we 
> treat these
> mobility signaling part of NSIS signaling"?

we do not treat mobility signaling as part of nsis. nsis signaling needs to
work in a mobile environment. 

 If not, the 
> signaling would be
> almost always sender-init, since the first GIMPS message is 
> always sent out
> from the sender. If yes, then, the signaling could be initiated anyway
> (sender/receiver/middle node)
> 
> 
> > > 
> > the data sender has to send the first message in nearly all cases. 
> 
> Please see above.
> 
> 
> > for the receiver-behind a nat things are a bit different but 
> > this might not fit into the sender- vs. receiver-initiated 
> > "something" terminology either. 
> 
> Agree. Add in the NAT makes it more confusing for now.
> 
> > i suggest to deprecate the sender- and receiver-initiated 
> > terminology. what matters at the end is
> > - who has to provide information for authorizion 
> > - what is he authorized for
> > - to which entity is authorization required
> > - who triggers reauthorization
> > - what credentials are used for authorization
> > - how long is authorization valid
> > - and finally the different levels of authorization (for qos 
> > resource, for triggering certain actions, ... )
> 
> This is a good list. But I feel some of the issues could be 
> separated for
> NTLP(GIMPS) and NSLP.

certainly true. 

> Most of the authorization issues would 
> be related to
> NSLP, e.g. authorization for qos, etc.

i fully agree with you. unfortunately, there is some interworking between
them. 
entirely separating is insecure as we saw with the man-in-the-middle attacks
for tunneled authentication. 

 As for the GIMPS, the 
> issue is more
> focused on the "routing state maintenance" and "messaging 
> association".
true. with version -00 of the gimps draft intermediaries have been
introduced with have no nslp part at the same host. with version -01 this
was removed again. this has major security implications. 

> Therefore, the things to be sort out are: 
> -who and when setup the messaging association (including 
> nodes auth. issues)
> 
> -what triggers the setup of messaging association 
> (interactions with NSLP or
> routing stack)
> -What is the interaction for "routing state" and "messaging 
> association
> (related to mobility)

true. i guess that this is what we do at the moment. we updated the text on
the qos nslp with regard to security. the nat/fw issues contain a fair
amount of security issues (and additional issues are in discussion). based
on the issues we discover in this area input will be provided to the ntlp. 

> 
> 
> 
> > since some of these issues have a relationship to mobility i 
> > would encourage everyone to take a look at the mobility draft 
> > (and the nslps) and to post their opinion. 
> 
> Is the new version of the mobility draft available now?

the draft <draft-manyfolks-signaling-protocol-mobility-00.txt> is already
pretty new. 

ciao
hannes

---

From: Tschofenig Hannes <[email-masked]>
Date: Wed, 7 Apr 2004 11:36:42 +0200

hi robert, 

i think there is no value in changing the text since the definition itself
is (my personal opinion) not helpful anyway.

hence, my suggestion is therefore to modify a possible question regarding
sender- vs. receiver-oriented into the details of the protocol. for example,
is the data sender able to authorize a qos reservation or the data receiver?
for rsvp it was claimed that it is the data receiver since the sender does
not know how much resources the receiver will request (due to the adspec
functionality). if you defer the authorization decision a bit - after
receiving the RESV message - then again it would be possible for the sender
to provide the authorization. other proposals have been provided in the
past. 

something which matters is the following. does the qos nslp allow both the
data sender and the data receiver to provide authorization information. for
the current draft the answer is: no (using some assumptions, see below).
only the query and the reserve messages carry a POLICY_DATA object.   

my assumption is that the data receiver returns a response message (and does
not return a reserve after receiving a query) or it does not return a
reserve after receiving a reserve message. 

ciao
hannes

> Sent: Wednesday, April 07, 2004 11:20 AM
> To: Tschofenig Hannes; 'Cheng Hong'; 'Elena Scialpi'; 'nsis'

---

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 7 Apr 2004 15:29:20 +0100

A clarification: when we (I) mention 'asymmetry', 
we are not talking about asymmetry in the IP routing
(which we know happens, and we know is handled by the
message routing mechanisms in GIMPS). 

We are talking about asymmetry in the signalling protocol,
e.g. in that the two ends of the signalling conversation
may have different 'roles'. That is a point that would 
arise even if we had symmetric routing at the IP level,
in fact.

r.

> From: Thanh Tra LUU [mailto:[email-masked]]
> Sent: Wednesday, April 07, 2004 12:49
> To: Tschofenig Hannes
> Cc: 'nsis'
> Subject: Re: [NSIS] About GIMPS!
> 
> 
> hi Hannes,
> 
> i think there is no asymmetric routing here. In the mode 
> receiver-initiator,
> the recevier maintains the forward state ( Resv state in 
> RSVP). However, the
> sender must discover the data path in anycase and there in 
> only one data
> path (sender -> receiver).
> 
> Nary Tra,
> ENST, Paris.
> 
> ----- Original Message -----
> From: "Tschofenig Hannes" <[email-masked]>
> To: "'Hancock, Robert'" <[email-masked]>; "'Cheng Hong'"
> <[email-masked]>; "'Elena Scialpi'" <[email-masked]>; "'nsis'"
> <[email-masked]>
> Sent: Wednesday, April 07, 2004 11:11 AM
> > receiver-initiated reservations. the do not fit into the 
> nsis picture.
> >
> > ciao
> > hannes
> >
> >

---

From: Attila Báder (IJ/ETH)<[email-masked]>
Date: Wed, 7 Apr 2004 16:51:29 +0200

Hi Nary Tra,

I am afraid that using other transport protocol than NTLP would not be NSIS compliant. Instead NTLP should support this function, see 5.1.5 of QoS-NSLP draft:

  "The forwarding of the RESPONSE message along the path does not
   necessarily imply the existence of NTLP reverse-path state at every
   node. For example, the NTLP may have a mechanism to pass a message
   directly from the egress to the ingress of a region of QNEs that do
   not store per-flow reverse-path state."

Best regards, Attila

> Sent: Wednesday, April 07, 2004 4:30 PM
> To: Attila Báder (IJ/ETH)
> Cc: [email-masked]
> hi Attila,
> if i dont miss something, QoS-NSLP can use other protocols 
> than NTLP as a
> transport protocol (ex UDP, TCP). in the case you mention, 
> NSLP receiver (or
> any signaling entities) can directly send a message to sender (or any
> signaling entities) using  TCP,UDP, SCTP.
> 
> Nary Tra,
> ENST, Paris.
> 
> From: "Attila Báder (IJ/ETH)" <[email-masked]>
> To: "'Takako Sanda'" <[email-masked]>; <[email-masked]>
> Sent: Wednesday, April 07, 2004 1:57 PM
> > Hi Takako Sanda,
> > Yes, I think you are right, if sender would like to receive RESPONSE
> transported back by NTLP pear-to-pear, QUERY should contain 
> SESSION_ID. But
> RESPONSE can also be sent directly to sender, if sender 
> address is known by
> e.g. NSLP layer.
> >
> > Best regards, Attila
>

---

From: Tschofenig Hannes <[email-masked]>
Date: Wed, 7 Apr 2004 16:53:02 +0200

hi robert, 

regarding asymmetry of operation: i also agree that there is some asymmetry
in operation in various ways. not only end-to-end but also between
neighboring nodes. many security protocols are asymmetric (e.g., tls).

how could this observation of operational asymmetry help us for
authorization issues ( i avoid the sender- vs. receiver- initiated
reservations for a moment)? 

ciao
hannes

> Sent: Wednesday, April 07, 2004 4:29 PM
> To: 'Thanh Tra LUU'; Tschofenig Hannes
> Cc: 'nsis'

---

From: Tschofenig Hannes <[email-masked]>
Date: Wed, 7 Apr 2004 17:03:42 +0200

hi nary, 

> hi Hannes,
> 
> the asymmetric routing is mentioned in nsis requirements . so 
> i think it is
> clear here.
> 
> Is it right that routing record is not used in GIMPS ?

version -01 says that the record route has been removed (see section 9.1 -
change history; bullet 10). 

ciao
hannes

> ENST, Paris
> To: "'Thanh Tra LUU'" <[email-masked]>
> Cc: "'nsis'" <[email-masked]>
> Sent: Wednesday, April 07, 2004 4:04 PM
> > hi nary,
> > with asymmetric routes and path-coupled signaling the first message
> > (discovery) needs to be sent from the data sender.
> >
> > if you would like to send signaling messages back (from the 
> receiver to
> the
> > sender) along the same path then you need to either
> > - establish some information at each intermediate node or
> > - do something like record route
> > to allow your messages to travel back along the same path.
> >
> > ciao
> > hannes
> >
> > > hi Hannes,
> > >

---

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 8 Apr 2004 10:29:39 +0100

hi,

I think I understand this but I'll check:

An upstream RESPONSE sent via the NTLP will always
be sent peer-to-peer using the NTLP per-flow routing state.

HOWEVER what can be done in practice is quite flexible. An
example (for one scenario):

A node wishing to send such a response may be participating
in more than one signalling session for a given flow:
- a session which visits the domain-internal nodes for a particular
administrative domain, which don't store reverse path state, and
- a session which only visits domain-edge nodes, possibly for the
entire path, and these nodes do store reverse path state (pointing
to 'previous edge node')

Upstream messages can't in general be sent for the first session.

They can be sent for the second, and will use normal NTLP mechanisms
to do so. The way the routing state is set up will ensure that the
messages skip the interior nodes (and it doesn't require the NSLP
to provide e.g. sender addresses explicitly to do so).

[Conceptually, the routing state management here is nearly identical
to that which was bolted on to RSVP in RFC3175, although obviously
a lot of the details are different.]

r.

> From: Attila Báder (IJ/ETH) [mailto:[email-masked]]
> Sent: Wednesday, April 07, 2004 15:51
> To: 'Thanh Tra LUU'
> Cc: [email-masked]
> I am afraid that using other transport protocol than NTLP 
> would not be NSIS compliant. Instead NTLP should support this 
> function, see 5.1.5 of QoS-NSLP draft:
>