Subject: Re: [NSIS] session ID

From: [email-masked]
Date: Thu, 13 Feb 2003 16:16:52 +0100

Hi Melinda,

Thanks for your reply. Please see my comments inline.

Sven

Melinda Shore <[email-masked]>@ietf.org on 13/02/2003 16:00:44

Sent by:    [email-masked]

To:    Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL
cc:    [email-masked]
Subject:    Re: [NSIS] session ID

> 2. A question that comes to mind is whether the session ID would belong
in
> the NTLP or in the NSLP.

It seems clear to me that it's not an either/or question.
There's a question about whether or not the NTLP needs a
session identifier for its own purposes, and that question
is independent of the question of what an NSLP would need.

[Sven] OK. The question in that case should be rephrased as: does the NTLP
need a session ID in addition to the NSLP's session ID and if yes what for.
I have the impression the session ID is always tied to NSLP state.

Aside from that, in general I'm not overly fond of
overloaded functionality in protocols.  I believe there's a
good case to be made for a session/flow/what-have-you
identifier in the NTLP to simplify state management (imagine
a case where you've got two different NSIS applications, say
QoS and firewall, manipulating state for one data flow).

[Sven] At the interim meeting we discussed about lower/upper layer
correlation and agreed we would limit any awareness of the coupling to the
end (edge) nodes (at least for now)

It may also simplify message processing in cases where an
NSIS-capable device doesn't support a particular NSIS
application.

[Sven] Can you elaborate? The session ID is meant to identify existing
session state in order to avoid e.g. double reservation. If the
intermediate node has no NSLP (for that application) it does not maintain
its application state and hence doesn't need the session ID.

Additionally, there may be differences in semantics.  I
would not like to see an NSLP session identifier constrained
in its semantics by the NTLP layer.  There may be issues
around grouping, etc.

[Sven] Browsing through my interim meeting notes I found that of the three
options we discussed
- randomly generated session ID (globally unique enough to prevent random
collisions)
- cryptographically random (first + known only to participating nodes)
- purpose-built keys (or similar asymmetric cryptography)
the middle one was prefered because the incremental cost was minimal for a
relevant additional benefit. In the case of (near) global uniqueness, would
you be able to easily aggregate session IDs?

Melinda

_______________________________________________
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: Melinda Shore <[email-masked]>
Date: Thu, 13 Feb 2003 10:38:22 -0500

Well, obviously I'm missing a lot of context because I was
not at the meeting and minutes have not been published.  I
haven't seen any decisions about layer split on the mailing
list, which is where decisions are made.

Clearly much will depend on the general approach to state
management.  There's still the question of whether an
RSVP-like soft state approach to state management will be
used or whether there will be persistent "connections"
between nodes.  I would not ask if the NTLP needs a session
ID in addition to the NSLP's, but rather if the NTLP needs a
session ID.  There may, in fact, be NSIS applications which
on their own don't require a session ID.  

I think it's very important, when talking about what to put
where and how to manage state, to remember that we're
talking about a fairly large number of potential
applications with potentially very different semantics,
whether it's something like tunnel endpoint discovery
(query/response, no persistent state), NAT (persistent
state, you need to find the outermost device), QoS
(persistent state, topology information is a generally less
important feature of the protocol), monitoring/testing
(query/response, topology is interesting but not the primary
concern), and so on, and that these applications may be
running across the same nodes at the same time and may be
trying to control policy on the same stream.

Melinda

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 13 Feb 2003 10:51:45 -0500

> between nodes.  I would not ask if the NTLP needs a session

I think there is general agreement that this is not an "or", but an 
"and". As was discussed at the meeting, the use of persistent 
peer-to-peer connections does not at all contradict a soft-state model.