[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Stephane's Comments on IKEv2



> questions 4 and 5: Clarification of sequence numbers: If a sequence number
> is "out of whack", drop the message.

Well, yes.  But I was just wondering if a NOTIFY or something was required,
or if we should just blindly drop the packet.

> Out of whack: Suppose the receiver Bob's window is n, and the largest
> sequence number of a valid message Bob has seen is k and the most
> recent "hole", i.e., sequence number he has NOT yet seen, is j. j is
> guaranteed to be less than k, and in fact less than k+n+1, if Alice
> is following the rules. Bob must reject anything greater than j+n (Alice
> shouldn't be sending anything
> greater than j+n if Bob has not ack'd j) or less than k-n. For something
> between k-n and j+n, Bob will respond. He is committed to keeping track
> of n messages if the msg isn't idempotent, so if it's within the window
> if Bob has seen it before he is guaranteed to send back the same response
> as he did before. That's why we don't want him to simply drop messages
> if his receive window is, say, n, and Alice sends n+5 messages at once.
> He might respond to something, and then get a retransmission, and perhaps
> he'd respond something different the second time. And his first response
> might actually reach Alice (she'd prematurely given up on it) and perhaps
> things would get confused. Seemed simpler to just have Alice NOT send
> more than Bob is willing to remember.
>
> As for reaching sequence number 2^32 on
> the IKE-SA...Funny thing about that...
> Charlie asked me that and I said, "Come on! There's no
> way you could ever send that many IKE messages", so he agreed
> not to say anything in the spec about it. But it would
> be easy to add that if you run out of sequence numbers
> you rekey. And then I'd have to admit to Charlie that he was right
> and we should have said something about that in the spec. :-)

I'm still not very keen on this "windowing" concept.  It seems that the
initiator will have to perform some logic to ensure that it doesn't
overwhelm the responder.  In essence, the initiator is doing the responder's
job in managing it's resources.  I prefer the model where the initiator
makes requests, and the responder processes as many as he can.  Once the
responder is overwhelmed, it starts to ignore requests.  The initiator's job
in this case is to ensure that it re-requests the service if it is still
needed, or perhaps attempt a connection with a secondary Gateway which is
hopefully not as busy.


>
> 8-9: missing AUTH payload: We don't use an auth payload to protect
> the contents of any IKE messages beyond 1 and 2. The AUTH payload protects
> messages 1 and 2 and proves identity. All IKEv2 messages after the first 2
in
> the initial IKE-SA creation are fully
> encrypted and integrity protected using a key
> which is a function, among other things, of the Diffie-Hellman
> key established in messages 1 and 2, so if the other side knows
> the integrity check key they must be the entity that proved their
> identity in the AUTH payload. Instead of doing integrity protection
> for messages 3 and later
> with an AUTH payload, which was kind of painful to specify because it
> involves discussing how to integrity protect something that includes
> the integrity protection bytes, the integrity field is at the end of
> the packet. To save words in the spec, we said "use the same format
> as ESP", i.e., IV | encrypted data | encrypted padding | enc. pad. length
|
>           wasted byte (where ESP has "next header") | integrity check
> So this is equivalent to having an AUTH payload...it's just that the
integrity
> check follows the encrypted data rather than being in the middle of it.
>
> And the integrity check protects everything, including the IKE header, so
> we don't have to think about what fields should go into an integrity check
> payload.
>
> Some people objected to, and some people were confused by, our pointing
> to the ESP spec. We certainly could explicitly lay out the packet format
> inside IKEv2 rather than pointing to the ESP spec, and then we could
> get rid of the funny reserved byte after the encrypted padding length
field.
>

Count me among the confused.  I completely missed any such wording.  I'll
take another look.  Thanks for pointing it out.

>
> 6) reactions to unprotected messages like ICMP "destination unreachable"
> or unprotected "unknown SPI" IKE messages:
>
> If you rely on periodic IKE pings to detect the dead peer, it might be
> a long time that you'd be sending into a black hole. If the routing
> infrastructure says the destination is unreachable, you can use that
> to be suspicious and check for aliveness in order to speed things up,
> but it has to be rate limited so someone can't send you a zillion
> ICMP messages.

Ah.... I just re-read this section.  I was completely mis-understanding what
you were saying. Sorry.

>
> 7) being more specific about waiting for known aliveness of new SA before
> deleting the old one. Seems like a good idea. I'd be glad to
> read Tim Jenkin's draft except you said it was expired.
> Pet peeve: you pointed me at an expired internet draft, which means it's
> hard to get. It would be nice if the IETF page had a link to all drafts
> ever made. At any rate, could you send me a copy of Tim's draft? (don't
> CC the list when you do of course)

OK.  It's on its way.

>
> 10: INITIAL-CONTACT: I'm not a fan of it at all, but
> I understand other people like it. It makes me nervous
> because although the spec says "don't do that" it's possible
> someone will replicate a service and then you could have multiple
> things with the same ID and nullifying each other's connections.
> Bill Sommerfeld got me to like the INITIAL-CONTACT
> thing better if we add "and the
> same IP address" after the phrase "to the same
> authenticated identity".
> An alternative is
> Bill Sommerfeld's birth certificate proposal, which is a "to be written"
> internet draft rather than an "expired draft" which makes it just as
> hard to find. :-) I'm slightly nervous about that as well, in the
> unlikely event that someone's monotonically increasing counter actually
> goes backwards, without being aware of it. And I'm not convinced
> things wouldn't work without either mechanism. I don't have strong
> feelings either way though. As for your question
> about where INITIAL-CONTACT would appear: It would be in message 3 or 4,
and
> it would be covered by the integrity check
> as would everything else inside messages 3 and 4.

OK.  Can you add text to that effect.  I've seen INITIAL-CONTACT in strange
places before ;)

>
> 11: deletes for IKE SAs: I don't understand what you were asking.

Section 7.11
The new IKE SA delete payload doesn't allow you to specify cookies in the
SPI field.  That was allowed in IKEv1.  This was conveniant in order to use
an IKE SA to send a protected DELETE for some out-of-sync IKE SA.  So in
other words, if peer A thought he had 2 IKE SAs (SA1, SA2), and peer B only
thought he had 1 IKE SA (SA2).  This out-of-sync scenario could happen for
multiple reasons in IKEv1.  In this case peer A could be sending data (ex.
Create-Child-SA) with SA1.  When peer B received this data, it wouldn't be
able to find the matching SA to decrypt with.  Peer B could then send a
DELETE with SA1's cookies, using SA2 to encrypt it.  I guess we could also
use INVALID_COOKIE notify, but it was always more reliable / predictable to
send the delete.

Granted, many of the conditions which led to this scenario are gone in
IKEv2.  The ack'd DELETES solve the most common case.  However, permitting
the specification of cookies in the SPI has no drawbacks (other than a few
more bits on the wire), yet it could prove to be very useful.

>
> 13: Nat traversal: we'll have to think about this. As well as perhaps
> going through an anonymizer, which I'd think would be similar. Wanna help?
:-)
>
> Radia
>
>



Follow-Ups: References: