Subject: [NSIS] NSIS and NATs

From: [email-masked]
Date: Wed, 24 Jul 2002 11:19:11 -0400

Aside from the question of creating an NSIS "application" to
communicate directly with NATs, the problem of getting NSIS
*through* NATs probably needs to be considered.  Robert and
I discussed this last week and there's clearly a problem.

The problem is that pretty much by definition of what the
protocol is intended to do, there *must* be payload-embedded
addresses (the filter spec), and those create a problem for
NATs.  A NAT will translate the header and may or may not
translate payload- embedded addresses, depending on how
sophisticated the NAT is and several other factors.  Either
way, it introduces problems.

NSIS will clearly not be able to traverse an NSIS-unaware
NAT.  In fact, even low-end NATs are somewhat stateful and
if NSIS is transported in raw IP packets a NAT may examine
the packet, see that it's not UDP, TCP, or ICMP, and simply
drop it because it doesn't know what else to do. 

An NSIS-aware NAT could take several forms.  It's
increasingly common for NATs to do sophisticated stateful
inspection and payload rewrite, which introduces some
problems of its own.  In particular, 1) for it to do
stateful inspection the traffic must be in the clear, and 2)
any stateful rewrite of payload-embedded addresses will
break any integrity mechanisms that have been applied to
that object.  It also adds considerably to the complexity
and, of course, cost of the NAT device.

Rather than using stateful inspection we could use a NAT
request object that allows the application to communicate
explicitly with a NAT, effectively putting it into the NSIS
hop-by-hop path (this is the TIST proposal).  It allows NATs
to recompute integrity checks on a hop-by-hop basis, it
allows the use of hop-by-hop encryption (NATs would share
keying material) and it would allow smarter NAT table entry
allocation.  It would not, however, solve the problem of
NSIS-unaware NATs.  Nothing would, except to do something
STUN-like and I do think that would work far less well for
NSIS than it would for telephony applications, as it seems
to me that you're more likely to run into instances of
multihomed devices.

The problem of NSIS devices *behind* NATs, of course,
remains.

Melinda

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