Re: issue 11 -- window size

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

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.

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

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.

> Okay, you allow "NAT/attacker" temporarily till the
> update message is sent so that you don't have to
> 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
> 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 ?

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 protected]