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

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

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.

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