[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

TTL and IPsec



I disagree that a tunnel endpoint should always decrement the TTL.  If
you're a client, and if you're near the edge of the TTL radius, you can
drop things you shouldn't be dropping.  Some people think that end systems
that decrement the TTL too much are broken.  Think about how you want
'traceroute' to look.

TTL is going to get whacked out anyway, since the INNER IP header isn't
going to have it's TTL decremented as the packet travels through the net.
I bet someone with IP-over-IP experience has something to add to this...

>To: ipsec@tis.com, ipsec-dev@tis.com
>Subject: TTL and IPsec
>X-URL: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/
>Date: Mon, 07 Jul 1997 14:01:05 +0300
>From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
>Sender: owner-ipsec@ex.tis.com
>
>-----BEGIN PGP SIGNED MESSAGE-----
>
>
>  I'm going through some of our finer points of our implementation to
>get them all "correct" and I'm couldn't find any text to back a belief
>of mine up: 
>
>  An IPsec/VPN tunnel should consider itself to be a router, and
>decrement TTL, generating ICMP's as required. Should both ends
>consider themselves to be routers? I don't see anything in the
>documents that says this explicitely, but maybe I missed it.
>  It also should say something to the effect that ICMP messages
>generated in response to a datagram that arrived via a tunnel should
>be sent back via the "same" tunnel. (e.g. in the outgoing SA of the SA 
>bundle that makes up a "tunnel"). 
>
>]                 The sun rarely sets on Helsinki               | one
quark   [
>]   Michael Richardson, Sandelman Software Works, Ottawa, ON    | two
quark   [
>] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ | red q
blue q[
>] panic("Just another NetBSD/notebook using, kernel hacking, security
guy");  [
>
>  
>-----BEGIN PGP SIGNATURE-----
>Version: 2.6.3ia
>Charset: latin1
>Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
>
>iQB1AwUBM8DMacmxxiPyUBAxAQHbvwL/XOynke40YOlbD/F+PsJYu4UYCb5K7vW0
>2SFk8ty8bzqz8cn3rD6cFhl7Ko9ZaFQyIn9PHfm5dqGI8TSvz+fHwsmh69fUMJYl
>pZPZTDXE2MZRLmHizDIY3gwHzGL88X+7
>=K1gE
>-----END PGP SIGNATURE-----
>
>


Follow-Ups: