[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPsec Architecture -- proposed changes
Folks,
A couple comments on encapsulation.
> The question is, should a tunnel look like a single IP hop or not? I'm of
> the VPN religion, and so I believe that tunnels should look like a direct
> (one hop) link between the two hosts/routers.
VPNs are certainly one important area that the working group is to
address, but not the only one. The working group is to try and make
the services provided by IP secure, not to depreciate services that
are not "easy" to secure. We should make sure that we do not overly
constrain interaction between individual hosts or a host and, e.g., a
server run by some business (apt to be much more common than
(configured) VPNs if the internet becomes a commercial success).
IPSec is using the mechanism of encapsulating a datagram with another
IP header and AH and or ESP headers because it is an efficient
mechanism to specify the source routing needed to get a datagram to
the right system (destination security gateway), and to identify the
security headers that it should process (all those up to the next IP
header). Thus the IPSec use of encapsulation has different motivations
and goals than, for example, the tunneling used in the MBONE to get
through routers that do not support multicast. In the MBONE context,
the tunnel should look like a layer two point-to-point link to the
multicast routing layer, so that multicast traffic can be correctly
forwarded. It is also needed in order to make expanding searches,
etc. work correctly.
> This makes traceroute output look really weird when going through a tunnel.
If most of the connectivity problems one has to diagnose are before or
after the security gateways, then seeing the hops between them would
not be an issue. My experience has been that connectivity problems
are more often "in the cloud" than in the organizations at either end.
The ability to diagnose things between security gateways will be even
more important until we get all the path MTU issues resolved and the
code working. Things that make diagnosis of problems harder for the
users are not a win, in my opinion.
I think that by treating security encapsulations as "tunnels", with
nothing between the security association endpoints visible to the end
user, and a separate TTL, we will be making it harder to maintain the
existing IP services if not break them altogether (think multicast
:-(). I thus think that it is important that security encapsulators
and decapsulators look just like one more system along a path that a
datagram follows. To do otherwise is to make a subtle change the
basic internet architecture, which I do not think we have addressed
and understand.
Charlie
Follow-Ups: