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

Hi all,

Just for the record. This has been addressed, but did require changes in multiple places. Please read the updated draft, once it is available.

Here are the changed places in the draft:
- added new section 4.2.3.  External Binding Address Object
- added new section Appendix B.  Usage of External Binding Addresses
- changes in section 3.7.2. to address the new usage/object

  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]
> ----------------------------------------------------------------------