Re: Issue 59: Editorial comments from Tero (was: Commentsof draft-ietf-mobike-protocol-04.txt)

[email protected] writes:
> Tero Kivinen wrote:
> > 
> > [email protected] writes:
> > > NO_NATS_ALLOWED is a bit different: since it's used only when we 
> > > know beforehand that there are no NATs, so it contains the same 
> > > address as the IP header -- so encrypting it does not provide
> > > anything extra...
> > 
> > I disagree with that. How can we know there is no NAT between
> > beforehand? We have not tested the path or anything, so we do not know
> > if there is NAT or not. We can hope there is no NAT, as if there is
> > one, then we cannot establish connection, but we cannot know anything
> > about presense of NATs.
> > 
> > Even if our configurations says there must not be NATs between us, it
> > does not mean that this is necessarely true, and it does not mean that
> > we can reveal the IP-addresses to the listeners.
> 
> NO_NATS_ALLOWED means that your policy is not to use the link if it
> contains a NAT. IMHO this policy implies that you're not especially
> concerned about revealing your IP address.

I might not be that much concerned, but the network I am using might
be concerned. I personally think that the internal IP-address space
used in any network do not have any security implications, so we can
freely tell it to the world. Some people do not feel that way, and
they might not like that misconfigured machines will tell the internal
IP-addresses out.

I mean if the employee actually goes and actively posts all the
ip-address information to the public web-page he can be fired because
he violated the company policy. If the employee has misconfigured
IPsec client for that environment (but completely valid configuration
in other environments) he really cannot be fired because of that...

If there is anybody who feel that IP-addresses needs to be proteced,
the same person will also want them to be protected even in case the
user using his network has a configuration error in his machine. 

> (And like I already mentioned in the mail about issue 60, NAT Traversal
> reveals the addresses, too, as is clearly said in the IKEv2 spec.)

Digging out the IP-addresses from IKEv2 packets is a bit more work
than simply getting reading them from the net. I mean it is actually
much cheaper to act as a man in the middle in the exchange and check
out the ID payload, than to dig out the IP-addresses used in the
NAT-T. On the other hand storing all the NO_NATS_ALLOWED packets going
past you in the net is again much cheaper than either one of those two.
-- 
[email protected]