Subject: [NSIS] Session in NSIS

From: "Elena Scialpi" <[email-masked]>
Date: Thu, 19 Feb 2004 12:15:20 +0100

Hi all,

In RFC 2205 (http://ietf.org/rfc/rfc2205.txt?number=2205) a RSVP session is defined as "a data 
flow with a particular destination and transport-layer protocol" and it "is defined by the triple: 
(DestAddress, ProtocolId [, DstPort])"

NSIS framework (http://www.ietf.org/internet-drafts/draft-ietf-nsis-fw-05.txt)  defines session as 
"application layer flow of information for which some network control state information is to be 
manipulated or monitored".

Session_ID is a random number but which parameters can be used to represent a session?

Regards,
Elena 

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

---

From: Tschofenig Hannes <[email-masked]>
Date: Thu, 19 Feb 2004 13:01:40 +0100

hi elena, 

in nsis the concept of a session is separated from the flow identifier. the
advantage of this approach is also visible in many of the nsis mobility
drafts. you can find the latest version (a merge of previous drafts) at:
http://www.tschofenig.priv.at/drafts/draft-manyfolks-signaling-protocol-mobility
-00.txt

you might also want to take a look at :
http://www.tschofenig.priv.at/drafts/draft-tschofenig-nsis-sid-00.txt

this draft describes alternative ways to create the session id with security
properties.  

as a summary, the session id allows you to change the flow identfier
- during the lifetime of a session (e.g., due to mobility, IPv6
privacy,...),
- somewhere along the path and 
- to group different flows together

does this answer your question? 

ciao
hannes

> -----Original Message-----
> From: Elena Scialpi [mailto:[email-masked]]
> Sent: Thursday, February 19, 2004 12:15 PM
> To: nsis
> Subject: [NSIS] Session in NSIS
> 
> 
> 
> 
> Hi all,
> 
> flow with a particular destination and transport-layer 
> protocol" and it "is defined by the triple: 
> NSIS framework 
> (http://www.ietf.org/internet-drafts/draft-ietf-nsis-fw-05.txt
> )  defines session as

---

From: Tschofenig Hannes <[email-masked]>
Date: Thu, 19 Feb 2004 15:27:11 +0100

hi elena, 

~ snip ~ 

> 
> I haven't understand very well the concept of session. 
> I think that a session is between two specific nodes (sender 
> and receiver of signaling)  while in 
> RSVP it consider only one node.
> Is it right?

not quite. the session id remains the same over all traversed nsis entities
along the path. you can compare this with figure 1 (of the nsis framework
draft).

   Sender                                               Receiver 
   +-----------+      +----+      +----+      +----+      +-----------+ 
   |Application|----->| R1 |----->| R2 |----->| R3 |----->|Application| 
   |   +--+    |      |+--+|      |+--+|      +----+      |   +--+    | 
   |   |NE|====|======||NE||======||NE||==================|===|NE|    | 
   |   +--+    |      |+--+|      |+--+|                  |   +--+    | 
   +-----------+      +----+      +----+                  +-----------+ 
    
      +--+ 
      |NE| = NSIS      ==== = Signaling    ---> = Data flow messages 
      +--+   Entity           Messages            (unidirectional) 
                 Figure 1: Simple Signaling and Data Flows 

in figure 1 all NEs use the same session id. it is not modified. let's
assume that R1 is a NAT then the flow identifier is modified but the session
id remains the same. 

in rsvp there was no requirement to support mobility (or similar
functionality which causes a flow id modificiation). hence there was no need
to introduce a separate identfier and only the flow identifier was used. in
nsis we use both - the flow identifier and the session identifier. both
identifiers carried via nsis signaling along the path between the ni and nr.

does this make more sense? 

ciao
hannes

> Thanks for your reply,

ciao
hannes

---

From: "Elena Scialpi" <[email-masked]>
Date: Thu, 19 Feb 2004 17:41:19 +0100

Thanks for your comments!
I have understand session and session_ID concept but I have an other question.
In your opinion, which elements are useful in a Session class?  
It's a detail, but I'd like to know your opinions!

Many thanks,
Elena

---

From: Tschofenig Hannes <[email-masked]>
Date: Fri, 20 Feb 2004 12:54:15 +0100

hi cheng, 

if the nsis initiator creates the sid then the other nodes receive the value
as part of regular nsis signaling. no application signaling is involved. the
difficulty with a cryptographically generated session id is that in many
cases only the creator of the sid is able to start signaling (and not
intermediate nodes as sometimes required by nsis mobility optimized
solutions).

in the nat/fw nslp we, however, found a scenario (receiver behind a nat)
where you could (as one possible solution) signal the sid via sip (as one
example). we that that this might be a deployment problem and hence
considered a different approach which is explained in the nat/fw draft. 

we mentioned it also at the last ietf nat/fw presentation (see "reserve mode
of operation approaches" slide)
http://www.tschofenig.priv.at/nsis/IETF58/NAT-FW-NSLP_ietf58.ppt

ciao
hannes

> From: Cheng Hong [mailto:[email-masked]]
> Sent: Friday, February 20, 2004 12:03 PM
> To: 'Thanh Tra LUU'
> Cc: 'nsis'
> Subject: RE: [NSIS] Re: Session in NSIS
> 
> 
> Hi Nary,
> 
> Does this mean that the SIP or other types of signaling has be used in
> conjunction of the NSIS signaling to achieve the NR SID 
> generation? Wouldn't
> it be a bigger issue?
> 
> Cheers
> 
> Cheng Hong
> 
> > From: Thanh Tra LUU [mailto:[email-masked]] 
> > Sent: Friday, February 20, 2004 6:39 PM
> > To: Cheng Hong
> > Cc: 'nsis'
> > Subject: Re: [NSIS] Re: Session in NSIS
> > 
> > 
> > hi Cheng Hong,
> > 
> > > It is not necessary that the NI always be the mobile. Also, 
> > wouldn't 
> > > the computation cost just an implementation issue? If it is that 
> > > computational intensive, could it be placed into certain 
> hardware, 
> > > e.g. some smart card?
> > >
> > > Another issue for NR generating the id would mean that the first 
> > > message sent from NI would not carry the SID information. 
> Does this 
> > > have any
> > impact
> > > on the design of the protocls?
> > 
> > i think it maybe a problem. Seeing NAT/FW, NI and NR can 
> > initiate its own session
> > 
> >  NI ---> NAT/FW_I ----> Internet---->NAT/FW_R---->NR.
> > 
> > NR can initiate the signaling session and some states are 
> > established on NAT/FW_R to permit NI can send signaling 
> > message to it. This session-id is sent by SIP or other means.
> > 
> > Nary Tra,
> > ENST, Paris.
> > 
> > 
> > 
> > 
> 
> 
>

---

From: Tschofenig Hannes <[email-masked]>
Date: Fri, 20 Feb 2004 13:57:23 +0100

hi Nary Tra, 

~snip~

> 
> i agree. in any case, session-id does not give enough information for
> authentication, authorization. however, how to use the session-id for
> re-authentication and re-authorization is not clear now :o)

true. i think that the reason for this is that the mobility handling is not
fully specified and needs more discussions. once the expected signaling
behavior is clarified it would be useful to take a look at the proposed
security mechanisms again and to provide some text for the individual nslps.

ciao
hannes

> ENST, Paris

---

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 23 Feb 2004 10:34:08 -0000

Elena,

I'm sorry but I don't really follow your question. The 
phrase 'session class' doesn't appear in either the
framework or NTLP documents, which makes it difficult
to work out what the elements could really be ...

Maybe you could give a bit more context to what you
are really asking about.

cheers,

robert h.

> Sent: Thursday, February 19, 2004 16:41
> To: hannes.tschofenig; luu; nsis
> Subject: RE: [NSIS] Session in NSIS
> 
> 
> 
>