Subject: FR Service Type

From: Danny McPherson <[email-masked]>
Date: Wed, 21 Mar 2001 13:09:55 -0700

Andy,
You mentioned "several apparent shortcomings" in the 
L2TP Service Type draft in the WG session today.  We 
definitely appreciate your input and ask that you 
provide the mailing list specific pointers to the 
problems you see with it. 

Aslo, if you could provide the list of pointers you 
mentioned we should be referencing that'd be of 
great benefit as well.

Thanks!

-danny

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 21 Mar 2001 17:42:00 -0500

Danny,

For the benefit of the people on the list that weren't at the meeting 
today, it was draft-vasavada-l2tpext-fr-svctype-00.txt I was commenting 
on.  Here are some specific comments:

1. Most importantly, given the wide and mature implementation of FR 
switches and deployment of FR networks, there are a number of specific 
requirements that service providers must meet in order to carry frame relay 
traffic for paying customers - if you don't meet those requirements, end 
users will go elsewhere.  By far, the easiest way to get the requirements 
for transporting FR traffic over another technology is by reading FRF.5 
(http://www.frforum.com/5000/Approved/FRF.5/FRF5.PDF).  While this document 
is specific to FR over ATM, it's easy to see, such in sections 1-3, what 
the general requirements are, and in sections 4.2 through 4.4, what is 
required regarding error reporting, congestion indications, and such in the 
data path, and in section 5, what is required for traffic management and 
PVC status signaling.  FRF.5 can easily be used a blueprint for any 
specification to carry FR over a different technology, such as this one.

2. I very much agree with Mark's concern, as he stated in the meeting, that 
FR frame contents need to be protected.  There are any number of ways of 
doing so, such as requiring the UDP checksum (even though it is weaker than 
the FR FCS), carrying the FR FCS end-to-end, adding a new FCS, etc.  But 
you need something.

3. FR frames are often much larger than typical IP network MTUs - almost 
all FR switches support frames up to 4K octets, and some support up to 
8K.  You're going to need fragmentation of some sort.  Rather than using IP 
fragmentation, I would rather suggest that you use FRF.12 
(http://www.frforum.com/5000/Approved/FRF.12/frf12.pdf) at the tunnel 
endpoints.  FRF.12 is very easy to implement, in that it is largely based 
on RFC 1990, which is itself very widely implemented.

4. Rather than referencing ANSI T1.618 (reference 4), which is obsolete, 
you should instead be referencing ITU-T Q.922 for FR core aspects and Q.933 
for PVC status signaling.

5. FR users have expectations that CIR really does mean committed bandwidth 
over the window measurement interval.  That needs to be acknowledged in the 
draft, and there needs to be a mechanism to commit the bandwidth, unless 
you specifically only intend to be able to carry CIR=0 (e.g. best effort) 
VCs, in which case this should be made explicit.

6. I highly agree with the text in section 7.3.  I suggest borrowing text 
from FRF.5.

That's about it for now.  I'll send more comments as they occur to me.

Cheers,
Andy

-------------------

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 22 Mar 2001 16:03:52 -0500

Mark,

Thanks to you as well for the history.  We're certainly on the same page, 
as FR's native data integrity mechanism is stripped off in the current 
draft, leaving no protection at all for the data, which violates the FR 
service specification.

Cheers,
Andy

-----

At 3/22/2001 03:34 PM -0500, W. Mark Townsley wrote:

>Thanks, Andy. A comment on one item below.
>
>"Andrew G. Malis" wrote:
>
>I am certainly concerned about sending data without any checksum or CRC
>protection.
>
>However, let me outline what I have seen happen with the deployment of
>PPP tunneling over the years.
>
>As with the Frame Relay document, L2TP defines that the PPP FCS be
>removed before encapsulation and sending to the LNS. Further, in RFC2661
>the UDP checksum is defined as optional, but MUST be configurable as
>present or not. This was the compromise reached between two camps, each
>with their own strong beliefs. As it turns out, most deployments I have
>seen keep UDP checksums turned off. For better or for sorse, the desire
>for performance seems to have one out over the desire for integrity
>checking for the entire UDP payload.
>
>Given this fact, I would like to identify some of my thoughts on the
>implications. First, in many cases the tunneled payload has its own
>checksum present anyway. That is, if you are carrying an IP/UDP packet
>within PPP, it likely has its own IP and UDP checksum covering the
>packet. Any additional checksum at the UDP/L2TP layer for the payload
>would be certain duplicate effort. If we assume this is the case, then
>this leaves only the L2TP header and PPP framing itself unprotected.
>That is, there are a few bytes (anywhere from 7 to 16 or so) in the
>entire packet that are not covered by a checksum above the lowest link
>layer.
>
>The worst case scenerio of this is that a bit gets flipped in 32 bits of
>the L2TP session or tunnel id that just *happens* to correspond to an
>active tunnel and session between the same two peers. This could result
>in a data packet being sent down the wrong tunnel. Apparantly, customers
>have converged on the liklihood of this being small enough that they are
>not willing to turn on UDP checksums to provide the additional assurance
>that it doesn't happen.
>
>Of note is the fact that the early versions of L2TP had a fixed, 32 bit
>"cookie" that sat in the header of every data packet that was derived
>from authentication data computed during session startup (essentially an
>agreed upon random value). This was ultimately tossed out citing it as a
>weak attempt at "security" that was open to attacks, etc. (we made the
>semantic mistake of calling this a "key" and identifying it as a
>"security" feature which offended some). It seems that this was
>shortsighted as this cookie would have served well to protect against
>the above scenerio.
>
>- Mark

---

From: "W. Mark Townsley" <[email-masked]>
Date: Thu, 22 Mar 2001 15:34:20 -0500

- Mark

---

From: "W. Mark Townsley" <[email-masked]>
Date: Thu, 22 Mar 2001 16:58:40 -0500

> draft, leaving no protection at all for the data, which violates the FR

There is still *some* protection for the data. Perhaps my reply was too
long-winded, but embedded within the paragraphs was the following

> >entire packet that are not covered by a checksum above the lowest link

To restate, in the typical case, any IP packets being carried within the
tunnel actually does have protection (though likely not as reslient as a
FR or PPP CRC). It is only the bytes between the interior tunneled
packet and the outer IP header that remain unprotected. 

- Mark

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 22 Mar 2001 17:04:47 -0500

Mark,

Agreed on IP.  However, it's important to note that there are also non-IP 
applications for FR (SNA, FRADs, fragmentation headers, etc.) that depend 
on the FR FCS.

Cheers,
Andy

--------

---

From: "W. Mark Townsley" <[email-masked]>
Date: Fri, 23 Mar 2001 11:17:05 -0500

> applications for FR (SNA, FRADs, fragmentation headers, etc.) that depend

Certainly. Same with PPP, the PPP CP negotiation and keepalive packets
are not protected without a UDP checksum.