[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipsec
Subject:    Re: IPsec Architecture -- proposed changes
From:       "C. Harald Koch" <chk () utcc ! utoronto ! ca>
Date:       1997-10-11 3:12:32
[Download RAW message or body]

Nice idea. However, since the packets that generate the "TTL expired"
message are encrypted, it's kinda difficult (read impossible) to figure out
who the *original* unencapsulated packet came from, and so return the TTL
expired message. Net result: a traceroute output with lots of "* * *" lines,
which is *not* productive to diagnostics.

To go back to your original point: if you want source routing, use source
routing. If you want tunnelling, do tunnelling. Don't try to mix the two;
you'll get the worst of both worlds.

We don't know what to do with multicast in an IPsec context. Leave it for
IPsecond.

The outer TTL should not be copied to the inner TTL on decapsulation.

-- 
Harald Koch <chk@utcc.utoronto.ca>

In message <199710102359.TAA03524@relay.rv.tis.com>, Charles Lynn writes:
> 
> > 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.

[prev in list] [next in list] [prev in thread] [next in thread]