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

[Martin Stiemerling <[e-mail]>]

Hi Robert and All,

Am 10.05.2006 um 10:59 schrieb Hancock, Robert:

> hi all,
>
> i'm still trying to get my head round sections 3.8.2 and 3.8.7 of
> the spec (which i think is what most of the thread below is about).
>
> however, i do have a specific comment about the applicability of the
> LE-MRM and PC-MRM for various types of scenario. i'll say in advance
> that i'm not 100% certain that the LE-MRM definition is right;
> however, the discussion below is not persuading me that it is wrong.
> i'll try to explain why:
>
> from a GIST perspective, the purpose of the LE-MRM is to allow an
> NSLP at an end host to talk to the 'edge' of the network and to
> get signalling messages back. from that point of view, no port numbers
> are needed at the GIST level, because there are no port numbers
> associated
> with the concept 'edge of the network'. routing state can be quite
> happily created at NATs along the path [how? see below] and GIST
> messages can be sent backwards and forwards as the NSLP requires.
>
> it turns out that the NATFW NSLP may need a port number for NATFW
> purposes; specifically, that the external address that gets allocated
> may actually be a {address, port} pair, if the NAT is doing address
> sharing [if i understand it right ...]. However, in this particular
> case, it's vital that the {address, port} information is *not* carried
> at the GIST level, since it's vital that these are *not* translated
> on the way back to the end host - the end-host wants these unmodified
> so it can advertise them in the public network. so {address, port}  
> have
> to be carried at the NSLP level (where other funny processing also
> takes place on them).
>
> the question then arises whether other NSLPs might want to use the
> LE-MRM and might need to have port numbers translated for them if
> the signalling path went through a NAT. I can't assess that either
> way at the moment; however, I can say that the QoS-NSLP is not a
> valid example. if the QoS-NSLP wants to use some sort of proxy mode,
> then it should use the upstream PC-MRM, not the LE-MRM. this is
> because the QoS-NSLP talks about flows, not about network edges.
> if the QoS-NSLP wanted to manage QoS for something which wasn't a
> flow but which was bound to a network edge for some reason, then the
> LE-MRM might be appropriate - but then there would be no port numbers
> involved anyway. and i think that the same line of reasoning would
> be applied to other NSLPs also.

Nothing to say other that I fully agree. Good that we've had the sushi
in San Diego ;-)

>
> there remains the question of how GIST gets LE-MRM-routed traffic
> through a NAT. i think there are two cases here:
> *) if the NAT hosts the NSLP in question, it is a non-issue. the
> signalling traffic is presented to GIST by the NSLP separately
> on each interface, and the NSLP is responsible for choosing the
> MRI/SID/NSLP to pick out the routing state towards the right peer.
>
> *) if the NAT does not host the NSLP in question, GIST has to do
> MRI/NLI/SCD re-writing to get the Query/Response messages backwards
> and forwards correctly. no GIST routing state gets established, but
> NAT bindings need to be established for the signalling traffic
> itself. but I don't see this requiring access to information that
> might be carried in the NSLP; the NAT can use the SID or the UDP
> source port from the Query as keys for its binding table; the
> former we assume to be unique and the latter can be rewritten.

 From the NTLP point that is all right. However, semantically the
purpose of LE-MRM NAT traversal support at the NTLP is
questionable (therefore I have asked Henning about use
cases). A message with LE-MRM is used to locate a network
edge with a NAT to enable inbound traffic. A REA message would
be used in conjunction with the LE-MRM. If this type of message
is transparently pushed through a NAT (let's call it N1) and intercepted
by yet another edge-NAT (N2) beyond this, we get some non-issue
as well. N2 can enable locally the NAT bindings for inbound data  
traffic,
but how is this done at N1? The NATFW NSLP signaling messages
can be exchanged between the hop before N1 and N2, but
there is no way out of the NATFW NSLP to configure N1 for the
expected inbound traffic. The NI would anyway need to use some
other sort of NAT traversal technique.

>
> summary: at the moment, I think that the LE-MRM is ok. However, it's
> a subtle subject and it's possible that I haven't understood all the
> concerns. I'm also not certain at the moment that the way the NATFW
> NSLP does things like proxy REA are correct - still thinking ...

I also see no issue with LE-MRM in the current NATFW NSLP usage.
However, no guarantee for other NSLPs.

There is no doubt from my side about proxy REA and LE-MRM.
The semantics of REA on the NTLP level itself is not changed for
proxy REA. Proxy REA just needs to carry additional information
for generating the latter CREATE. The CREATE is independent
of the signaling state created by REA. The proxy REA is, in the
first place, doing exactly the same job as REA: Finding the network
edge with an edge-NAT.

   Martin

>
>
> cheers,
>
> r.
>
>> -----Original Message-----
>> From: Martin Stiemerling [mailto:[e-mail]]
>> Sent: 08 May 2006 16:01
>> To: Henning Peters
>> Cc: [e-mail]
>> Subject: 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
>>> [e-mail]
>>> https://www1.ietf.org/mailman/listinfo/nsis
>>
>>
>> _______________________________________________
>> nsis mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/nsis
>>
>
> _______________________________________________
> nsis mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/nsis


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