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

[Hannes Tschofenig <[e-mail]>]

Hi Henning,

thanks for your comments. Please find my response below:

Henning Peters wrote:
> 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).

I agree.

> 
> 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.

The counter argument is the following: Why should someone use GIST NAT 
traversal when in relationship to the NATFW NSLP?
Problems show up when the QoS NSLP suddenly starts to use a proxy mode 
configuration similar to the NATFW NSLP.

I personally, however, think that the introduction of the port numbers 
into the LE-MRM would be cleaner.

> 
> 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.

I agree.

> 
> 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.

I don't think that the LE-MRM can only be used for NAT scenarios. In a 
firewall scenario an applicability statement is appropriate to deal with 
multi-homed networks.
> 
> 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).
> 
> 
I agree.


> 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?
> 
I think that the NR should be required to have as little information as 
possible.

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

The problems particularly show up when the QoS folks decide to use the 
LE-MRM for a proxy solution.


> 
> 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/


Ciao
Hannes

> 
> Thank you for your attention,
> Henning Peters
> 
> 
> _______________________________________________
> nsis mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/nsis
> 
> 


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