Please keep it a SHOULD, but include the explanation.
Thanks,
Yaron
On 03/06/2015 09:50 PM, Valery Smyslov wrote:
Hi Yaron,
Hi Valery,
Sorry if I was inconsistent on this one.
This is a performance optimization, and it's a trade off for the
responder: Do I want to cache keys, thereb
Hi Yaron,
Hi Valery,
Sorry if I was inconsistent on this one.
This is a performance optimization, and it's a trade off for the
responder: Do I want to cache keys, thereby saving on CPU but wasting more
memory on potentially useless SAs? So I suggest to make it a MAY, not a
SHOULD.
At this
Hi Valery,
Sorry if I was inconsistent on this one.
This is a performance optimization, and it's a trade off for the
responder: Do I want to cache keys, thereby saving on CPU but wasting
more memory on potentially useless SAs? So I suggest to make it a MAY,
not a SHOULD.
Thanks,
Yar
What else could we recommend to do in this situation?
If responder deletes IKE SA in case it receives IKE_AUTH
message that doesn't pass ICV check, then it would give
an attacker an easy way to prevent legitimate initiator
to connect - just monitor the network and once IKE_SA_INIT
from the legitim
Valery Smyslov writes:
> > Thanks for the detailed clarification, and I still disagree... This
> > situation is very unlikely with correctly functioning peers, and I don't
> > think we should recommend acting on unauthenticated information, even if
> > it slightly improves performance. Actually,
Hi Yaron,
Hi Valery,
Thanks for the detailed clarification, and I still disagree... This
situation is very unlikely with correctly functioning peers, and I don't
think we should recommend acting on unauthenticated information, even if
it slightly improves performance. Actually, I think it is
Hi Valery,
Thanks for the detailed clarification, and I still disagree... This
situation is very unlikely with correctly functioning peers, and I don't
think we should recommend acting on unauthenticated information, even if
it slightly improves performance. Actually, I think it is a prototypi
Hi Yaron,
Hi Valery,
to make it easier for everyone, I suggest that you submit a new draft
version.
I completely agree with you - the amount of changes makes it difficult
to track them. We will definitely issue a new version shortly.
Commenting on the pull request, specifically:
"If the p
Hi Valery,
to make it easier for everyone, I suggest that you submit a new draft
version.
Commenting on the pull request, specifically:
"If the puzzle is successfully verified and the SK_* key are calculated,
but the message authenticity check fails, the responder SHOULD save the
calculate
Hi all,
I've updated my previous pull request.
The source file and changes are available at
https://github.com/ietf-ipsecme/drafts/pull/2
Now it is completely described using puzzles in the
IKE_SA_INIT and IKE_AUTH exchanges.
Payload formats and IANA considerations
are also provided.
Regard
10 matches
Mail list logo
