Re: issue 11 -- window size

Mohan Parthasarathy writes:
> 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.

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

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

Yes.
-- 
[email protected]