Re: issue 11 -- window size

 > 
> > I was talking about  an "option" for detecting the
> presence of  NATs
> > securely where you don't accept blindly what you
> see in IP headers but also
> 
> There is no way to detect NATs securely, unless you
> have co-operation
> of NAT. NAT is an attacker on the way from initiator
> to the responder
> who changes the IP-addresses. There is no way to
> distinguish that from
> the real attacker, without changing NATs. 
> 
Agreed. I wanted to say something and wrote something
different. But if there are other protocols (outside
of MOBIKE) used to detect NAT and also learn the
bindings, can we use MOBIKE to carry that information
?

> > check the payload (if address is present in the
> MOBIKE NAT-D
> >  payload) to see if the address on the IP header
> is same.
> 
> It is easy to securely detect that there is NO NAT
> between, and that
> does not require changing of packets for
> retransmission. We simply
> need to keep the other end up to date which
> addresses we might be
> using, and if the address is one of those, then
> there is no NAT
> between. 
>
I am not sure i follow this. If i am moving and
acquiring a new address, you have to tell the other
end about the new address securely for detecting "NO
NAT" securely. This implies that the packets have to
change in retransmission. You could not have told
about the new address beforehand. So, if we want to
prevent NAT from appearing in the path
(NAT_PREVENTION), you still need to add the newly
acquired address to the payload.

Now if there is some other protocol outside of MOBIKE
which can tell us what the NAT binding is (e.g.
MIDCOM), i can use the same mechanism (as in
NAT_PREVENTION above) to tell the other end about
what address is allowed to appear in the IP header.
The attacker cannot modify the IP header anymore.

-mohan

> -- 
> [email protected]
> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike
>