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

Re: A few observations about the replay issue

  Steve,

  I'm having deja-vu all over again.

  Of the 8 or 10 or so people to voice an opinion on receiver notification
of replay you are the only person to want it. Derrell's response to your
technique to shoehorn notification into ISAKMP mentioned that it would
work "at the expense, on the wire, of requiring that each SA proposal be
more than twice as large (in bytes) as it would otherwise be without
'negotiated' AR". That's hardly an endorcement.

  I'm really baffled by your insistance on retaining this text. That there
is no WG support for it (excluding yourself) and there is WG opposition to
it (also excluding myself) makes it even more baffling.

  But since we're in the spirit of compromise let me suggest one to settle
this. The current Arch draft mentions:

	"If an SA establishment protocol such as Oakley/ISAKMP [sic] is
	employed, then the receiver SHOULD notify the transmitter, during SA
	establishment...."

I trust that SHOULD is remaining a SHOULD and not becoming a MUST. The real
way for a receiver in ISAKMP to notify the transmitter of anything is via 
a notify message. So, what should be done is to not have replay be an 
attribute of the SA negotiation process (and thus unnecessarily burden
that process) but to make a new notify message type of "REPLAY". If either
side is doing replay then they SHOULD send this notify message which contains
the SPI of the SA in question.

  How does that sound?

  Dan.

> 	I'm willing to adopt with your suggested compromise.  The
> docucuments will be revised to reflect that the receiver notifies the
> sender whether AR is enabled for each SA (using the technique Derrell
> mentioned earlier, so as to preserve the ISAKMP negotiation symmetry), but
> there will be no mechanism for the receiver to notify of the AR window
> size.  The MIB for AH and ESP will include window size.  The MIB author
> will need to discuss the read/write constraints for this entry.
> 
> 	That leaves the question of what the documents should say about the
> receive window size.  We no longer need to advertize it, so that removes
> one motivation for standardizing allowed window sizes.  However, one can
> still argue that a minimum size should be specified, to avoid the problems
> that can arise if very small window sizes are adopted.  (Recall the
> confusion over adopting a window size of 1 as a default .)  Based on the
> current specs, a minimum of 32 would be mandated, with a recommended
> minimum of 64.  Any probolems with that?
Follow-Ups: References: