Subject: RE: Fail Over extensions for L2TP: comments welcome

From: "Vipin Jain" <[email-masked]>
Date: Mon, 26 Nov 2001 21:22:58 -0800

Ignacio,

> >We must also keep in mind that this could happen even when fail over 
> >process is not kicking in. For example, without fail over protocol 
> >when an endpoint fails it would establish new tunnels to the peer,
> >it might observe interference with old messages in the network and
> >the similar issues we are discussing now. 
> 
> ...which is the reason for the 'random id allocation' suggestion in
> the RFC. If you allocate tunnel ids from a small set of numbers, your
> chances of reusing the same number increase and with that, the chances
> increase that you may accept an stale packet incorrectly.
How would 'random id allocation', as suggested
in RFC, improve the chance of interference of new tunnel messages with
old tunnel messages? If the goal is to reduce interference
with old messages, the ideal thing would be to use 
'tunnel id circularly'. 
IMHO, the reason for using 'random id allocation' is to
safeguard from allowing someone to detect the next tunnel id
(based on existing tunnel id) and launch an attack.

I agree with you that smaller the set-to-choose-from is,
lesser are the chances for collisions.

> This is basically the same situation as in TCP with its ISS.
Again IMHO, security and not interference-with-previous-TCP segments,
is the primary reason for using a random ISS in TCP.
I don't claim to be anyway near to be an expert on TCP,
but my guess would be that if that
was the goal it could have used "circular ISS" as well..

thanks,
-- vipin

---

From: "W. Mark Townsley" <[email-masked]>
Date: Tue, 27 Nov 2001 06:13:53 -0500

We added the random tunnel and session ID suggestion to the draft when we
removed the Key field (see draft-ietf-pppext-l2tp-03.txt at
www.watersprings.org). The motivation was a simple attempt at prevention against
blind attackers inserting or spoofing data. The random tunnel ID is not a whole
lot of help in some cases, though, given that for several important control
messages, the Session ID is always 0, limiting your random space to 2^16.

For data packets, a random tunnel ID and session ID at least forces a 2^32 tag
on each packet for helping to thwart a blind attacker trying to insert data into
your tunnel. 

As for protecting against stray packets, yes, a "circular" method for choosing
IDs is a better defense. As such, I would recommend some method of avoiding
reuse of a tunnel or session ID within a reasonable period of time (which may
actually decrease the randomness of the values selected).

For L2TPv3, the Key field returns (known now as the Cookie) and the Control
Connection ID is itself 32 bits, so our bases are covered a bit better.

- Mark

> Vipin Jain wrote: