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

From: Mohan Parthasarathy <[email-masked]>
Date: Mon, 11 Apr 2005 11:22:45 -0700 (PDT)

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

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

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 12 Apr 2005 11:27:43 +0300

> have a few addresses to try.

I do not consider this a problem. When the first message of the window
is ACKed then the other end can send the notification packets to
inform about the situation.

Only thing this will do is to delay the updating of the address list
for some fraction of seconds while this is busy processing messages in
window.

In normal case there will not be any messages (or there will be one
DPD message) in the window.

> earlier. Not sure whether it is a big advantage or

The peer could get the information a bit earlier, but I do not really
consider NAT prevention that important feature that it needs to be
communicated immediately to the other end, I think we can wait for a
round trip for that.

And if we do not use NAT prevention we do not even need the update
packets, we only need move traffic style packets, but for those we
need to know the working address pair anyways, so we want to finish
the address pair discovery before we send those anyways.

> modify the retransmitted packet.

No, I do not allow it (if the NAT prevention is turned on), I tell the
other end that there is NAT/attacker, your request was rejected, i.e.
we do allow replying to packets, but we do not allow it to be there
for IPsec traffic.

> Can the on-path
> cause some meaningful attack ?

He can get us to retransmit replies for each request he sends to
address specified by him (reflection attack), but he cannot amplify
the number of messages (i.e. there will not be more messages sent to
given address than what was sent by attacker). 

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

I do not think it will help.

It might remove a bit of latency when you loose the only address you
have, but we are talking about one round trip or so.

But I think we are talking too much about the actual protocol, we
should get back to upper level issue 11.

My hole point of going in the details of protocol was just to say that
it could be done this way too. Now we need to decide which way we want
it to be done.
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike