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

Re: Stephane's Comments on IKEv2



Stephane, thanks for you comments. Here are some answers to
some of your questions.

questions 4 and 5: Clarification of sequence numbers: If a sequence number
is "out of whack", drop the message.
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. :-)

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.


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.

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)

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.

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

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: