[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: HASH(1) or no HASH(1)?
[ NOTICE! This list will be hosted at lists.tislabs.com as of March 26.
There is no need to resubscribe, if you are on the list, you will remain
on it. Just begin sending posts, and any administrative requests to
lists.tislabs.com as of now. List mail to tis.com will cease to be
delivered as of March 26, 1999. ]
At 19:05 25.3.1999 -0800, you wrote:
>[ NOTICE! This list will be hosted at lists.tislabs.com as of March 26.
>There is no need to resubscribe, if you are on the list, you will remain
>on it. Just begin sending posts, and any administrative requests to
>lists.tislabs.com as of now. List mail to tis.com will cease to be
>delivered as of March 26, 1999. ]
>
>Question on IKE Notify/Delete messages in Phase 2 Informational Exchanges,
>to which I can't seem to find a reference to in the archives.
>
>According to RFC 2407, page 21, "Note Bene:"a Notify payload is fully
>protected only in Quick Mode".
>
>However, RFC 2409, page 19, Section 5.7 ISAKMP Informational Exchanges,
>"This protocol protects ISAKMP Informational Exchanges when possible" and
>goes on to describe:
>
>Initiator Responder
>--------- ---------
>HDR*, HASH(1), N/D --> ...
>
>
>So, which is it, should Info N/D's be HASH protected whenever possible or
>not? I only ask because I'm finding a lot of (encrypted but
>un-HASH-protected) Phase 2 INVALID PAYLOAD notify's coming back in response
>to my HASH protected DELETEs.
>
>Thanks,
>Joe
Info N/D messages have a hash if phase 1 is finished.
If some implementation rejects hash values there, I'd call it broken.
Furthermore, I would never send a notify for an informational exchange.
This can easily result in a notify storm.
Jörn
References: