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

RE: Phase 1 Re-keying Implementation Identification



Just to clarify a point, but I think we will not pursue
attempting to recognize continuous channel implementations
any further.

> -----Original Message-----
> From: Tero Kivinen [mailto:kivinen@ssh.fi]
> Sent: November 18, 1999 4:59 PM
> To: Tim Jenkins
> Cc: ipsec@lists.tislabs.com
> Subject: RE: Phase 1 Re-keying Implementation Identification
> 
> 
> Tim Jenkins writes:
> > The advantage in knowing how the other end operates is when you
> > receive a delete for the last phase 1 SA between you, and there
> > still exists 1 or more phase 2 SAs between you that you did not
> > get a delete for. This can happen due to the optional and
> > unreliable of the existing delete notifications. (Yes, I know
> > there is a proposal to replace them.)
> 
> So, what you really gain from the information that you know that the
> other end support continuous channel mode is, that you can delete one
> unused phase 2 SA before its natural lifetime, in the case of the lost
> phase 2 SA delete.
> 
> So we save up the resources used by one unused phase 2 SA, but only in
> special case where we lost the phase 2 SA delete notification. But we
> waste much more resources to keep the all the phase 1 SAs up until the
> phase 2 SAs are deleted.

It isn't just a resource issue. It's also related to how well the
protocol behaves from a customer point of view.

It seems to me that no one seems to care that one end can have an
SA that will potentially spew invalid packets at another end.

Here's an example of why I think we should minimize this:

One of the MIBs has a trap for reporting when invalid ESP packets
are received. If applications do not clean themselves up as
well as possible, this trap effectively becomes useless, since
it will cry "wolf" so much that customers will shut if off.

If someone says that we shouldn't define the protocol based on
the MIB, they're right, but they're also missing the point.
I'm having explaining it better.

Further, as I'm starting to say elsewhere, this isn't a
protocol issue, it's an application-specific-use-of-the-protocol
issue.

Tim