Hi Yoav,
Regarding the notification syntax, it is actually a bit worse than that.
This is a corner case in the RFC, but if you read Sec. 3.10 literally,
there are exactly 2 allowed values for the Protocol ID field (or 3
values, if you read RFC 4306). There is no extensibility defined, and no
IANA registry either. So a responder would be correct if it replied with
an INVALID_SYNTAX rather than ignoring your notification, if it doesn't
recognize it.
And the value you are using (1) comes from RFC 2407 and has never
existed in IKEv2. Ugh.
Thanks,
Yaron
On 2013-08-25 10:53, Yoav Nir wrote:
On Aug 25, 2013, at 9:45 AM, Yaron Sheffer <yaronf.i...@gmail.com> wrote:
Hi Yoav,
I started by reading -01, then went back to -00. And I think the two can be
merged to create a better solution.
Including the notification as soon as the peers know they want a handover is
cleaner. So IKE_AUTH (of the new SA) is better than DELETE, and in fact
IKE_SA_INIT would be even more useful because then you can define that all such
IKE SAs are implicitly childless, and avoid the need for the RFC 6023
notification.
CAFR -01 says a peer is allowed to hand over the Child SAs if it successfully authenticates to the
other peer and has the same authenticated identity. Seems to me this is symmetric, i.e. it doesn't
matter if the exchange is run over the "old" or the "new" IKE SA. And so this
could apply just as well to -00, and the POP stuff is not needed.
I'm not sure about the race discussion in -00, because it only applies in failure cases.
Can't an attacker "swallow" a few DELETE messages or their responses and cause
a similar database mismatch?
I hope they can't. Informationals with DELETEs are just like any other IKEv2
exchange. If at active attacker swallows DELETEs or their responses, eventually
at least one side loses the IKE SA.
But with regular initial IKE, there is an asymmetry. The Responder verifies the
IKE_AUTH request, generates the Response, sends it, and believes that
everything is just fine. Then the Initiator gets the IKE_AUTH response, and
decides that something is wrong. Maybe the certificate has just expired, or the
OCSP server is unreachable, or the new certificate does not have the proper
extended key usage. So we have an asymmetry, where the Responder believes that
IKE_AUTH succeeded, while the Initiator believes that it failed. The Initiator
quickly rectifies this with a DELETE, but that takes some time (milliseconds,
but still - time).
So if we tie some action on the part of both parties to the IKE_AUTH success,
we get cases where the Responder performs the action, while the Initiator does
not. In this case, the Responder transfers the child SAs to the new IKE SA, and
the Initiator doesn't. The subsequent DELETE for the new IKE SA sent by the
Initiator deletes all those Child SAs on the Responder, while they remain alive
and active on the Initiator. You could use some heuristic, like if the DELETE
comes within x seconds of the IKE_AUTH, you transfer the child SAs back. But
that is some weird code that we should not require people to make.
Making the transfer follow the IKE_AUTH makes it all cleaner. Whether it's done with the old or new
IKE SA depends on whether you are worried about childless IKE SAs kidnapping the children of other
IKE SAs (sorry, couldn't resist). We are not likely to require sameness of IP address, and I am
worried about the reliability of code comparing to IKE SAs for sameness of authenticated identity.
All L2TP over IPsec clients tend to have the same identity (with user authentication being done at
the PPP layer). Do we allow them to claim each other's child SAs? I think not, and then if we take
the "pull" approach - using the new IKE SA - we need some PoP. With a "push"
approach - using the old IKE SA - we don't.
Also note that the notification syntax is in conflict with both RFC 5996 and
RFC 4306. RFC 5996 removes the option of Protocol ID=1, while RFC 4306 assumes
that we are talking about the *current* IKE SA, and so mandates that the SPI
field should be empty in this case. Practically speaking, we will have to fix
5996 before this can document move forward. Luckily we're doing just that with
Tero's bis draft.
Good timing!
Yoav
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
