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

Re: Retransmits in traffic count?

On Wed, 11 Aug 1999 16:11:44 EDT Andrew Krywaniuk wrote, where (2) is
the "# of negotiations" type of life that is being proposed for IKE:
>
> My feeling on (2) is that notifies for expiry constraints aren't
> particularly useful, but if we support them then we should at least be
> consistent. I was hoping that someone would suggest a reason why these
> notifies are important (because I can't think of a good one) -- perhaps for
> auditing purposes or maybe to negotiate an intelligent jitter condition to
> avoid rekey collisions.
> 
> Besides, it doesn't seem to do much harm to send expiry constraints that the
> other side doesn't understand (since, as we have already discussed, pretty
> much everyone discards them without using them). But apparently it does do
> damage to some vendors' implementations if we remove constraints that
> already exist. As far as I can tell, this should be a MAY clause in the spec
> (which it probably already is, but I can't be bothered to look it up).

  Wow! With an attitude like that ("I can't be bothered to look it up") I'm
not surprised you don't understand. If you never use something then it is
worthless to you. A gearshift is not a useful part of a car if you never get 
out of 1st gear. But not everyone (and I hope not "pretty much everyone") 
discards lifetime offers and responder-notifies, and for those of us who do
parse lifetime offers and send responder-notifies (when needed) they are 
quite useful.

  By using these two features each side is able to keep their SAs in
sync. If A offers B a lifetime _less_ than what B has configured B will
accept it and respect it. If A offers B a lifetime _more_ than what B
has configured B sends A a "responder-notify" stating the lesser
lifetime which A is expected to respect. That way both sides are in sync
when rekeying comes around and each side knows that the other side is
going to delete the SA when it will. That is the reason why these 
features are part of the protocol.

  For a variety of reasons-- a reluctance to write a variable memcmp
routine to parse TLVs of (possibly) different length and return -1,0,1
depending on the result of the comparison, or perhaps a "my way or the
hiway" type of enforcement of lifetime policy-- some people are reluctant
to engage in this behavior and instead just ignore these very useful
features. They ignore an offered lifetime and any responder-notify message
they receive and they never send responder-notify messages regardless of 
the contents of the protection suite they receive. But the result is that 
some complicated re-keying regime is necessary and interoperability is not 
ensured.

  This complicated protocol is easier if these common sense features are
used and not ignored. I encourage you to find the time to "be bothered" 
to read the RFCs.

  Dan.
References: