Subject: [NSIS] "sessions" and discovery

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 21 Oct 2002 11:59:38 +0200

hi melinda!

thank you for your comments to the casp draft.

you are right that casp separates the process of discovey and the delivery
of signaling messages. please see my comments inline:

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Melinda Shore
> Sent: Thursday, October 17, 2002 3:41 PM
> To: [email-masked]
> Subject: [NSIS] "sessions" and discovery
>
>
> I think that these are two of the most fundamental questions
> that this working group needs to resolve, and while there's
> been a suggestion to send the requirements draft through WG
> last call both of these questions, along with some other
> basic questions (like addressing) are still open.
>
> Frankly, I think that this is something that RSVP got very,
> very right and that it might be difficult to improve on it.
> In the framework draft it says that NSIS Entity discovery is
> not to be included in an NSIS protocol, and in the CASP
> draft discovery is a separate process.  What concerns me is
> that 1) it leads to a lack of robustness, and 2) it
> increases the number of messages required to accomplish a
> given task.
could you please elaborate the reasoning behind your "lack of robustness"
statement?

i am not sure whether it really increases the message count. as the draft
says if you already know your next peer (by some other means) then there is
no need to use a discovery protocol.

it however decreases the message size in comparison to idempotent messages.

in fact rsvp does not always use pure idempotent messages: for example...
- the refresh reduction rfc uses mechanisms to limit refreshes.
- if kerberos is used to establish a security association then the session
ticket might not always be included
(to optimize both performance and message size) you have to assume that you
contact the same peer (if known)

furthermore there are security issues related to this procedure. whenever
you do
not know your next peer then you might experience difficulties selecting a
security association to provide proper message protection.

>  Rerunning the discovery process every time
> route moves or a node goes down seems to me to be far less
> desirable than having discovery be implicit in the state
> maintenance mechanism.

>
> Using a stand-alone discovery process becomes more
> attractive when you have persistent, (hopefully) durable
> connections between NEs.  While I understand that the use of
> persistent connections for QoS signaling *might* have better
> scaling properties (although I'm not convinced of it), by
> rerunning the discovery protocol and then introducing round
> trips between entities it makes the system slower to respond
> to changes in the network,
we think that the discovery process makes it even faster to react on route
changes since you can have independent timers for refreshing messages and
for discovery related messages.

additionally there are different discovery mechanisms available which allow
a larger degree of freedom. in some cases you do not need to exchange
additional messages if (a) some discovery procedure is used anyway (for
example router advertisement, dhcp, etc.) or (b) if you know the next peer
(for example
based on the routing table).

>increases the amount of local
> traffic (between NEs),
idempotent messages which have their discovery mechanism built-in  also
increase the amount of
traffic.

> and *requires* an external discovery
> process.  My preference would be to look for ways to
> aggregate/multiplex messages over a protocol that looks more
> like RSVP than it would to create persistent sessions among
> NEs.
>
> There have been arguments for creating a stand-alone
> RSVP-like discovery protocol that doesn't actually convey
> requests or install state, and that's certainly what TED
> does.
from the last ietf meeting where you reported about the TED protocol i had
the impression that you like the approach.
you even mentioned that you did something like ted but with the help of
rsvp.

>  I would argue that a correctly designed RSVPv2 could
> do that very easily and is almost certainly preferable to
> separate discovery/state processes.

thank you for your comments and for starting a discussion in this area.

ciao
hannes

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

---

From: Melinda Shore <[email-masked]>
Date: Mon, 21 Oct 2002 08:26:49 -0400

> of signaling messages. please see my comments inline:

To be honest I am not very comfortable with a discussion of
CASP when 1) it is not the NSIS protocol this week, either,
and 2) neither the NSIS framework document nor the NSIS
requirements document are even close to completion.

> you even mentioned that you did something like ted but with the help of

TED could be done with an NSIS protocol (I did a version
using RSVP), and I would argue that it could be done better
than the current IKE-based implementation.  This is where
topology enters into it.  As things currently stand the
first node that receives the TED request answers it and
doesn't forward the TED message any further.  This means
that the tunnel that's created is the *shortest* possible
one.  RSVP (or something like it) allows us to find the last
appropriate endpoint and create the *longest* possible
tunnel.  I think we can improve upon TED.

Melinda

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 22 Oct 2002 09:43:19 +0200

hi melinda!

> requirements document are even close to completion.

i fully agree with you that we should keep requirements/framework
discussions separate from protocols.

i submitted my comment to your question not to start a protocol discussion.
instead i thought that it might be very helpful to discuss the security
implications of the two addressing approaches which are related to the
process of discovery. i personally think that the two lead to the same
procedure from a security perspective since you always need to know who will
process your message next to provide efficient security protection. (see
also confidentiality protection). rsvp also works this way. for the path
message this is more difficult because of its nature. for a resv message
which is backwards routed along the already pinned path selecting a security
association is not a problem. hence you can treat the path message also as a
discovery message in some sense.

ciao
hannes