Subject: Re: [Mobike] issue 11 -- window size

From: Mohan Parthasarathy <[email-masked]>
Date: Sun, 10 Apr 2005 12:11:25 -0700 (PDT)

> 
> > 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-masked]
> _______________________________________________
> Mobike mailing list
> [email-masked]
> https://www.machshav.com/mailman/listinfo.cgi/mobike
> 
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 11 Apr 2005 14:26:43 +0300

> acquired address to the payload.

If you send separate notification to the other end when ever you
address changes, the responder can check if the source address of the
packet is from that list, and if so it knows there is no NAT.

If the address is not in the list, there is now two possible things:

1) There is NAT between
2) The other end got new address after it started this exchange, thus
it needed to retransmit the packet using this new source address
without telling you. If this is the case, then immediately after you
answer to this the other end will send and address list update message
which should include this address.

So temporarely it seems there is NAT between, but as soon as the
window is cleared then there will be new packet that will update the
address lists so that they have all new source addresses.

I.e. the process flow would be:

CREATE_SHILD_SA -> (lost)

CREATE_SHILD_SA retransmit (with other IPs) -> (lost)

getting new IP address A3

CREATE_SHILD_SA retransmit (with A3) -> (gets through)

<- CREATE_SHILD_SA reply (to A3, notices that A3 is not in list of IPs)

N(UPDATE LIST) (adds A3 to list) ->
<- ACK (notices now that A3 is again on list, so no NAT)

N(MOVE TRAFFIC) -> (lost)

N(MOVE TRAFFIC) (with other IPs) -> (lost)

getting new IP address A4

N(MOVE TRAFFIC) (with A4) -> (gets through)

<- N(ERROR-NAT-DETECTED) (returns error as A4 is not in the list, and
nat prevention set)

N(UPDATE LIST), N(MOVE TRAFFIC) (updates list to have A4, moves traffic) ->

<- ACK (adds A4 to list, moves traffic to new address).

> The attacker cannot modify the IP header anymore.

Yes.