Subject: RE: Few questions on L2TP..

From: Vipin Jain <[email-masked]>
Date: Wed, 14 Mar 2001 18:45:04 -0800

Ignacio, Mark:

I have commented on your ideas in following with <<vipin>> tags..

-----Original Message-----
From: Ignacio Goyret [mailto:[email-masked]]
Sent: Wednesday, March 14, 2001 10:19 AM
To: W. Mark Townsley
Cc: Vipin Jain; 'Keyur Parikh'; Andy Koscinski; [email-masked]
Subject: Re: Few questions on L2TP..

I normally hate jumping into a heated discussion, but here are my $.02:

Abusing Ns=0 or adding a "reset" bit is just a very bad idea. It makes
L2TP so much more vulnerable to attacks. It also negates any authentication
that may have been negotiated between the two endpoints: how can I verify
that the request to resync is from a bona fide source?

<<vipin>>
Regarding security, as keyur also pointed out, how do you stop a person
from sending a StopCCN on a tunnel; In other words, you are advocating
something like "password digest" to authenticate every message coming from
peer,
like how radius does it.
<<vipin>>

Finally, it is a hack that has been demonstrated to fail (guaranteed!) in
some cases.

<<vipin>>
Not really, if we ensure an implementation following today's rfc2661
legitimately drops the packet because of one of the following:
- the version number of newer packet is different
- the message contains an AVP which it doesn't like
- the message has some header field which it thinks is invalid).

Where as, a newer implementation of L2TP could interpret it correctly and
get something sensible out of it.
<<vipin>>

A *MUCH* better solution is to add new commands to the protocol so that
the failed end can obtain all the resync information over a _new_ tunnel,
as Mark suggested. Whether the remote end supports or not these new
commands can easily be determined by a judicious use of the M-bit or
by using a different number in AVP 2, or even with a new AVP (resync
capable)
added to the SCCRQ and SCCRP. This is a significantly more robust design
since it will allow you to select different strategies depending on the
capabilities of the remote endpoint.

<<vipin>>
Relying peer to give all information over a new tunnel has following
problems:
- it invites a significant amount of traffic during resync and probably
that's when you would want to avoid all un-necessary traffic flowing between
you and peer as there is already a dozen of other things going on when a
failover occurs.
- more serious problems like peer can propagate incorrect information to
you.

Asking peer to restart sequencing (using "resync bit" was just one way to do
it) is much more cleaner.
<<vipin>>

If you were to implement something like the Ns=0 hack, I think you have a
duty to warn your customers that your box is not 2661-compliant and that
this non-compliance may lead to unexplained behavior and failures.
<<vipin>>
As of today, nobody should claim it will be 2661 compliant..
IMHO, that's doesn't mean we should stop trying to work on a cleaner way of
solving problems.
<<vipin>>

thanks,
vipin

At 11:50 AM 3/14/01 -0500, W. Mark Townsley wrote:
>Vipin Jain wrote:
>> 
>> Mark,
>> 
>> Agree with most of your ideas. 
>> I wanted to add the following:
>> Querying or probing peer about your state is different from asking peer
to
>> reset sequence number and retransmit control packets which has not been
>> acknowledged. 
>
>OK, so you are suggesting that we tell a peer to *start over* at a new
>sequence number. Make sense, except that (1) you have to ensure that
>there are no local messages that you may have acknowledged but did not
>transfer state of to your backup node yet (possible, but if we really
>want to talk about scaling then this can be limiting), (2) this requires
>your peer to poke down into its transport level unsent queue and
>resequence messages (nasty layer violation), (3) this is not at all
>extensible, (4) most importantly, this is NOT backwards compatible
>(illustrated below).
>
>> Following can be fairly easily implemented and backward
>> compatible as well:
>> 
>> * After fail over/shutdown on LNS (or LAC) when redundant one takes over,
it
>> initiates a packet on tunnel with Ns=0, Nr=0 and "reset sequence bit"
set.
>> * LAC (or LNS) responds with first acknowledged packet with Ns=0 Nr=0 and
>> "reset sequence bit" set
>
>An implementation that does not support the reset bit could consider
>this a valid "future" packet and simply drop it. Again, run your logic
>with Ns=100, Nr=100 and tell me if it works in a backwards compatible
>manner. There is NOTHING SPECIAL about Ns=0 and Nr=0 to the L2TP
>transport unless the TunnelID=0 as well (the zero TunnelID being the
>more important of these fields).
>
>Further, an implementation MAY update its resend queue with the Nr
>present in an out of order packet (see the l2tpbis draft). So, your Nr=0
>could end up inadverdantly acknowledging a lot of packets. I know of at
>*least* one widely deployed implementation that does this, so get ready
>for some hard to figure out bug reports if you deploy this non-standard
>extension in a multivendor environment!
>
>> * LNS (or LAC) responds to it with Ns=0 Nr=0 without "reset sequence bit"
>> set.
>
>The following steps are not completely clear to me, but it doesn't
>matter as the step above breaks backwards compatibility already.
>
>> * After having sent a packet with Ns=0 and Nr=0 and "reset sequence bit"
>> set, if LAC or LNS receives a packet with Ns or Nr with NOT EQUAL to ZERO
it
>> considers it out of sequence.
>> * They can then start exchanging control packets as they were before.
>
>> * Data plane can use the same logic if it wishes.
>
>There is no concept of "replying" on the data plane, so I don't see how
>this same logic can be applied. Also, treating Ns=0 as somehow "special"
>on the data plane is as incidious as it is on the control plane. Nr on
>the data plane is just a reserved field, you cannot use it for anything.
>
>If you just want to set an "R-bit" ala the old flow control days to
>reset your requence numbers, fine, I guess that would work to signal
>your peer to accept an out of order packet (assuming it is even
>checking). But, this adds a bit to the data plane and makes the data
>header even more complex than it already is. I still think for the data
>plane you could just start over at 0 and let the peer drop a couple of
>packets (again, assuming it is even checking sequence numbers).
>

---

From: "W. Mark Townsley" <[email-masked]>
Date: Wed, 14 Mar 2001 23:38:11 -0500

> something like "password digest" to authenticate every message coming from

A StopCCN attack is a Denial of Service attack. Even so, in a blind
situation you have to guess your peer's tunnel ID and the proper Ns for
the tunnel. The "reset bit" proposal negates the second item here,
reducing the values one has to guess down to just 16 bits.

> - the message has some header field which it thinks is invalid).

Changing the version number in the header for one new feature is a bit
drastic. Header bits are precious.

> you and peer as there is already a dozen of other things going on when a

Let's see.

First, assume that there is only one tunnel between a given LAC and LNS:

- If you consider a hot standby case, the control connection could
already be setup between the standby and the peer, waiting for a state
update in case of a failover. One control connection should not take up
considerable resource, and you peer has the bonus of knowing that your
standby is ready and waiting in the wings.

- If you consider a restoration after reboot case, sending 3 packets for
tunnel setup is likely insignificant to the time it took to reload the
box.

As a more pathological example, suppose I have 2000 tunnels between an
LAC and an LNS and one side goes down. With the "reset bit" method, I
have to send 2000 packets of some sort with the reset bit to resync.
With the #2 proposal I sent earlier, I bring up one control connection
and can obtain whatever state information I wish to compact within a
single control message exchange, potentiall one message for all 2000
tunnels (Ignacio pointed out to me that RFC 2661 removed the 1500 byte
control message limitation somewhere along the way, so if you don't mind
your control messages potentially being fragmented by IP, then you could
packet one message chock full of whatever you wish... I still think it
is probably prudent to keep it under 1500 in separate messages though).

> - more serious problems like peer can propagate incorrect information to

If your peer is going to lie to you then you have much bigger problems
at hand.

> As of today, nobody should claim it will be 2661 compliant..

Interesting accusation.

> IMHO, that's doesn't mean we should stop trying to work on a cleaner way of

Using bits in the header (so far you are suggesting at least two, one
for the "reset" bit and one for the header version increment) for new
features that can be just as well served with control messages and AVPs
is not a good use of the few header bits we have.