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

Hi Henning,

Am 21.04.2006 um 22:06 schrieb Henning Peters:

> 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

Good to hear that!

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

Comments and suggestions are always welcome.

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

While the naming is technically correct, I have to admit that it is  
confusing.
So, I would suggest to change the names directly to what you have
proposed: 'src port' -> 'DS port' and 'dst port' -> 'DR port'. This  
is then
inline with the naming of 'data sender's IP address' in the same object.

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

There are two things to differentiate: NAPT support is not broken in the
NATFW NSLP and whether NAPT traversal of GIST is broken when using
LE-MRM is a different story that depends on the view point.

My concern here is about why we need a GIST/LE-MRM NAPT traversal
mechanism? When there is a NAT on your side of the network that is
not NATFW NSLP enabled you anyway need to fall back to all the
other workarounds, such as STUN, TURN, or other tricks.

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

There is non compensation needed, because GIST carries all information
necessary for the message routing and the DTINFO object carries
information about the later expected data flow. That are basically two
different things: The message routing information and the expected
data flow.

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

I do not see the applicability given for the GIST with LE-MRM and NAT
traversal. I probably need a good example why it is needed.

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

The DTINFO_IPV6 object has been removed since there is no IPv6 NAT
and the usage of NAT-PT seems to be deprecated.

>
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |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 makes sense to either enable usage of ports or not. However, if ports
are enabled you still can wildcard the DS port. This makes some sense
from the point of whether your policy rule to be installed in the device
covers port numbers or not.

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

DTINFO and PC-MRM cannot be used at the same time. *BUT* this is
not specified in the draft :-)
I will fix this.

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

Right, NR needs to choose carefully in what scenario it is. But the  
DTINFO object
is not useful in firewall only scenarios, since those messages are  
anyway
carried using the PC-MRM.

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

I would prefer a different way of deciding whether the NR is NATed or
firewalled only. However, until now there has been now good proposal
how to avoid this. Suggestions are welcome.

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

Already noted this.

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

As said, I'm open for suggestions!

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

I still lack the real usage scenario for GIST with LE-MRM NAT traversal.

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

I hope to get some time for checking this out.

>
> Thank you for your attention,

Thanks a lot for the comments!

> Henning Peters
>
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis

_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis