Subject: RE: Session-ID in GIMPS (was: RE: [NSIS] Re: Session in NSIS)

From: Attila Báder (IJ/ETH)<[email-masked]>
Date: Mon, 23 Feb 2004 15:36:40 +0100

Hi Robert, 

In case of bi-directional reservation they must known it, or the flows should be the same session ID, is not it?

Attila

> 
> This would be the normal mode of operation, but I don't think 
> we can be that prescriptive about how session-ID is interpreted.
> examples:
> 
> a) there is a flow from S to R, and some reverse routing state
> already exists to get signalling from R to S. Both S and R want
> to make reservations for the flow, but neither knows the S-ID
> that the other will use. Consequence: two reservations. (Another
> way of putting this: in your phrase "must represent a flow which
> is not established in the network", how would a node ever be able
> to ensure that a flow was not established in the network? This
> is information it could never know.)
> 
>

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.

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

---

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 23 Feb 2004 14:36:41 -0000

hi attila,

in the case of bi-directional reservations *as defined in
the QoS-NSLP* you have a particular message flow where
*) it's clear how both ends find the same ID [or at
least I hope it is], and
*) the QoS-NSLP spec actually defines that the Session-ID
should be the same.

In other words, it depends on the particular NSLP you are
talking about. It's hard to make general statements about
the session ID.

hope this helps,

robert h.

> -----Original Message-----
> From: Attila Báder (IJ/ETH) [mailto:[email-masked]]
> Sent: Monday, February 23, 2004 14:37
> To: Hancock, Robert; 'Thanh Tra LUU'
> Cc: 'nsis'
> Subject: RE: Session-ID in GIMPS (was: RE: [NSIS] Re: Session in NSIS)
> 
> 
> Hi Robert, 
> 
> In case of bi-directional reservation they must known it, or 
> the flows should be the same session ID, is not it?
> 
> Attila
> 
> >

---

From: Attila Báder (IJ/ETH)<[email-masked]>
Date: Mon, 23 Feb 2004 15:48:25 +0100

Hi Robert, 

Yes, thank you that is what I wanted to point out,

Best regards, Attila

> From: Hancock, Robert [mailto:[email-masked]]
> Sent: Monday, February 23, 2004 3:37 PM
> To: Attila Báder (IJ/ETH); 'Thanh Tra LUU'
> Cc: 'nsis'
> -- 
> 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: "Hancock, Robert" <[email-masked]>
Date: Tue, 24 Feb 2004 08:49:36 -0000

hi cheng,

<Snip>
> > 
> > Session-ID is as global as the NSLPs make it. Typically, I 
> > assume it will be valid along the entire path. (This does not 
> > mean that 
> > there can be only one for a given flow.) There might also be 
> > reasons why the session changed mid-path (e.g. to interwork 
> > between sender- and receiver-initiated signalling paradigms 
> > at a proxy node.) It all depends on the NSLP.
> > 
> > r.
> 
> If the NSLP decides how global the Session-ID is, could we say that
> Session-ID could only be unique within the specific NSLP space? 

that is one possible consequence. however, at this stage i would 
not like to formalise it in this way. specifically:
- the Session-ID is never unique (under any conditions), it is
  only probabilistically unique
- it is just as easy to ask it to be probabilistically unique
  over the whole NSIS space as over a single NSLP space

making statements about how the Session-ID space relates to 
different NSLPs might have some impacts on NSLP-NSLP interactions
(at the moment we are ignoring these but it doesn't mean they
don't exist). i'd rather leave it unspecified than overspecify it.

> It means the
> different NSLP applications could choose different session ID 
> value for the same flow, 

this could certainly happen, especially if the 'initiators' for
the two NSLPs were on different nodes (e.g. one was a proxy).
they would just have no way to synchronise their use of the 
Session-ID value.

> and use the same session id for unrelated flows?

this could happen by coincidence (e.g. 1 time in 2^128). I would
rather not encourage it, but i do not immediately see what the
practical impact would be.

robert h.

> Best regards
> Cheng

---

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 24 Feb 2004 11:29:44 -0000

hi,

> From: Thanh Tra LUU [mailto:[email-masked]]
> Sent: Tuesday, February 24, 2004 10:58
> To: Hancock, Robert
> Cc: 'nsis'
> Subject: Re: Session-ID in GIMPS (was: RE: [NSIS] Re: Session in NSIS)
> 
> 
> hi robert,
> 
> I don'n mention how to create a global SESSION_ID (e.g. random)  here,
> supposing that there are some ways to do it.  in case of bidirectional
> reservation, if these are two indenpendent reservations, it is easy, you can
> take two different SESSION_IDs. NTLP can not know the relation between two
> reservations. If two reservations are not independent, there must be some
> mechanism to know it (off path signaling, aller-retour (reservation S to R
> and then R to S or vice versa)...).

i think we're in agreement here ...

> 
> > b) at the GIMPS level you receive two discover messages for the
> > same flow but from different directions (different peers). This
> > might be for several reasons (some legitimate, some malicious);
> > GIMPS uses the Session-ID to separate the routing state for each.
> 
> i don't understand what flow you mean. For me, the flow from S to R and the
> flow from B to A are different.
> At NTLP level, if it receives two messages for the same flow but from
> different directions (different peers) and IF it knows the routing is
> symmetric, the route discovery is not necessary.

i'll try again:

there is a source address for a flow S, and a destination address R.
somewhere in the middle of the network, there is a GIMPS node G.
it receives a downstream signalling message claiming to be about S-->R
from one peer G1 through one interface with session-ID SID1; and it
receives another downstream signalling message claiming to be about
S-->R from another peer G2 through another interface with session-ID
SID2.

it may be possible for GIMPS to work out to reject one of the messages
on security grounds. however, if this is not possible, the different
SIDs can still be used to prevent the two sets of routing state 
corrupting each other.

> 
> > > otherwise, if i misunderstand your idea, do you mean 
> session-id is not
> > > global ?
> 
> > Session-ID is as global as the NSLPs make it. Typically, I assume
> > it will be valid along the entire path. (This does not mean that
> > there can be only one for a given flow.) There might also be reasons
> > why the session changed mid-path (e.g. to interwork between sender-
> > and receiver-initiated signalling paradigms at a proxy node.) It
> > all depends on the NSLP.
> 
> i agree.

phew!

robert h.

> Nary Tra,
> ENST, Paris