Subject: RE: [NSIS] framework: proposal on fragmentation

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 6 Jun 2003 10:40:47 +0200

Hi Lasse,

| The selection of NTLP-functionality may be coupled to a 
| certain NSLP-type.

This sounds like NSLP specific NTLPs. We don't need a 
layer split in that case. Like Robert, I don't support 
this proposal.

| In that case you I think that you do not need to have 
| negotiation between different
| NTLP-instances or.. ?

Negotiation of options between NTLP-instances isn't 
desireable from an operators point of view. 

I understand that at some level within the protocol stack
there must be awareness of the path MTU size. We should 
be careful not to overengineer our solution. If NSIS uses 
a transport protocol below NTLP which handles the MTU 
issue, let's make it the default. This would also simplify  
bundeling within NTLP, wouldn't it? 

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

---

From: "Lars.Westberg" <[email-masked]>
Date: Fri, 06 Jun 2003 17:00:16 +0200

The generality of NTLP is a difficutl issue. My point is that I can
forsee application that is so simple
that an UDP-style of operation is good enough.

I do not support the single-mode of operation due to my expectation of a
complec protocol standard.
I forseen that we can discuss protocol feature during long time and use
the generality argument
for all protocol feature. This will result in a very complex protcol
when the standaridzation is finished.

I would recommend that we have two modes of operation in mind:
RSVPoverSCTP
RSVPover UDP

I also recommend to partion the effort for NTLP in these "modes of
operation"

If someone want to use high-level of protocol support in NTLP => use
RSVPoverSCTP.
If someone want something simple use RSVPoverUDP.

regards Lasse

---

From: Melinda Shore <[email-masked]>
Date: Fri, 06 Jun 2003 11:27:13 -0400

> I would recommend that we have two modes of operation in mind:

We reached an agreement at the last meeting, confirmed on
the mailing list, that we'd run over a connectionless
protocol - that we would gut 2205 and 2961 and use that as
the basis for an NTLP.  If you go back and look at John's
slides from the meeting there was no agreement even to make
a connection-oriented protocol available as an option (that
is to say, no decision was made either way).  One of the
things that's killing progress in a number of IETF working
groups is the unfortunate tendency to want to go back and
revisit and revisit and revisit and revisit decisions that
we don't agree with.  We need to put a stop to that.

That said, I think that we can almost certainly put an NTLP
over a connection-oriented protocol, but that we do not want
to do this in the baseline.  Unless there's new information
today that wasn't available in March, however, revisiting
the decision that was made then seems like an incredibly bad
idea.

Melinda

---

From: Michael Thomas <[email-masked]>
Date: Wed, 11 Jun 2003 10:27:46 -0700 (PDT)

> that an UDP-style of operation is good enough.

[]

I really think it might be useful to take a more
systemic look at things on all of these
discussions. That is, what are we trying to use
NSIS for, and what are the design constraints in
that system. In isolation the notion of UDP-based
communication is good since you don't need hard
state, blah, blah, blah. My personal acid test is
in the realm of mobility and handoffs: could an
NSIS be used to gain favorable treatment of
packets on a lossy and insecure medium where fast
handoffs are necessary to keep connectivity?

The two principle things that come to my mind are:

1) Security -- rationing a scarce resource
2) Speed -- completing the allocation in a timely
            fashion so as to be useful

If either of these conditions are not met, then
NSIS is likely to not be used, opting instead for
the time-honored tradition of brute force and
ignorance, or used in a way such that the setup
time is not in the critical path. 

In this particular scenario, connectionless
transport doesn't tell the whole story; the desire
to have a command/response kind of 2 message
protocol (on the first hop, that is) is an obvious
win over needing to first need to create a
session, but the access control aspect of (1) is a
significant consideration as well. In particular,
identity credentials have a tendency to be large,
and CPU complexity especially for public key
operations tends to be high. Both considerations
push you in the direction of creating hard state
of some kind (cf IKE main mode, TCP). At the very
least, it's fairly obvious that any underlying
transport which wants to use X.509 type identities
is going to have to deal with the message
fragmentation problem, and frankly IP-layer
fragmentation is just a non-starter, IMO, if
that's the norm.

So in at least some of the interesting cases we
know that we won't be able to have our coveted
command/response protocol (assuming the MTU-pixie
doesn't wave its wand over the Internet): three or
more messages may be necessary.

Which leads us to the next questions:

1) how interesting is this case? (ie, how likely)
2) does more than 2 messages in and of itself blow 
   our time budget for (1) above?

Neither are especially clear at this point: the
deployed base of RSVP -- such as it is -- isn't
using RFC 2752 identities that I'm aware of, so
that's no help. Or maybe it's instructive... take
your pick. And (2) is highly dependent on the air
interface and its characteristics. For current 3G
cellular just about anything beyond a single
command and response for *everything* is likely to
blow your time budget, and 802.11 while better
isn't dramatically better. 

Which is to say, that it's not entirely clear that
for, oh say, VoIP with current radio technologies
intersected with access control requirements that
this is going to work well enough during handoffs
in the naive break-before-make handoff that's an
unfortunate necessity. I'm sure somebody will find
this debatable, but that's not really my point
here.

So, I'm not sure where I'm going with this except
to try to ground these discussions into some sort
of reality check of what we're trying to
accomplish here. In my particular example,
depending on how you tweak the parameters,
connectionless establishment may be a large win,
or it may be a non-starter. Also: if you believe
that X.509 or other large byte identities are
going to see widespread deployment for access
control for wireless, then it's pretty much a
given that we're going to need to deal with
transport fragmentation in a sensible (read:
non-L3) way. That in turn informs the debate
whether fragmentation based on a non-threeway
handshake protocol (tcp/sctp) is useful (or
possible, some might argue). 

Finally, finesse is required here. It's easy to
say that x.509 identities are required therefore
fragmentation trumps all. That way lies insanity,
IMO. We have to be careful to not overengineer
solutions for marginal problems. The track record
of PKI deployment is not good, so it's probably
wise to consider the case where it is not part of
the solution and provide optimization around that
design criteria.

Which is why I'm muddled about this.

	Mike