Re: Issue: NAT-T interaction (#3)

Mohan Parthasarathy writes:
> I should not have asked two questions in the same place.
> I am not sure to which you said "No" :-)   I guess you were
> refering to the process to detect that you are behind NAT..

My answer was mostly saying that there are all kind of options. 

> > The detection goes so that you send address update to the address you
> > have behind the NAT, and the other end see that the outer IP-address
> > of the address update packet differes from the contents of address
> > update. It will now know that :
> > 
> > 1) There is attacker between modifying the packet outer
> >            headers
> > 2) There is NAT between.
> > 
> > Now, it have two options. Either ignore the address update packet it
> > was modified by the attacker or continue.
> > 
> > Next it does return routability check for the address given in the
> > address update packet. If that fails, it will know that it either was
> > malicious client in the other end or there was NAT between.
> > 
> > If the RR check successed, it knows it was probably attacker
> > modifying the packet.
> > 
> Ah! I missed this part.

This wasn't really explained anywhere, I was just thinking the things
at the same tiem I wrote the message.

> > That would require that our address update packets also include the
> > port numbers for the IKEv2 traffic. Also securely finding out the
> > external IP address of NAT is impossible with the normal NATs out
> > there. 
> > 
> I at least know the external IP address of my NAT at home :-) It seems
> to be reasonably stable. Assume i am reading my company email on the way
> home (connected to my company through the IPsec tunnel) and i get into my
> house where there is a NAT, but still would like to read my email without
> disruption/packet-loss :-) 

True. I have similar setup in my home, and the NAT is actually
configured to be static for my laptop (it will always get the same
external IP, only allocated for it). Perhaps we need to think whether
the protocol should take account those things too... 

> > > There is no 3rd party bombing attack as your RR
> > > would succeed if the address used is a proper address or it would
> > > fail if the attacker used some random address. This assumes that
> > 
> > The attacker can modify the packets source IP (just like NAT), and it
> > can then grab those RR packets from the net (it needs to be along the
> 
> If the attacker modifies the source address on the address-update
> packet before it reaches the other end, then the peer will detect
> that the source IP does not match the address (the public address of
> NAT) contained in the payload (which is protected) and hence can
> decide either to drop the packet or do RR on the address contained
> in the payload. So, i am missing something..

The data in the payload is the address behind the NAT, not the exteran
address of the NAT, thus attacker and NAT look identical. In both
cases the outer IP address and the address inside does not match.
There is no way to know wheter it was attacker who modified the packet
or whether it was NAT (which actually is an attacker who modifies the
packets :-)
-- 
[email protected]