Clarify enabling replay protection and add notify for maximum crypt offset#14
Clarify enabling replay protection and add notify for maximum crypt offset#14antonyantony merged 2 commits intomainfrom
Conversation
| of sending the value 0, the notification SHOULD be omitted entirely. | ||
| That is, if this notification was not received by a peer, that peer | ||
| MUST not use a Crypt Offset when sending EESP packets. | ||
|
|
There was a problem hiding this comment.
Hmm, what to do with packets violating this "MUST"? Or violating the maximum Crypt Offset value? Perhaps this should be specified in the core EESP document, but some rules should be given.
This is actually a difficult question. On one hand, if the peer sends a packet with Crypt Offset greater maximum announced value (including 0), then the possible harm (if any) has already done, so why the packet should be dropped? On the other hand, this is a violation of a host's policy, so why we expressed it if we do not enforce it?
Opinions?
There was a problem hiding this comment.
Yeah, I first had "MUST drop the packet" in the second paragraph of this section (where I now just recommend terminating the IKE SA). But like you, I wondered why, because it's a valid packet and the damage is already done so why drop it.
There was a problem hiding this comment.
After discussing it with Antony and Steffen, I've added that the packet MUST be dropped and only the Child SA SHOULD be deleted. I've added the same text here at the bottom of the section.
tobiasbrunner
force-pushed
the
replay-cryptoffset
branch
from
53773de to
ffa6732
Compare
tobiasbrunner
force-pushed
the
replay-cryptoffset
branch
from
ffa6732 to
59288a4
Compare
3 participants
This tries to clarify that negotiating 64-bit SN enables replay protection (i.e. the peers MUST use it). And it adds a new notify to announce the maximum accepted Crypt Offset.