[anonsec] BTNS and NAT-traversal

[Nicolas.Williams at sun.com (Nicolas Williams)]

On Tue, Mar 21, 2006 at 01:29:48PM -0600, Michael Richardson wrote:
>   So, there is some significant difference between:
>    a)   A:1234/32 <-> B:80/32 (transport mode)
>   and
>    b)   A[A:1234/32] <-> B[B:80/32] (tunnel mode)
> 
>   when a NAT is involved.  From the point of view of the gateway, these
> become:
>         
>    a)   N:4567/32 <-> B:80/32   (%)  
>    a'   A:1234/32 <-> B:80/32 
> 
>    b)   N:4576[A:1234/32] <-> B[B:80/32] (host-to-host tunnel mode)
> 
>   Where N:4567 is outer IP of NAT, and 4567 is outer UDP port. 
> 
>   (%) Yes, there are some systems that let transport mode change TCP (or SCTP)
>       connections into UDP connections... they are broken. Openswan KLIPS 
>       was such a system until recently.  

Yes, I see now (actually, I saw yesterday :)

Now, we could leave NAT out of scope :) or we could do what you
suggested yesterday, namely, to use connection latching as part of the
packet inbound dispatch/outbound SA/tunnel (or NAT address) selection
process.

I don't mind leaving NAT in scope because your solution seems obvious
enough and seems not to do too much violence to IP/IPsec.  That said, I
would insist on this being optional, or even a separate document
altogether.

>   Now, if you have a', guess what... *A* is not UNIQUE. You REQUIRE
> connection latching, and BITS and BITW just can't work easily.
> 
>   If you have b), then guess what... *A* is not UNIQUE.
>   Note that (b) is morally equivalent to gateway mode, from a policy point of
> view. 

BTW, is there a potential argument here that connection latching SHOULD
or MUST be used with tunnel mode only because it makes (I assume, for
this argument) implementation of this sort of NAT traversal easier?

>     Nicolas> I think we want to leave tunnelling out of scope for BTNS.  That
>     Nicolas> doesn't simplify things so much though -- we still need
>     Nicolas> connection latching and, ultimately APIs to inspect what is
>     Nicolas> latched and channel bindings.  But note that IPsec generally
>     Nicolas> needs this, and not because of BTNS -- BTNS is merely bringing
>     Nicolas> the issue to a head.
> 
>   I agree. 
>   I don't think you can reasonably do BTNS through a NAT without connection
> latching.   
> 
>   I also don't think you can do it using the language of the RFC2401/4301
> SPD, because the indirection level introduced by that mechanism means that
> you can't seperate two SAs or SPDs that leads to the same "identifier"
> (rfc1918) address. 

But not because of BTNS.  End-to-end IPsec NAT traversal has this same
problem, no?

>   In this context I have been pondering what to do with Opportunistic
> encryption through NATs. Originally, we thought that the problem was policy
> and authorization. We figured out how to solve this. 
> 
>   Since OE uses host /32<->/32 tunnels, we need something unique for the host
> to use as it's "identifier" for the inside. We considered the subset of
> people like the developers, who have unique identifiers we can allocate
> already. (road.marajade.sandelman.ca, 205.150.200.163 is an IP for my laptop
> that I use only on the inside of a tunnel).
>   
>   I then realized that we had a problem. Our outgoing TCP connection was
> going to try to send a packet from:
>       192.168.1.101 -> 205.150.200.178   (my web site)
> 
>   and I was hen going to want to try to match it to an SPD that said:
>       205.150.200.163/32 -> 0.0.0.0/0   => try OE.
> 
>   Worse, if I managed to do this, I would then, after having established a
> tunnel, want to *change* the IP from 192.168.1.101 to 205.150.200.163!
> 
>   Then I thought about people who don't have that unique IP, and wondered, as
> long as I'm violating several layers of software stack, why not change the IP
> >From a v4 to a v6 underneath the application. In the case of Linux<->Linux, I
> can reasonably guarantee that there is v6 at the remote end, and I can use
> IPv4-mapped IPv6 addresses at the remote...
> 
>   Ooops. Maybe transport (BTNS) and/or BEET mode would be better at the lower
> levels, but it may be that I still want to do this.
>   HIP pushes the problem that I have described up to the application layer,
> giving it these HIT's in the form of IPv6 (and now IPv4, I'm told) addresses.

Which the application could use for channel binding and/or LoF?

I remember conversations about how HIP and BTNS were working on the same
problem from different directions.

Nico
--