Subject: [L2tpext] PPPoE Relay over L2TP - Feedback needed

From: "Reinaldo Penno" <[email-masked]>
Date: Wed, 12 Dec 2001 13:21:12 -0800

Hello,

there is a proposal today to tunnel PPPoE Discovery packets over L2TP.
(http://search.ietf.org/internet-drafts/draft-dasilva-l2tp-relaysvc-01.txt).

I have several issues regarding this proposal that I stated during the IETF
L2TP meeting (see below). But, maybe I'm over reacting and I would like to
hear from the PPPoE community their opinions about this. 

The main issues that I see in this proposal are:

1 - The Session_ID looses its end-to-end semantics. The session_id as seen
by the AC is not the one seen by the client. 
2 - The Relay_session_id and AC-Cookie are changed at each hop on the L2TP
cloud, although RFC2516 say this should not be 
    done.
3 - The AC-Cookie is used as a way to pass information (to aid in
determining which tunnel to use over the L2TP cloud) which 
    in one sense is defeating its original or current purposes.
4 - The MAC address of the client is lost, i.e., all sessions come from a
single MAC address (LNS's) from an AC point of 
    view.
5 - The proposal relies on the fact the Relay-session-id is supported by AC
and AC-cookie by the clients.
6 - Support for configurable/expanding timers. Since now the discovery is
going through a possible large cloud, there might 
    be retransmissions of PADI/PADR or maybe some clients will just give up.
The proposal relies on loose definition of PADx 
    retry timers

Maybe there are others issues that I didn't spot. 

My proposal was instead of loosely interpreting 2516 to fit this or that,
that we should investigate a solution that only changes L2TP per se and
leave PPPoE alone.

thanks,

Reinaldo Penno

---

From: "David F. Skoll" <[email-masked]>
Date: Wed, 12 Dec 2001 16:52:43 -0500 (EST)

> by the AC is not the one seen by the client.

I don't think that's a problem.  My PPPoE relay implementation does
not preserve an end-to-end Session-ID.

> cloud, although RFC2516 say this should not be

That's bad.  See later for why it's bad.

> single MAC address (LNS's) from an AC point of

Same thing as a normal PPPoE relay, so not a big deal.

> and AC-cookie by the clients.

This is required by the PPPoE RFC, so not a big deal.

The biggest problem is that all the L2TP nodes have to store a fair bit
of state.  Because of the nature of PPPoE (no authentication on the PADx
packets), this can very quickly lead to a denial of service attack.

For example, I have simple code which sends PADI, waits for PADO, and sends
PADR over and over again in a tight loop.  This can generate thousands
of sessions quickly.  With the L2TP scenario, you could just blast PADI's
at the network and bog the L2TP nodes down with all the state they have
to remember.

--
David.

_______________________________________________
L2tpext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/l2tpext

---

From: "Louis A. Mamakos" <[email-masked]>
Date: Wed, 12 Dec 2001 16:44:29 -0500

Rather than discussion the merits of this particular proposal, I wonder if
the L2TP working group within the IETF is considering a specification of
L2TP transport over Ethernet MAC frames. 

As some of you might recall, I've mentioned before that the lack of
this particular L2TP profile was the driver for the development of PPPoE.
If L2TP was specified over ethernet MAC frames, then the situation posited
by the Internet Draft really turns into concatenation of two different
phsical media for the L2TP tunnel transport.  This might be a "cleaner"
approach.

-- 
Louis A. Mamakos                                    [email-masked]
Distinguished Technical Member
UUNET, a WorldCom Company                           Voice: +1 703 886 5823
22001 Loudoun County Parkway, E1-3-119              Fax:   +1 801 881 9049
Ashburn, VA 20147

Subject: PPPoE Relay over L2TP - Feedback needed
From: "Reinaldo Penno" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Thomas Narten'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'W. Mark Townsley'" <[email-masked]>
Date: Wed, 12 Dec 2001 13:21:12 -0800

Hello,

thanks,

Reinaldo Penno

---

From: "W. Mark Townsley" <[email-masked]>
Date: Wed, 12 Dec 2001 16:10:49 -0700

"David F. Skoll" wrote:
> of state.  

If you think really hard about it, you don't have to store a lot of state. The
implementation we are working on now requires very little additional state (if
any).

> Because of the nature of PPPoE (no authentication on the PADx

In general, an implementation should rate limit such attacks when detected. That
said...

The PADIs are simply forwarded over a single L2TP tunnel. In the implementation
we are working on, the messages are "fire and forget" e.g. no additional state
necessary. 

Assuming what I say here is not bogus, would this alleviate your concerns about
the relay proposal?

Thanks,

- Mark

---

From: "W. Mark Townsley" <[email-masked]>
Date: Wed, 12 Dec 2001 16:04:48 -0700

> phsical media for the L2TP tunnel transport.  This might be a "cleaner"

Well, if I could go back in time I would happily try to develop L2TP over
Ethernet, as well as some discovery protocol of sorts, in L2TP. However, given
that PPPoE exists, I'm not sure how prudent that would be today. 

Assuming L2TP over ethernet with a discovery phase existed, what we would really
be talking about is an L2TP "tunnel switch" from an ethernet segment to an IP
network. What we are doing here now, is trying to provide an interface between
L2TP and PPPoE which leverages what is already deployed as much as possible.

- Mark

>   --------------------------------------------------------------------------------
>               Name: 2826
>    2826       Type: Outlook Express Mail Message (message/rfc822)
>        Description: 2826

---

From: "David F. Skoll" <[email-masked]>
Date: Wed, 12 Dec 2001 20:54:20 -0500 (EST)

On Wed, 12 Dec 2001, W. Mark Townsley wrote:

> If you think really hard about it, you don't have to store a lot of
> state. The implementation we are working on now requires very little
> additional state (if any).

If you're going to monkey with Relay-ID and AC-Cookie tags, you must
store some state.  An AC can issue an AC cookie for its own purposes,
which must be echoed by the host.  And it's conceivable that end-users
could run their own relay agent (I do from time to time), so they will
want their Relay-ID preserved.

I would much rather add additional tags to PPPoE to support any information
required by the L2TP endpoints or relays.  The use of Relay-ID as
specified in the PPPoE RFC is broken; it needs fixing.  You should be
able to add multiple Relay-ID tags and guarantee ordering; that way,
you can relay through any number of stages.  Since we can't easily fix
the RFC, it's better to add new tags that work properly.

> The PADIs are simply forwarded over a single L2TP tunnel. In the
> implementation we are working on, the messages are "fire and forget"
> e.g. no additional state necessary.

Even if the PADI already has a relay session ID tag?

Regards,

David.