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

Re: A few observations about the replay issue

Dan,

>  I'm having deja-vu all over again.

I presume the first instance of deja vu you refer to is mid-May message Ted
posted recently, in which you agreed to the text that currently appears in
the AH and ESP drafts :-).

>  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.

A series of messages have been exchanged on the general topic of receiver
notification, incluidng both basic notification and window size
notification.  Most of the messages argued against the latter aspect of the
current drafts, fewer against the former.  WG members other than I noted
the implications of not providing any notification, which could lead to
mandating authentication for all ESP SAs, even ones where AH was also being
used.  This strongly argues in favor of retaining receiver notification.

I don't question your claim that the addition of this data would double the
proposal size, but I think that's a misleading characterization.  Given the
amount of data being passed in ISAKMP messages, e.g., certificates, this
notification data is pretty small.

>
>  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.

I don't agree with your characterization of WG support re this aspect of
the specs.  As I noted above, most people expressed support for removal of
the size notification, and provided rationales for this position.  However,
later discussion of the problems that would result if no notification were
provided did not result, in my opinion, in a clear WG consensus to make
that change.

>  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?

I appreciate the spirit of compromise expressed here and my only concern is
the following, based on the issue that Cheryl raised in Munich. Consider
the situation where the receiver fails to notify the sender that AR is
enabled, (the requirement is a SHOULD, not a MUST) and thus the sender does
not check for sequence counter overflow. If the sender transmits 2**32
packets, then the receiver will begin rejecting packets, but the sender
will not know why.  I expect that the sender will eventually give up and
create a new SA, but it seems a pity to create this problem. When we wrote
the current text, I believe that we made this a SHOULD, vs. a MUST, largely
because of the requirement for window size notification.  Since we're
dropping that aspect of the notification, that motivation for the
requirement level no longer exists.  Why do you feel strongly about having
this be a SHOULD, vs. a MUST?

Steve
Follow-Ups: References: