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

[Martin Stiemerling <[e-mail]>]

Hi Henning,


Am 10.05.2006 um 20:32 schrieb Henning Peters:

> Hi Robert,
>
> good summary. Though, I am missing one point:
>
> In a hierarchical NAT scenario, is it sufficient only talk to the  
> edge to
> make a reservation? An example:
>
>    A:NI --[ B:NF(NAT) --[ C:NF(NAT) --- D:NR
> 1)             <=========================REA
> 2)             RESPONSE====================>
> 3)    CREATE====> ============> X =========>  X...marks the problem  
> loc.
> 4)    <========== <============= <==RESPONSE
>
> Assumption: In this scenario I assume that a REA(1) message with LE- 
> MRM
> does only talk to the edge and traverses C seemlessly. C may trigger a
> reservation, read the flow, but will not change any data of the  
> message
> exchange between B and D.

Does this imply C:NF(NAT) being NATFW NSLP unaware or do you say
C:NF(NAT) is NATFW NSLP aware but does not care about the message?

The picture does not show the NATFW NSLP operation
if C:NF(NAT) is NATFW NSLP aware.

Can you clarify this? Otherwise the answer to this email is going  
full of ifs.

Thanks,

   Martin

>
> For an upcoming CREATE(3) message from A it seems to be necessary  
> for B to
> previously store the IP address of the C during REA(1) operation,  
> because
> B has to map between different session IDs based upon the external  
> port
> reservations. It also has to know the external port reservation of C.
>
> Thus, in respect to NAT behavior, B has to translate the IP and TCP/ 
> UDP
> layer and update MRI accordingly to match the new destination
> address/port. But: how does B know about a valid destination port  
> at C?
>
> In my view all NAT have to do a mapping unrelated to session ID,  
> but on IP
> address and port, because REA and CREATE messages are different  
> sessions.
> Thus, they need a mechanism to signal their external port  
> reservation to
> the upstream NAT, this is not possible without modifying the exchange
> between B and D. Thus my previously made assumption is wrong.
>
> Hence, I asked Martin to give me a port field, it was introduced in  
> last
> fall. The whole issue is complicated, so I am not 100% sure whether I
> might not miss a point. If I might be right, then I have following
> concern:
>
> LE-MRM is not only about "talking to the edge". Therefore, I find it
> sensible to put the port into LE-MRM. Please keep in mind that I  
> might be
> biased, because I want to keep my codebase small ;).
>
> Currently the port resides in DTINFO object. So, if signaled with  
> LE-MRM
> one has to use this field, when using PC-MRM one has to use MRI port
> although the port is here needed for the same purpose: giving the  
> upstream
> NAT information about the local NATs port reservation. Sure, in PC-MRM
> this information is overloaded the same way as NAT is already  
> overloading
> identifiers.
>
> Henning
>
>
> Hancock, Robert sagte Mi, 10.05.2006, 04:59:
>> 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.
>>
>> 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.
>>
>> 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 ...
>>
>>
>> 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