Re: issue 11 -- window size

Tero,

> > 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.
> 
The address list update message may not be the next
message as there might be others in the window if
window size is > 1. So, the peer has to wait for a max
of windows worth of messages before it would see the
update with the new address. This could be long if we
have a few addresses to try.

> 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.
> 
Agreed. Perhaps if we can send the UPDATE message
also outside the normal window, the peer can know
earlier. Not sure whether it is a big advantage or
not.

> 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).
> 
Okay, you allow "NAT/attacker" temporarily till the
update message is sent so that you don't have to
modify the retransmitted packet. Can the on-path
attacker (assume that the attacker needs to know the
full message and not just the message-ids),  can
generate lot of packets with bogus address/es and can
cause some meaningful attack ? Anyway, it is required
by IKEv2 today, so we don't worsen the security any
more than what is there today. Will it improve the
current situation if we can update the other end about
the new address before the window clears up ?

-mohan