Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-fw-05.txt

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 5 Nov 2003 23:28:12 -0000

hi melinda,

you raise an important point. i try to think of the NSIS NAT
problems in coming in two levels.

1. a NAT has (somehow) established address and maybe port mappings
for a flow. you want signalling packets to be treated by the NAT
consistently with how the flow packets are treated (but you
aren't trying to modify the mappings themselves). this includes
as one example the SIIT case (where there is no explicit per-flow 
mapping state at all AFAIK).

2. you want to be able to inspect or control mappings in the NAT
explicitly (e.g. to get an incoming flow through it, or discover
what to put in an application layer payload).

I think the direction we are going at the moment is that the 
functionality of (2) is to be handled by a special purpose signalling
application. This can get pretty complex and involve non-trivial
authorisation issues (especially where it fades into firewall 
traversal).

For the nearly-orthogonal and quite restricted functionality to 
handle (1), at the moment we are trying to make it possible to do 
this in the NTLP (at least partly for the reasons you describe). 
We could have made a design decision that
- the NAT should implement the functionality of (2), and
- the signalling application should use it to fill out its payloads
and this remains a possible approach, but I think it's overkill for 
a lot of scenarios. It might still be the right way in particularly 
paranoid security environments. Of course, we would have to be careful 
that nodes don't try to do things both ways at the same time.

cheers,

robert h.

> -----Original Message-----
> From: Melinda Shore [mailto:[email-masked]]
> Sent: Wednesday, November 05, 2003 22:05
> To: Hancock, Robert
> Cc: [email-masked]
> Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-fw-05.txt
> 
> 
> On Wednesday, November 5, 2003, at 04:46 PM, Hancock, Robert wrote:
> > well (just for example): the NSLP would invoke the NTLP with
> > - an opaque (maybe encrypted) payload (e.g. some QoS parameters)
> > - addressing information about the flow being signalled for
> 
> There are some issues here around NAT traversal that might lead
> one to conclude that the "NAT application" actually belongs in
> the NTLP.  Having a firewall/NAT NSLP is fine if you aren't
> concerned about NAT interactions in other NSLPs, like QoS (or
> anything which uses addressing information as part of the
> reservation description).  Obviously you want to avoid a
> situation in which the NTLP is peeking into, and parsing,
> NSLP payloads, and you want to avoid a situation in which
> random NSLPs must peek into a NAT NSLP (particularly if
> they're encrypted using different keys).  Reimplementing NAT
> function in every NSLP that uses addresses is also unattractive.
> 
> The first question, obviously, is how generalized you'd like
> your NAT traversal capabilities to be.
> 
> Melinda
> 

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

---

From: Melinda Shore <[email-masked]>
Date: Wed, 5 Nov 2003 18:45:28 -0500

> that nodes don't try to do things both ways at the same time.

It's actually not very complex to tag addresses and put them in the
NTLP with a "translate me" flag and put tags in the NSLP payloads.
Another advantage of doing that, aside from providing optional
support for translation of an address in any NSLP, is that you
don't have to worry about application payload rewrites breaking
integrity protection, and you don't have to deal with having
an application do a credentials exchange with both its peers and
whatever NATs may be along the path.  I think it's a lot simpler
and provides both better function and better security, but it's
certainly not what's in the framework and you might not want to
deviate at this late date.

Melinda