Re: Multi-level NAT and draft-ietf-nsis-nslp-natfw-20

Hi Magnus,

One approach to solve this issues is that each NAT includes its "public IP+port" (== the binding address) in the NATFW NSLP message sent towards the public Internet. This will give a stack of IP addresses+port. The outer NAT (e.g., NAT2) will return the whole stack in the response message. 

The particular NI could use the stack as input to STUN.

This requires a change in the objects (e.g., a external binding stack) and some text on the semantics. 

Does this solve this?

  Martin

[email protected]

NEC Laboratories Europe - Network Research Division
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email protected]]
> Sent: Friday, November 27, 2009 2:11 PM
> To: [email protected]; NSIS
> Subject: Multi-level NAT and draft-ietf-nsis-nslp-natfw-20
> 
> Hi,
> 
> I am a bit concerned with the handling of multi-level of NATs by the
> document. As currently defined it will force all flows to be pinned to
> the edge-NAT. As I understand there are no mechanism on how to optimize
> this route when the DR is behind the same NAT, or on a higher layer.
> 
> 
>  Ni  --192.168.0/24-- NAT1  -- 10.0.0.0/8 --- NAT2 Internet (public IP)
>                              |
>  Nr1 --192.168.0/24-- NAT3  --
>                              |
>                              Nr2 10.1.2.3
> 
> So the above diagram shows on Ni and two Nrs.
> 
> 1. Ni -> Nr1: Both Ni and Nr1 does external towards NAT2 and get an
> external address+port binding. Then they exchange that external binding
> and all traffic gets pinned to NAT2 instead of taking shortes path by
> NAT1 to NAT3 directly. However to do that Nr1 and Ni both needs to be
> aware that they also have the address on the external side of NAT1 and
> NAT3 respectively. If you run ICE and actually have a STUN server in
> the
> 10/8 network configured you can actually get the shorter path to work.
> If the NATFW NSLP would provide with all external addresses you have
> towards the public network it could allow for optimizations.
> 
> 2. In case two Ni -> Nr2 is even more obvious. Pinning this to NAT2 is
> an important fall back, but allowing for trying might be worth it.
> 
> Please note that if there are overlapping address domains between Ni
> and
> the public Internet the regular routing will not necessary allow
> sending
> the packet to the right domain.
> 
> This also makes it important to present the address as having different
> utility. The NAT2 external binding address would be the default as it
> is
> most likely to work. However, the NAT1 external address is also useful
> for certain applications.
> 
> I don't know how difficult this is to address.
> 
> Comments?
> 
> Cheers
> 
> Magnus Westerlund
> 
> IETF Transport Area Director
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Fdrvgatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: [email protected]
> ----------------------------------------------------------------------