Subject: RE: [Ietf-behave] New draft: Topology Complications

From: "Francois Audet" <[email-masked]>
Date: Sun, 20 Feb 2005 12:36:33 -0800 (PST)

Yes, I think you got it right.

I just saying that the VPN box (or app) is NATing inside the tunnel.

I'm happy with just mentioning it in the draft, as you say. 

In the example below, I'm just saying that the applications
running on the host think they have a 192.X address, but then the 
tunnel NATs it to whatever address range is used.

The applications in that case need to run a STUN service inside
the tunnel.

This is especially useful for unmanaged NAT boxes. I've also 
seen in some VPN software.

> -----Original Message-----
> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Pyda Srisuresh
> Sent: Sunday, February 20, 2005 12:23
> To: 'ietf-behave@xxxxxxxxxxxxxxxxxxx'
> Subject: RE: [Ietf-behave] New draft: Topology Complications
> 
> 
> Francois,
> 
> Thanks for your comments. Please see my responses inline.
> 
> cheers,
> suresh
> 
> --- Francois Audet <audet@xxxxxxxxxx> wrote:
> 
> > Bryan,
> >  
> > One thing worth mentioning in the VPN section, is that it is common 
> > for VPN devices (both "boxes" and PC clients) to NAT inside the 
> > tunnel.
> 
> [suresh] You are right. Doing NAT (instead of VA) inside the 
> remote access client is an option offered by some vendors. 
> The NAT option will obviate mucking with routes on the 
> client-PC. It is worth mentioning for this reason. 
> 
> However, this scenario carries the same caveats (as with VA) 
> w.r.t. overlapping networks on the corporate and remote access end.
> 
> >                                                                  So 
> > you'd get, say, a 192.168.0.X address range at the bottom 
> instead of 
> > the 10.1.1.1.
>               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> [suresh] What did you mean by this? Are you saying the 
> address pool used by the VPN server is 192.168.0/24, when the 
> corporate uses 10.1 network? I must be missing something here.
> 
> > From the corporate network however, that would still look like 
> > 10.1.1.1.
> >  
> > It takes care of some of the issues you mention, but it 
> obviously adds 
> > its own issues.
> > 
> 
> [suresh] Sorry, I dont follow what you are saying. But, I do 
> agree the NAT option takes care of some caveats, but adds 
> caveats of ots own. That was principally why we didnt specify 
> this in the first rev. We will specify this in the next rev.
> 
> 
> cheers,
> suresh
>   
> >  -----Original Message-----
> > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx
> > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Bryan 
> > Ford
> > Sent: Thursday, February 17, 2005 08:48
> > To: ietf-behave@xxxxxxxxxxxxxxxxxxx
> > Subject: [Ietf-behave] New draft: Topology Complications
> > 
> > 
> > 
> > Finally, the following slightly revised and expanded version of the 
> > earlier
> > "Topology complications" document I announced on the list, 
> is now in the 
> > official Internet-Drafts repository. 
> > 
> > 
> > "Topology complications from Network Address Translator deployments"
> > http://www.ietf.org/internet-drafts/draft-ford-behave-top-00.txt
> > <http://www.ietf.org/internet-drafts/draft-ford-behave-top-00.txt>  
> > 
> >     This document identifies and provides recommendations 
> for dealing 
> > with
> > issues that have arisen recently from the ubiquitous 
> deployment of network 
> > address translators (NAT), and the unconventional network 
> topologies that
> > are 
> > often constructed with them. First, the simplicity of 
> administering networks
> > 
> > through the combination of NAT and DHCP is increasingly 
> leading to the
> > deployment of multi-level hierarchies of inter-connected 
> private networks 
> > involving overlapping private IP address spaces. The 
> creation of these 
> > multi-level hierarchies is often unintentional, since each 
> level of NAT is 
> > typically deployed by a separate administrative entity such 
> as an ISP, a 
> > corporation, or a home user. Second, the popularity of 
> corporate virtual 
> > private networks (VPN) in conjunction with NAT leads to 
> problems in which
> > the 
> > private IP address space of the network through which a 
> remote client is 
> > attached may unintentionally conflict with the private IP 
> address space of 
> > the corporate network into which the remote client is tunneled. This
> > document 
> > specifies best current practice recommendations for 
> addressing the issues 
> > identified. 
> > 
> > 
> >   Since I've already received a number of positive comments on the 
> > original
> > draft privately by E-mail, I'd like to hear public 
> reactions to the idea of 
> > adopting this draft as a WG document, to be published 
> sometime down the road
> > 
> > relatively independently of the other documents.  The main 
> > complication is
> > that there is currently no corresponding WG milestone or 
> work item for this 
> > document, so one would have to be added. 
> > 
> > Thanks!
> > Bryan 
> > _______________________________________________ 
> > Ietf-behave mailing list 
> > Ietf-behave@xxxxxxxxxxxxxxxxxxx 
> > https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> > <https://list.sipfoundry.org/mailman/listinfo/ietf-behave>  
> > 
> > 
> > > _______________________________________________
> > Ietf-behave mailing list
> > Ietf-behave@xxxxxxxxxxxxxxxxxxx 
> > https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> > 
> 
> 
> =====
> 
> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx 
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> 
>

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 21 Feb 2005 07:22:15 -0800 (PST)

> I'm happy with just mentioning it in the draft, as you say. 
[suresh] OK. will do.

> tunnel NATs it to whatever address range is used.
[suresh] OK.

> The applications in that case need to run a STUN service inside
[suresh] I donot believe so. Any NAT enroute between the tunnel endpoints does
not effect the applications inside the tunnel. 

cheers,
suresh

=====