[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AH/ESP Last Call Results
Ted,
I can't say I have strong feelings anymore about replay (I feel like I
punched myself out actually) but I want to make one more comment.
> Both AH and ESP
> ---------------
> 1. Sequence Number and Anti-replay Service -- 3 options have been
> proposed over the past several months. (B) was chosen over (A) back
> about 2 months ago. (B) is what's in the text at present. (B) is
> a perhaps bit better than (C) but both are pretty similar. It seems
> simplest at present to stick with (B).
>
> S = Sender AR = anti-replay
> R = Receiver Seq# = sequence number
>
> Sender
> Default To initiate AR Pro Con
> ------- ------------------ ---------------------- -----------------------
> A) AR OFF S negotiates AR ON,- Deterministic, reli- Have to change Oakley/
> R accepts/rejects able way for S & R to ISAKMP
> know AR status
> - Handles manual keying
>
> B) AR OFF R SHOULD notify S - Handles manual keying - NOTIFY is unreliable,
> that AR is ON - No changes to Oakley/ so S may continue to
> ISAKMP send while R rejects
>
> C) AR ON R MAY notify S that - No changes to Oakley/- NOTIFY is unreliable,
> AR is ON or OFF ISAKMP so S may stop sending
> - Does not rely on when didn't need to
> unreliable NOTIFY to - Requires special case
> get S to monitor Seq# for manual keying
Anti-replay protection is "the right thing". We should assume the other guy
is always doing the right thing. Since it's in the receiver's best interest
to do anti-replay protection I see no reason why S should assume it is not
being done by R. I am unaware of any implementation that does not support
replay (not counting the ones that only support the deprecated transforms)
and, in fact, does not _do_ replay by default. The con for B is large I think.
It is larger than the 1st con for C. Since S is not going to wrap but still
has more packets to send it will initiate another negotiation to acquire new
SAs. I don't see the case where S stops sending when R doesn't require it
happening in the real world. This is not really a con.
The 2nd con for C seems slight to me as well. Manual keying is really for
bootstrapping, testing, and small scale situations. It doesn't scale to the
big-I Internet. I don't really see a problem requiring a special case for this.
In the event of sequence number rollover I'd rather see the worst case
scenario (where the two sides are not doing the same thing) be a seemless
transition to new SAs without packet loss instead of an abrupt termination
of the connection.
I hum loudly for C (and in C too :-).
I'd also like to note that it isn't necessarily the notify that is unreliable.
It is the exchange that a notify is usually passed in that is unreliable--
the Informational Exchange. There is no reason why a conformant implementation
(in this case R) can't chain the notify payload to the response message which
contains the SA(s) in question. It seem the logical place for it in fact.
"Here's what I like from your offer. An oh, by the way, I'm not doing replay."
The receipt of the notify payload can be guaranteed-- but that doesn't mean
that SHOULD should become MUST.
Dan.
Follow-Ups:
References: