Re: Issue 60: Addresses in IKE_SA_INIT/AUTH (was: Comments of draft-ietf-mobike-protocol-04.txt)

Jari Arkko writes:
> Having read through this thread, I tend to agree with
> Pasi on this, i.e., take the addresses from where they
> are currently taken from and use NO_NATS_ALLOWED
> where its currently in.
> 
> I do not think the leakage of addresses is an issue, and
> if it is, we are already doing it in ADDITIONAL_*_ADDRESS.
> The rest of the issue is really a debate about aesthetics
> and complexity of variant 1 or variant 2; personally I think
> what's in the document right now seems better.

I have really started to hate different variations in the protocol. It
causes lots of different new tests to be done. In the last interop we
already did around 50 different tests to get through the  basic
exchanges. That didn't include testing different ciphers or macs, only
different variations of the IKE protocol (auth methods, rekeying,
cookies, invalid ke notify, liveness, basic NAT). The more versions of
protocol we have for mobike, the more complex test matrix we need to
generate for it too. 

> Here's a suggested addition to the Security Considerations,
> Section 6.5, after the fourth paragraph:
> 
> The use of NO_NATS_ALLOWED will also disclose the
> internal address to the peer, in case NAT was in the path.
> However, this has relevance only if the node is configured to first
> try with NO_NATS_ALLOWED and only then fallback to
> the use of NAT traversal if that fails.

NO_NATS_ALLOWED discloses the internal address to the WORLD, not to
the peer.

It relevant in case NO_NATS_ALLOWED is ever configured, and that node
is ever behind NAT whose IP-addresses adminstrators are not willing to
disclose. The fallback case is not the only case it is also about
misconfigurations.
-- 
[email protected]