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

Inline.. (in the interest of brevity, I've removed parts which we 
agree on explicit response doesn't seem necessary).  Let's hope this 
gets past the size limitations..

On Mon, 19 Sep 2005 [email protected] wrote:
>> substantial
>> -----------
>>
>>    Note that if some of the initiator's interfaces are behind a
>>    NAT (from the responder's point of view), the addresses
>>    received by the responder will be incorrect.  This means the
>>    procedure for changing responder addresses described in
>>    Section 2.4 does not fully work when the initiator is behind
>>    a NAT. [...]
>>
>> ==> this is probably something that needs more air time.  What
>> does "does not fully work" mean?  This also probably applies to
>> the responder, though in different ways.  This may also have
>> security implications (exposing internal topology), and it may
>> affect address selection (if for example smaller scope
>> addresses are preferable, but actually belong to different
>> sites).  This probably needs a bunch of more analysis...
>
> Yes, this is something that probably deserves a slightly longer
> explanation (but I don't think we should spend too much time on
> it). How about this?
>
> 1.3  MOBIKE and Network Address Translation (NAT)
>
>   In some MOBIKE scenarios the network may contain NATs or stateful
>   packet filters (for brevity, the rest of this document talks simply
>   about NATs).  The NAT Traversal feature specified in [IKEv2] allows
>   IKEv2 to work through NATs in many cases, and MOBIKE can leverage
>   this functionality: when the addresses used for IPsec SAs are
>   changed, MOBIKE can enable or disable IKEv2 NAT Traversal as needed.
>
>   Nevertheless, there are some limitations.  NATs usually introduce an
>   asymmetry in the network: packets reaching the NAT from the "inside"
>   are treated differently from packets coming from the "outside".  This
>   asymmetry leads to restrictions on what MOBIKE can do.  To give a
>   concrete example, consider a situation where both peers have only a
>   single address, and the initiator is behind a NAT.  If the
>   responder's address now changes, it needs to send a packet to the
>   initiator using its new address.  However, if the NAT is, for
>   instance, of the "restricted cone" type (see [STUN] for one
>   description of different NAT types), this is not possible: the NAT
>   will drop packets sent from the new address (unless the initiator has
>   previously sent a packet to that address -- which it cannot do until
>   it knows the address).
>
>   For simplicity, MOBIKE does not attempt to handle all possible NAT-
>   related scenarios.  Instead, MOBIKE assumes that if NATs are present,
>   the initiator is the party "behind" the NAT, and does not fully
>   support the case where the responder's addresses change.
>
>   "Does not fully support" means that no special effort is made to
>   support this functionality.  However, if the alternative is losing
>   connectivity completely, the responder can still attempt to proceed
>   with the change, and depending on, e.g., the exact type of NAT, it
>   may succeed.  However, analyzing the exact circumstances when this
>   will or will not work is not done in this document.

This is good description of some of these problems (suitable in the 
introduction as you put it), but I'm not sure if it addresses all the 
open questions.

If I understand correctly, if the initiator is behind a NAT with IP 
address 10.0.0.1, it will tell the responder in MOBIKE exchange that 
its IP address is 10.0.0.1.  At least two issues sprang to my mind:

   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.

   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.

>>   When the initiator is behind a NAT, it SHOULD include these
>>   payloads in DPD messages, and compare the received ...
>>
>>   When MOBIKE is in use, the host not behind a NAT SHOULD NOT
>>   use the dynamic updates specified ...
>>
>> ==> How does the MOBIKE code know whether you're behind a NAT?
>> Is this done automatically as part of IKEv2 NAT detection?
>> Note that the spec doesn't seem to require running NAT presence
>> detection so with current spec this can't be done.
>
> Yes, this is done by IKEv2 NAT Traversal already (so saying
> that it must be done would be redundant).

To a person like me who didn't know what kind of NAT detection 
exchange is done by IKEv2 (and whether that's mandatory to implement 
or mandatory to enable), this didn't spell out how MOBIKE knows 
whether it's behind a NAT or not.  If it could fit somewhere neatly, 
it would likely help a bit.

>   "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..

>>    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).

>> semi-editorial
>> --------------
>>
>> ==> there seem to be a number of assumptions scattered
>> throughout the document (e.g., relating to the responder not
>> being behind a NAT) -- maybe it would be useful to put these as
>> a new subsection of the Introduction?
>
> This particular assumption is actually mentioned in the
> Introduction section (and gets better treatment in the proposed
> NAT text above). Were there any others you had in mind..?

Maybe minor ones like the assumptions on what other elements need to 
be implemented (but which aren't specified here, like address 
selection), but it may be that those don't need to be mentioned up 
front.

>> ==> 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.

>> ==> It might make sense to spell out, probably in section 1.2,
>> that apparently (AFAICS) the initiator never tells the
>> responder which addresses it takes to use.  It just sends
>> UPDATE_SA_ADDRESSES with the updated addresses (inmplicit
>> update).
>
> It does tell the responder, by sending UPDATE_SA_ADDRESSES.
> I'm not sure how it could be more explicit than this...?
>
> (Or are you referring to the detail that the addresses are not
> contained inside the IKEv2 payload, but in the IP header?)

Exactly, only in the IP header.  (I haven't analyzed whether this may 
or may not open any new threats, because the IP address is not secured 
as it's from the header.. I think those were described at sufficient 
length already)

>>      HDR, SK { IDi, [CERT], [IDr], AUTH,
>>                 [CP(CFG_REQUEST)]
>>                 SAi2, TSi, TSr,
>>                 N(MOBIKE_SUPPORTED),
>>                 [N(ADDITIONAL_*_ADDRESS)+]  -->
>>
>> ==> this raises a minor issue of the normativeness of this spec
>> with regard to the non-MOBIKE -related IKE payloads.  The above
>> exchange is just an example; some other payloads could be
>> included as well, or some listed above could be omitted.  Also
>> the optional/mandatory status might change.  Perhaps the
>> document could give a short disclaimer about the IKE exchange
>> examples.
>
> Right... How about adding this:
>
>   In some cases, the diagrams also show what payloads defined in
>   [IKEv2] would be typically included in, for instance, the
>   IKE_AUTH exchange. These payloads are shown for illustrative
>   purposes only; see [IKEv2] for an authoritative description.
>
> to section 1.3, after the first paragraph?

Looks excellent.

>> ==> this is actually a good issue in more general.  Is it worth
>> the effort to do so in the first place? That is, couldn't we
>> just specify that the requests be sent with different cookies
>> for each destination. I don't think a hash is computationally
>> all that expensive.  That would simplify the spec and eliminate
>> an extra roundtrip in some cases.
>
> This would require everyone to support large "window sizes", and
> based on feedback we've received from implementors, most of them
> don't plan to support anything else than 1.
>
> (MOBIKE in general would be _much_ simpler if the designers of
> IKEv2 had done the reliability/windowing parts slightly
> differently...:-)

That's a bit unfortunate but it's fine with me..

>>    NO_NATS_ALLOWED payloads can also be included when changing
>>    the addresses of IPsec SAs (see Section 2.3) and updating
>>    the additional addresses (see Section 2.4).  An initiator
>>    using this "NAT prohibition" feature includes a
>>    NO_NATS_ALLOWED payload in all address update messages.
>>
>> ==> s/includes/MUST include/ or..?
>
> 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..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings