[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPsec Architecture -- proposed changes
>
> In message <199710071603.JAA20103@trix.cisco.com>, Cheryl Madson writes:
> >
> > The tunnel should have it's own TTL. This is consistent with how
> > other RFCs on tunnelling specify this. Look at RFCs 2003 and 1853
> > for examples.
>
> Just to be clear, we're agreeing, right? both RFC 2003 and 1853 say that you
> do *not* copy TTLs from inside to outside, but instead decrement the *inner*
> TTL when (encapsulating as fowarding) and when (forwarding after
> decapsulating), which incidentally produces useful traceroute info :-)
That's what I meant -- don't try to massively diverge from the tunnel
behavior that is already in use by other tunnelling mechanisms,
unless there is a compelling security reason to do so.
I haven't had the cycles to sit down and compare what's in the
architecture draft with any of the tunnel RFCs. Although I'm not
fully certain that any one of these RFCs is considered the "standard"
one to use (meaning that I am not willing to point to one to
simply incorporate by reference), we probably should try to keep in
line with the tunnel docs. I think it will make our collective lives
easier.
>
> > There is nothing that suggests that other key sizes are even a MAY,
> > apart from the reader recalling the history of the older AH drafts. I
> > suppose a wordsmith revision could say "this and only this" or
> > something which makes the MUST more of a MUST... ;-).
>
> In this case I'd change "160-bits must be supported" to "160-bits must be
> used". "Supported" implies that other key lengths are allowed, which is
> where I (and others I discussed this with) all went astray.
>
Since I see that the draft spells out that "no other authenticator
sizes are supported", the same should be done for the key length.
- C
References: