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

 In your previous mail you 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.
   
=> IMHO this problem is only for MOBIKE itself (where a private of
a node behind a NAT has no meaning, i.e., it can put anything) but
not for NAT detection/prevention: I asked why NAT detection
uses a hash and not the addresses themselves and the answer was
exactly because some people were concerned that NAT detection would
reveal the internal topology (so a) applies in the real world).

   > 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.
   
=> there is a point about this: I'd like to drop the "middle ground",
i.e., to make the usage of either NAT detection or NAT prevention
mandatory. My idea is to get a mandatory protection of the addresses
in IP headers (as they'll become the endpoint addresses of IPsec SAs)
but your argument is good too.

   > (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)
   
=> this opens a threat what I called the "transient pseudo-NAT attack"
but it is not a new threat, just an ignored threat. BTW, it is easy
to fix: the addresses in the IP header should simply be reflected in
some way into the IKE payload. This is why I propose to enforce the
usage of NAT detection/prevention which does that for the first exchange.

Regards

[email protected]