[NSIS] NAT/Firewall NSLP LE-MRM/DTINFO concerns

["Henning Peters" <[e-mail]>]

Dear WG, dear NAT/Firewall NSLP authors,

NAT/Firewall NSLP is a quite stable and usable protocol. There is running
code already available that covers broad aspects of its functionality.
This proves at least that from an complexity and functional viewpoint it
can be considered feasible. Still, I find that some parts of the spec can
be improved. Here, I would like to present my concerns connected to
LE-MRM/DTINFO that I developed during working on our implementation.

shortcut: the questions related to WG discussion are at 4).

1) Confusing directions

Most notable, the directions are a bit confusing in this object. src port
is data sender (DS) port, dst port is data receiver (DR) port. DR port is
subject of rewrite, whereas DS port specifies the data sender. I would
appreciate avoiding the term source and destination in this context, this
would also leverage the positioning issue (see later *** when discussing
the message format that confusely destination port is positioned before
source port).

Anyway, I will refer to DS port and DR port in the following.

2) LE-MRM / DTINFO ports

After introduction of LE-MRM (loose end message routing method) to the
spec last year it was found that NAT traversal in NAPTs is broken as
LE-MRM does not carry port information. Ports are considered as not part
of GIST routing and therefore omitted from MRI.

To compensate this DTINFO object was enhanced later with the port
information that was previously accessable in PC-MRM (signaling the wrong
way) MRI. I believe that the current approach is not a good design
decision as GIST NAT traversal would be rendered broken. GIST NAT
traversal is crucial as we cannot assume a domainwide deployment of
NAT/Firewall NSLP instantly. I would appreciate a deployable over a 100%
clean solution as deployment will be very crucial to NAT/Firewall NSLP
success anyway.

See Martin's and my discussion in the issue tracker:
https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/issue50

Actually, only the DR port and protocol field is needed for NAT traversal
as REA/LE-MRM needs only a one-sided translation.

3) DTINFO message format

The message format of the current solution is a bit confusing and lacks
IPv6 support (DTINFOv6 object was removed in previous draft). Let me start
with its figure:

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |I|P|S|    reserved             |   dest prefix |    protocol   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(***):      dst port number [DR]     |      src port number [DS]     :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                            IPsec SPI                          :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  data sender's IPv4 address                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The purpose of this object is two-fold:

- specify data sender during REA (aka: the cone-ness of the NAT)

- supply DR port/protocol for NAT traversal

Unfortunately, the draft heavily mixes and overloads these two different
semantical aspects in this object. Specifically, I see following issues:

a) The P flag specifies whether port numbers are present or not. This
means that either both ports are present or none. Confusely, DR port and
DS port cover different semantic aspects:

DS port specifies the data sender, DR port is necessary for NAT traversal.
A single flag to enable/disable two fields with different semantical
meaning can be problematic.

b) The I flag specifies whether the protocol field should be interpreted
or not. The protocol defines the protocol used for above mentioned ports
if the P flag is set aswell. Although the ports are of different
semantical meaning, the protocol covers both equally.

I am not sure whether this semantical overloading may introduce new
problems, at least this limits flexibility compared to PC-MRM case where a
protocol can be set in MRI and in DTINFO independently.

c) DTINFO object might be used for firewall signaling scenarios. But
LE-MRM can only cover NAT-only scenarios. That means that the NR has to
know the scenario in advance to choose between PC-MRM and LE-MRM
signaling. The more intelligence is put into NR the more it evolves to a
probing NR.

A probing NR sounds to me a bit like the situations BEHAVE working group
deal with; this is not the situation I would like to see NAT/Firewall NSLP
in. I think that our network states can be used more flexibly to assist
the NR better. The NR should not care about the network, but only give the
definitions that the network should adapt to.

Surely, this is a design decision that needs WG consensus.

d) DTINFO object MUST be included when using LE-MRM as NAT traversal is
not possible as long as DR port is not available. Therefore, following
paragraphs might need correction:

> The NI+ MAY include a NATFW_DTINFO_IPv4 object in the REA message
> when using the LE-MRM.  The LE-MRM does not include enough

also:

> When the data sender's address information is known in advance the NI+
> MAY include a NATFW_DTINFO_IPv4 object in the REA message (as described
> above).

4) I hope I pointed out that a discussion of following points in the WG is
necessary:

- How much intelligence should have the NR -> shall the network handle the
deployment sceario or should the NR know/probe the network scenario?

- Is a broken GIST NAT traversal worth giving up a 100% clean MRM design?

The message format issues heavily depend on these discussions, therefore I
would rather like to delay the message format design until both questions
gained consensus.

I also appreciate any feedback on our NAT/Firewall NSLP implementation
available at:

http://user.informatik.uni-goettingen.de/~nsis/

Thank you for your attention,
Henning Peters


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