Subject: Re: [NSIS] Multi-level NAT and draft-ietf-nsis-nslp-natfw-20

From: "Martin Stiemerling" <[email-masked]>
Date: Wed, 20 Jan 2010 10:24:19 +0100

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

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-masked]]
> Sent: Friday, November 27, 2009 2:11 PM
> To: [email-masked]; 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-masked]
> ----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 20 Jan 2010 14:30:53 +0100

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

Yes, I think it will solve that. However, there will need some text
around the utility of the addresses in the stack and the need to watch
out for duplicate address domains.

Cheers

Magnus Westerlund

Färögatan 6                | Mobile +46 73 0949079

---

From: "Martin Stiemerling" <[email-masked]>
Date: Fri, 22 Jan 2010 14:06:38 +0100

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