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

["Hancock, Robert" <[e-mail]>]

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