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