Subject: [NSIS] A 3rd slightly more interesting question about the layer split (w arning: involves NATs)

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 12 Dec 2002 09:43:55 -0000

Hi All,

Here is a third question about the layer split which also comes into the 'quite interesting' category (in that the answer is not obvious, but the issues are known and relatively easy to summarise).

Should the NTLP explicitly contain flow addressing information? 
===============================================================

Background: the current framework suggests it should (sections 3.3.5 and 4.5.1), on which Melinda (msg http://www1.ietf.org/mail-archive/working-groups/nsis/current/msg01842.html, reply http://www1.ietf.org/mail-archive/working-groups/nsis/current/msg02178.html) and Bob (http://www1.ietf.org/mail-archive/working-groups/nsis/current/msg02224.html, in several places) have commented; the NSIS-through-NATs question (http://www1.ietf.org/mail-archive/working-groups/nsis/current/msg01715.html) and policy-forwarding (http://www1.ietf.org/mail-archive/working-groups/nsis/current/msg02285.html) questions are also relevant. I now think that the current framework assumption is wrong in at least minor details, but here is the summary anyway.

It's clear that messages from our protocols will be stuffed with addressing and related information (ports, flow labels etc). There are two sides to this information:
1. It defines what packets the signalling messages are about (i.e. it's an input to the packet classifier). Call this 'packet classification information' (PCI).
2. It is relevant in policy-based forwarding decisions (i.e. you need to use it to make sure the signalling messages follow the same path as data packets), and may also need to get rewritten by NATs (consistently with how they are rewriting data packet headers). Call this 'flow routing information' (FRI). Probably, the FRI is a subset of the PCI.
(I think it would be just SA+DA+[FL|(PI+[(SP+DP)|SPI])], if that isn't too terse. Maybe DSCP as well.)

It's clear (I think) that PCI could get arbitrarily complicated but is also relevant only to the signalling application, i.e. the NTLP shouldn't worry about this stuff.

The question is, should we separate out the FRI and carry it separately in the NTLP. I think this gives some benefits for some problems, although it probably isn't a perfect solution to those problems. Here is a bag of issues:

1. You could do provide NAT and policy forwarding handling for signalling applications even at nodes which were unaware of specific signalling applications. My perception is that this is a major point for us to worry about these days (was it even on the horizon when RSVP was designed?). Otherwise, deploying a new signalling application (even a simple one) would require writing NAT ALG functionality for it and getting it into every on-path device.

2. For (1) to be true, you need to ensure that *all* address information needed by a signalling application is (a) in the FRI, and (b) arranged so it can easily be processed without understanding the rest of the signalling message.
If we fail on (a), we have gained (and lost) nothing compared to carrying the information only inside the signalling application. But it seems that at least for unicast flows, achieving (a) for the majority of signalling applications is not hard. The same reasoning almost certainly *doesn't* apply to fully generic multicast handling.
I don't see (b) as a problem. Basically, the NTLP could contain a field saying 'here are some fields, treat them like you would treat the same fields in an ordinary packet header'.

3. We have to worry about the encapsulation and security issues for the NTLP to make sure that the FRI can be manipulated easily but not too easily.

4. Some people may start to use higher layer fields for NAT or policy routing which aren't in our (fixed) FRI. In that case, again we've gained (and lost) nothing. My perception however is that this is not the long-term trend (even the doom-mongers discussing IPv6 NAT scenarios are mainly talking about straight address-address mapping rather than address sharing, which is where the real problems come).

5. There are probably other issues as well.

Summary: I think we have a fairly clear tradeoff here, between
COST: some additional complexity in the NTLP, making signalling applications dependent on some NTLP data fields
BENEFIT: for a one-off cost we can handle a high proportion of nat/policy problems for a high proportion of [unicast] signalling applications. ('high proportion' may or may not be 100%.)

How do people see this tradeoff?

Cheers,

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