Re: FW: external mobike-protocol-02 review (technical) (issue 42)

Pekka Savola wrote:

> a) some people will be (at least slightly) concerned that MOBIKE will 
> reveal the internal topology of the site. This may or may not be a big 
> issue (especially as probably the most IPsec sessions will go to at 
> least semi-trusted nodes), but if we don't state it now, someone is 
> going to invent a fancy MOBIKE "exploit" 5 years down the road. A 
> sentence or two in a separate paragraph in Security Considerations 
> section would probably be sufficient.

Agreed.

> b) as the conveyed addresses are used for address selection, there 
> might be issues with that. Let's say, the responder tells it has 
> addresses 20.20.20.20 and 10.0.0.2. The initiator has 10.0.0.1, and 
> possibly 30.30.30.30. The initiator and responder are in different 
> sites (a NAT between them). Now the initiator's address selection 
> policy might get skewed if it'd prefer particular kind of addresses.
> This may be one issue where an explicit warning might be useful.

Yes. I'd be even happier if we were able to know
which addresses are behind a NAT, but...

>> "While no specific timeout lengths are required, it is
>> suggested that responders continue retransmitting IKEv2
>> requests for at least five minutes before giving up."
>
>
> No problem with me, though that doesn't give any help on how 
> aggressive you should be to start with..

This would be useful to specify, I think.

>
>>> The data associated with this notification is the SHA-1
>>> hash [FIPS180-2] of the following data:
>>>
>>> ==> this spec is not algorithm-agile. (I can't find the ref
>>> right now where this is encouraged.) In this case, maybe it
>>> doesn't need to be considering the impact (I don't take a
>>> stance on that) -- but this probably deserves at least brief
>>> discussion in the security considerations section.
>>
>>
>> This part is basically copied from IKEv2 NAT detection payloads,
>> which also use SHA-1 (and IKEv2 spec didn't include any
>> discussion about this either)....
>>
>> However, here the situation might actually be slightly different,
>> since the security implications of NAT_DETECTION_*_IP payloads
>> and NO_NATS_ALLOWED are different. The simplest solution might
>> be just to place the IP addresses in this payload (and mandate
>> comparing them with the IP header)...
>>
>> Any comments from other on this?
>
>
> As these issues have seen some debate (see the thread starting from 
> http://www1.ietf.org/mail-archive/web/ipv6/current/msg05627.html as an 
> example), this seems to be something that needs to be at least 
> mentioned in security considerations; that may be sufficient, though 
> if one can easily engineer around it without hurting security, that 
> might not be a bad idea either.
>
> But the bottom line is that if the algorithm is glued in (which may be 
> OK given that you can only spoof the NAT prohibition), I think it 
> needs to be said explicitly (and it might not hurt to get tentative 
> early review from more folks in the sec area).

I think its fine to say the algorithm is "fixed" and that this
is something inherited from main IKEv2 spec.

But note that there's a difference in the algorithm being
fixed as a part of the the protocol versus fixing an algorithm
in an identifier (as in Julien's draft that you pointed) - there
may be ways of upgrading the protocol but identifier upgrading
is much harder.

>
>>> ==> I would also consider splitting out 2.3 in subsections for
>>> readability and more exact references. For example,
>>> initiator's first steps could be 2.3.1, Responder's reply
>>> 2.3.2, initiator's reply 2.3.3, and the exception 2.3.4.
>>
>>
>> Hmm... as it's currently organized, I'm not sure if splitting
>> it would actually improve the readability (it might even be
>> confusing if the subsection suddenly changes in the middle of
>> the description).
>
>
> If others have no opinion, I'm OK either way. It required a bit more 
> work from the reader to figure out which part of the section you were 
> referring to when saying "see Section 2.3" because that includes a 
> number of different things. Above would have made it shorter and 
> easier to point to, but with more careful reading, the current one 
> should be readable as well.

Close call, but I think I'd rather see one big section 2.3
than a set of sub-subsections.

>>
>> I think "includes" is correct, since it's describing a logical
>> necessity, not a choice (where we could discuss whether it
>> should be a MAY, SHOULD or MUST).
>
>
> My reasoning above was, could an implementer try to optimize the 
> protocol so that it will only send NO_NATS_ALLOWED with some but not 
> all update messages (saving bits). I.e., would the processing be any 
> different for the exchange responder if NO_NATS_ALLOWED was sometimes 
> present and sometimes not.
>
> Hence I proposed a MUST implying "if you are going to send 
> NO_NATS_ALLOWED, you have to send it *every time*, instead of just 
> when you feel like it".
>
> But if folks want to leave this a bit more open, that's fine with me..

I'd rather see the if-you-do-this-then-you-need-to-do-it-in-every-message
approach. But I'm not sure if there's need for a MUST; SHOULD appears
sufficient here.

--Jari