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

Replying my own e-mail...

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

Thinking about this further, it seems that sending the
addresses as they currently are is the least bad option
here, as long as we have sufficient warnings about that.

If we want to support multiple addresses for failover,
we need to inform the peer. Yet it would be quite
hard to test all these addresses, or pairs really, to
find out which one of them have a NAT towards the other
peer.

--Jari