Subject: [NSIS] Review of NTLP proposals

From: [email-masked]
Date: Fri, 11 Jul 2003 11:49:47 +0300

Hi all,

I asked Brian Carpenter to look over the NTLP proposals, in preperation
for Vienna.

Here is is quick review.

br,
John

> I see these as partly complementary and partly competing. Henning
> gives more of an overview whereas Melinda gives a first cut at
> a detailed spec. The question is whether the requirements implied
> by Henning can be met by morphing the details proposed by Melinda,
> or whether the distance is too great and you really have two
> irreconcilable drafts. I'm not sure about that. I certainly think
> Henning is correct to consider using either a reliable transport
> or not; everyone who tries to bypass TCP ends up partially
> recreating it. There's not the slightest reason Melinda's TLVs
> couldn't travel over TCP or SCTP. The killer overhead is likely
> to be crypto in any case.
> 
> I think there is scope for combining the two efforts but that
> would need the two authors to agree on the implied requirements
> and on the point about the transport layer. (I do agree with
> Henning that it's a misnomer to call this thing a transport layer.
> Better to call it what it is, a session support layer.)
> 
> Now a few specific comments on each draft:
> 
> draft-shore-ntlp
> 
> A classical TLV approach. If we accept the basic parameters of NSIS
> this is the "obvious" way to go. (I don't mean to trivialize the work
> by writing this, but this is the traditional approach and the details
> hardly matter at this level of discussion).
> 
> I'd like to see some specific discussion of NAT-PT traversal 
> and how it
> will work in this scenario and in IPv6-in-IPv4 tunnel scenarios.
> 
> I'm worried by the complete lack of security analysis at a stage when
> basics have been set. Without the threat model I have no idea whether
> there is a problem.
> 
> How does it work in SCTP or multihoming scenarios when 
> multiple IP addresses
> may be involved? Do we assume that each time the path 
> changes, NTLP is back to
> square one?
> 
> draft-schulzrinne-nsis-ntlp (gimps)
> 
> This is still an abstract protocol description with details 
> to be worked out.
> 
> > GIMPS can operate over any message or stream-oriented 
> transport layer, 
> > including UDP, DCCP, TCP and SCTP. [TBD: support raw IP?] 
> 
> I like. This feature is better than draft-shore, but 
> multihoming should
> also be discussed.
> 
> >     Proxy support:
> > The end systems in a session may not be capable of handling 
> either the 
> > signaling transport or the application and may instead rely 
> on proxies 
> > to initiate and terminate signaling sessions.
> 
> This is also a good feature, but the absence of NAT considerations is
> a major shortfall.
> 
> As with draft-shore, I'd like to see discussion of mixed 
> IPv4/IPv6 scenarios.
> 
> I'm glad to see the security discussion but very concerned 
> about the performance
> implications of crypto protection on a hop by hop basis. As 
> for other fields
> that need to be examined at every hop, crypto calculations 
> may simply be
> out of the question.
> 
>    Brian
> 
> 
> 

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 12 Jul 2003 16:32:57 -0400

Brian, thanks for your comments. Mostly questions in-line.

>>Better to call it what it is, a session support layer.)

I still think we're doing messaging at the core, from hop to hop, each 
with its own properties. I agree that the transport name evokes 
similarities that aren't apt - we are not building a multi-hop transport 
mechanism with intermediaries, but rather a chain of 
application-appropriate hop behavior.

>>I like. This feature is better than draft-shore, but 

I wonder (in general) whether multi-homing and mobility are close 
cousins in this area. Can you identify how "source or destination uses 
different network layer addresses" and "source or destination changes 
network layer addresses" differ? Is one the more general version of the 
other or do we need to treat them separately? I think multihoming is a 
topic that has received almost no discussion in this group, while 
mobility has.

>>This is also a good feature, but the absence of NAT considerations is

To be added. There seem to be two types of NAT behaviors: NTLP-aware 
NATs that can munge bits

>>As with draft-shore, I'd like to see discussion of mixed 

Can we constrain the transition mechanisms or should all be covered?

>>that need to be examined at every hop, crypto calculations 

This is clearly optional, but I don't see why symmetric crypto, as in 
IPsec or TLS, would be a big deal for anything but the multi-hundred 
Mb/s signaling channel. I agree that having to do key exchange for every 
session, with its public key operations, is likely to be a bear, so 
'restart' (for TLS) is a minimum.  As Michael Thomas has pointed out, 
this may not be a mode we need all that much, although I can think of a 
few cases where transport integrity protection would be useful, as they 
might be significantly cheaper than message-based (NSLP) crypto like CMS 
operations. One such example is network diagnostics where the querier 
wants to keep the results private from external listeners, but doesn't 
want to configure shared secrets in all routers.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 13 Jul 2003 11:35:20 +0200

below...

> topic that has received almost no discussion in this group, while

Well, Mobile IP is certainly in the set of solutions that don't quite
solve the multihoming problem (excuse the sarcastic tone, but we really
do have a challenge in meeting all the conflicting requirements for
multihoming, hence the churn in the multi6 WG). So there is linkage, but
the scenarios are not isomorphic.
> Can we constrain the transition mechanisms or should all be covered?

All is at least twelve mechanisms, so I don't think you want to go there.
But at least the basic dual stack, IPv6-in-IPv4 tunnels, and ugly NAT/PT 
could be covered.
> want to configure shared secrets in all routers.

In any case I think you need to discuss whether crypto overhead is
a significant concern. Also whether IPSEC flows can actually get
useful benefit from an NSIS environment which they can't get from RSVP).

   Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 13 Jul 2003 05:40:34 -0400

> the scenarios are not isomorphic.

You're extrapolating :-) I wasn't specifically talking about mobile IP, 
but the general problem that a node changes IP addresses (which mobile 
IP may then hide from, say, TCP). For example, in some versions of 
application-layer mobility, there is no mobile IP at all, but rather, 
changes in IP address are signaled at the application layer. At least 
with binding updates, the path would change.

> useful benefit from an NSIS environment which they can't get from RSVP).

Your comment seems to reflect a view of IPsec as an NSIS *user*; I was 
thinking of the inverse - NSIS as an IPsec (or TLS) user to protect the 
upper-layer signaling information from intercept and modification.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 13 Jul 2003 12:59:25 +0200

> with binding updates, the path would change.

Certainly. SCTP is fun to think about in a multihoming world.

> upper-layer signaling information from intercept and modification.

Both ways round are interesting.

   Brian