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

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

As i mentioned in my first mail, i assume that i can learn the public IP
address of my NAT (which is possible in my home case) and i include that
in the MOBIKE address exchange packet. Yes, it involves more work in
terms of getting the address in most of the cases. Assume i get the public
address of my NAT, wouldn't this work ? 

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

-mohan