Subject: [NSIS] New NSIS-related drafts

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 17 Sep 2002 09:28:53 -0400

We have prepared a set of drafts that describe an attempt at a layered 
signaling protocol, called CASP.

The basic protocol architecture is described in

http://www.ietf.org/internet-drafts/draft-schulzrinne-nsis-casp-00.txt
http://www.ietf.org/internet-drafts/draft-schulzrinne-nsis-casp-00.pdf

while the first client layer, for resource management, is described in

http://www.ietf.org/internet-drafts/draft-schulzrinne-nsis-casp-qos-00.txt
http://www.ietf.org/internet-drafts/draft-schulzrinne-nsis-casp-qos-00.pdf

We're currently working on a midcom client.

We would very much appreciate feedback. The drafts intentionally take a 
somewhat different tack than "classical" RSVP, with its own set of 
trade-offs. Our main goal was to provide a generic toolbox that avoids 
making policy decisions. For example, we take no position on sender vs. 
receiver-initiated reservations. We also separate the notion of finding 
NSIS/CASP nodes from the actual protocol, so that the 
in-band/out-of-band distinction becomes largely an operational, not a 
protocol, decision.

We built on Bob Braden and Bob Lindell's idea of splitting a base 
signaling layer from the signaling application.

We believe that the two drafts, in combination, are satisfying the 
requirements laid out in the NSIS requirements draft.

We haven't worried too much about the packet format at this point.

Thanks for feedback and comments.

Henning
(for the CASP team)

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

---

From: Melinda Shore <[email-masked]>
Date: Tue, 17 Sep 2002 10:18:32 -0400

One thing that pops out in a quick first scan of the
document isn't an issue that's peculiar to CASP but is
something that I think NSIS needs to consider, and that's
failure modes.

If an interesting node along the path fails to process an
NSIS or CASP (or, indeed, RSVP) message, the results can
be unfortunate but not catastrophic, or catastrophic (in the
sense that it causes the path to fail).  An "interesting
node" is one that should process and respond to the request
(i.e. a router for a QoS request, a firewall for a firewall
request, etc.) but that doesn't support the request
protocol.  That is to say, it won't honor the request but it
won't send back a message to the originator saying that it
won't honor the request.  If it's a QoS request it's
probably not going to be catastrophic, unless the network is
tightly engineered and running near capacity.  

The only example I can think of where a failure to process +
a failure to respond == catastrophe is firewalls, but that
is something to consider when designing a protocol that
might be used for middlebox communication.  In RSVP, a
failure to get any reply back at all can be considered a
negative response, and RSVP is a good example of a protocol
that's not likely to be passed through firewalls, so it will
probably work correctly in most cases.  A TCP-based protocol
almost certainly will pass outbound through most firewall as
they're currently configured and run, and a UDP-based
protocol may, as well.  SCTP will probably be treated like
TCP as it becomes deployed.

What would be ideal in a protocol to be used to communicate
with firewalls is protocol machinery that fails if a given
firewall along the path that is not {NSIS,RSVP,CASP}-capable
drops the {NSIS,RSVP,CASP} request rather than passing it
along.  It's not something that can be designed in and
guaranteed, but the probabilities can be jimmied.

Melinda

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 17 Sep 2002 11:13:47 -0400

Interesting observation. From a CASP perspective, it would likely be the 
scout message that would fail to traverse the firewall, as it would use 
UDP (or maybe ICMP). Thus, the interior CASP node would never see the 
exterior one, unless the firewall has been properly primed.

In general, I don't think it is possible to guarantee the property "if a 
signaling message goes through, the corresponding data will, too" unless 
the two cannot be distinguished - which tends to rule out anything but 
the null protocol.

As you say, we can improve the chances of failure detection, but I don't 
think we want to choose protocols based on their *un*likelihood to 
traverse firewalls...

---

From: Melinda Shore <[email-masked]>
Date: Tue, 17 Sep 2002 11:30:01 -0400

> the two cannot be distinguished - which tends to rule out anything but 

Absolutely, and VoIP is a case where we can pretty much
guarantee that it won't (an endpoint or gatekeeper receives
a SETUP message and wants to open a firewall pinhole to
allow an *incoming* H.245 channel).

> think we want to choose protocols based on their *un*likelihood to 

Of course, but I think it's important to be aware that if is
to be used for middlebox communication there are some
changes to the landscape.  For example, we need to start
worrying about topology (where is a NAT in relation to other
devices we're trying to influence?) and think about
mitigations to accomodate other failure possibilities.  For
example, what do you do if the outermost NAT with respect to
the two ends of a CASP path doesn't speak CASP?  That's
pretty easy, actually - you have the "receiver" CASP node
add information about what address it sees.  That is,
however, a protocol change and something that you almost
certainly would not do if you 1) weren't worried about NATs,
and 2) weren't worried about failures due to
non-CASP-capable elements along the path.

Melinda