[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: anti-replay notification
Aug 20, 97 6:42 pm
X-Mailer: ELM [version 2.3 PL11]
Sender: owner-ipsec@portal.ex.tis.com
Precedence: bulk
> Then it was noted that it makes no sense to do anti-replay without
> authentication, so the solution is to always mandate authentication.
Steve, not necessarily. Another solution is to mandate anti-replay when
authentication is on. In other words, in the non-manual keying case,
anti-replay and authentication are always used together (if auth is
on, anti-replay must be on; if one wants anti-replay, one must have
auth).
- Ly
>
> Derrell,
>
> We started with the issue of whether the receiver needs to tell the
> sender what size window is being used for anti-replay purposes, if it is
> being used. To avoid this notification complexity, it was suggested that
> anti-replay always be used if automated keying is being done. Then it was
> noted that it makes no sense to do anti-replay without authentication, so
> the solution is to always mandate authentication. What a slippery slope we
> have here. We had previously agreed that authentication was not a required
> service, e.g., if AH were used in conjunction with ESP.
>
> I should observe that, at the Munich meeting, Derrell and I
> discussed the option of a NULL authentication algorithm to make the ISAKMP
> message syntax more niform in the absence of real authentication for ESP.
> If the suggestion is to mandate authentication for all automatically keyed
> ESP SAs, and to allow the NULL authentication algorithm, then the
> performance hit won't be so bad ... :-)! But can we explain this to the
> greater IETF community with a straight face?
>
> Steve
>
>
Follow-Ups:
References: