Subject: [L2tpext] Last Call for draft-dasilva-l2tp-relaysvc-03.txt

From: "W. Mark Townsley" <[email-masked]>
Date: Tue, 02 Jul 2002 16:43:37 -0400

This is last call for draft-dasilva-l2tp-relaysvc-03.txt

I will advise the Area Directors on Aug 1, 2002, to take this draft to
Proposed Standard unless there is substantive comment raised on this list.

Thanks,

- Mark

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

---

From: "David F. Skoll" <[email-masked]>
Date: Tue, 2 Jul 2002 21:29:37 -0400 (EDT)

Hi, Mark.

Some comments:

Why is "Service Relay Request Message" abbreviated "SSRQ" instead of
"SRRQ"?  Same for SSRP vs. SRRP.  If the other abbreviations are already
taken, perhaps the full names should be changed to match.

Ah, wait; later on, it is abbreviated SRRQ.  I guess it's a typo
near the top.

Near the bottom of Page 4:

"The MAC address of the PADO MUST be the same as that which was utilized..."
PADO should read PADS.

Top of page 7: Having multiple Host-Uniq and AC-Cookie tags will break
some real-world implementations (like mine) which assume that at most
one Host-Uniq or AC-Cookie tag will appear per frame.  It's pretty
easy to fix my implementation, but you'd best check with others.

It is safer but a bit more work to simply add to an existing tag
at each hop.

For example, if a PADI comes in with a Host-Uniq tag with 8
octets of data, you can add additional octets something like this:

2 octets -- original size of Host-Uniq tag (0xffff = no original Host-Uniq tag)
4 octets -- some magic value for verification
n octets -- any data required by the relay

so the final length is 8+2+4+n octets.

The relay can then "peel off" the data in the reverse direction to get
back to the original value of the Host-Uniq tag.  The downside is that
this limits the data to a total of 255 octets instead of 255 octets
per tag.

Regards,

David.

---

From: "W. Mark Townsley" <[email-masked]>
Date: Wed, 03 Jul 2002 09:40:43 -0400

"David F. Skoll" wrote:
> "SRRQ"?  Same for SSRP vs. SRRP.  

I think that's a bug.

> If the other abbreviations are already

Yup. Noted.

> "The MAC address of the PADO MUST be the same as that which was utilized..."

Thanks.

> easy to fix my implementation, but you'd best check with others.

I hope that I never suggested sending multiple tags here.

> It is safer but a bit more work to simply add to an existing tag

That is the intent, I will double check the text.

> this limits the data to a total of 255 octets instead of 255 octets

Right. I added some text this round warning against the 255 octets, and
mentioning that if you need more than this (gosh, I hope not, but I suppose it
is possible) then you should move to a stateful tag value method.

---

From: Vipin Jain <[email-masked]>
Date: Wed, 3 Jul 2002 15:46:41 -0700 (PDT)

Mark, Ron:

few comments..
> 2.1 PPPoE Active Discovery Stage
>  <snip>
>
>    The PPPoE Relay AVP is sent via the Service Relay Request (SSRQ)
>    message defined in Section 3.  The SSRQ message MUST NOT be sent to
>    an L2TP node which did not include the PPPoE Service Relay Response
>    Capability AVP during control connection establishment. If no
The two capabilities are a little confusing:
First, "Relay Forward Capability" that says relay messages
could be forwarded (sent) by this L2TP peer;
So then typically LAC would qualify for this capability.
If not then defining another type of capability "Relay
Respone Capability" is not of much use because LAC and LNS both would
must have forward capabilities and "Response" capabilities are the subset
of forward capabilities.

If these two capabilities define two different things then, something
mentioned in the above section might not be true because 
it should be possible for a node to _not_ get "forward capability"
and still be able to send SRRQ messages, because it has "response capability".
I hope I am clear..

>    Upon receipt of the SRRQ, the included PPPoE PADI message MUST be
>    processed as described in [RFC2516], be relayed to another L2TP
>    control connection, or be relayed to another PPPoE AC. Care must be
>    taken if there are multiple destinations for a given relayed PAD
>    message. See Appendix A for more information on relaying across point
>    to multipoint configurations.
I am wondering is that when an AC (LAC here using the same MAC Address)
sends multiple PADOs with different AC-Cookie-Tag, would the client
consider them coming from different ACs and distinguish them based
on AC-Cookie-Tag? IMHO rfc 2516 doesn't discuss as much; Ideally the
implementations should consider multiple PADOs from the same MAC
address to be different and respond to the one it accepts the
offer from, copying back the AC-Cookie-Tag.
May be PPPoE Client implementors can confirm this.

> 2.2 Session Establishment and Teardown
>
>  <snip>
>
>    Upon receipt of an L2TP ICRQ message, the LNS parses the PADR message
>    as described in [RFC2516]. If this is an acceptable PPPoE service
>    connection (e.g. the Service-Name-Error TAG would not be included in
>    a PADS response), the L2TP ICRP message that is sent to the LAC
>    includes the resultant PPPoE PADS encapsulated within the PPPoE Relay
>    AVP. If the service is unacceptable, the PADS with a Service-Name-
You may want to mention that an LNS could forward the PADR to the ACs,
if not consume itself;

In the same context, where the LNS gets multiple PADOs for a
given PADI(either intermediate tunnel-switch node or the end LNS that
connect to ACs): Can an SRRP contain multiple 'PPPoE Relay AVP' AVPs?
If so, is LAC suppose to generate multiple PADOs for each PADO
in the Relay AVP? It would be nice to clarify the same.

Rest of the draft looks good to me.

thanks,
-- vipin

> Proposed Standard unless there is substantive comment raised on this list.

__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com

---

From: "David F. Skoll" <[email-masked]>
Date: Wed, 3 Jul 2002 20:43:54 -0400 (EDT)

On Wed, 3 Jul 2002, Vipin Jain wrote:

> on AC-Cookie-Tag?

No.  Clients are supposed to treat AC-Cookie as a black box.  They distinguish
PADO's only by MAC address, Service-Name tag(s) and AC-Name tag(s).  If
an LAC sends multiple PADO's, they should contain different AC-Name tags.

Regards,

David.

---

From: Vipin Jain <[email-masked]>
Date: Wed, 3 Jul 2002 19:58:02 -0700 (PDT)

comments inline..

> an LAC sends multiple PADO's, they should contain different AC-Name tags.
I agree, AC-Cookie needs to be a black-box thing. What I meant by distinguish
based on AC-Cookie is to allow it to identify that it is coming in from a
different host and that's all - not to make service selection based on AC
Cookie.

Consider following situation:
A client sends a PADI, two ACs respond with the same "Service Name" and happend
to choose same AC-Name (since there is no norm on how AC-Name be chosen).
Typically, MAC addresses used by them would be different except. But now with
the relay draft the MAC addresses would be same as well, then how would a host
distinguish two PADOs? Based on AC-Cookie? Not according to you. Which means we
have to do one of the following to deal with the situation:
- either leave the state of confusion to be dealt by client the best it can
- ensure that the LAC generates two different AC-Name tags for two PADOs with
same "Service Name" tags (coming from two different LACs). This would require
maintaining the state of what Service-Name tags were received earlier, etc. And
I guess Mark and Ron are inclined not to use any state, whatsoever, on the
intermediate nodes. Instead pack the state in AC-cookie or Host-Uniq tags.
- ensure that the LAC uses different MAC address for every such request; Given
that a LAC has pelnty of spare MAC addresses, it still must maintain the
mapping of MAC-address to AC-Cookie to be able to use the same MAC in PADS for
the given AC-Cookie (if pppoe client responds to the PADO). This would also
require maintaining some state at the LAC.

I am not particularly inclined to what is best among above three; Probably
first one is the most convinient and should be okay too - client should just
treat them as a retransmitted PADO (but then PADOs are not retransmitted as per
2516). It most likely won't behave strange in those situations, like sending
multiple PADS and tearing down the previous one considering it coming from the
same host.. In which case, IMHO, it might be wise to mention it in the relay
draft. 

thanks,
-- vipin

---

From: Vipin Jain <[email-masked]>
Date: Thu, 4 Jul 2002 09:13:19 -0700 (PDT)

Thanks for the insight, David.
> Actually, in the real world, this is not a problem.  Most clients do one of
> two things:
> 
> 1) Send a PADR to the AC which sent the first "acceptable" PADO and ignore
> all subsequent PADOs, or
By subsequent, you mean to include PADOs that are received after either PADS
was received or PADR was sent?

> I have another concern about the whole scheme, though: Using a
> reliable control channel for PADx packets may be a problem, because
> PPPoE clients typically have their own retransmit strategy (they
> assume they're operating over a LAN which can drop frames.)  As we've
> seen with schemes like PPP-over-SSH, piggybacking one protocol with a
> retransmit strategy over another protocol with its own retransmit
> strategy can lead to bad interaction and network congestion.
Could it be a possible DoS attack? May be its not a big problem because other
then L2TP re-xmit window for SRRQs and SRRPs, there would not be other
system state maintained.

thanks,
-- vipin

> 
> I don't think it's a big problem with PADx packets because the discovery
> stage is short, but it's something to keep in mind.
> 
> --
> David.
> 
>

---

From: "David F. Skoll" <[email-masked]>
Date: Thu, 4 Jul 2002 07:29:58 -0400 (EDT)

> different host and that's all - not to make service selection based on AC

But there's no guarantee that the AC-Cookie will be different in the
general case.  (For the L2TP relay case, there is.)

2) Collect all PADOs for a few seconds and then present a GUI to the
user for selection.  Seemingly-duplicate PADOs could confuse the user
or software, but if more than one AC is "acceptable", then it doesn't
matter much which is picked.

--
David.

---

From: "David F. Skoll" <[email-masked]>
Date: Thu, 4 Jul 2002 12:31:20 -0400 (EDT)

> was received or PADR was sent?

After the PADR was sent.

> > assume they're operating over a LAN which can drop frames.)

> Could it be a possible DoS attack?

Sure.  Flood the LAC with PADI's and you may be able to stress the L2TP
control channel, especially if you can command many machines connected to
the same LAC.  I don't know how high the risk is.  It depends on who gets
overloaded first -- the LAC or the LNS.  If the LAC gets overloaded and
starts ignoring PADI's, no problem.  If the LNS gets overloaded, big
problem -- your L2TP control channel will stall.

--
David.

---

From: "W. Mark Townsley" <[email-masked]>
Date: Thu, 11 Jul 2002 10:27:41 +0200

> strategy can lead to bad interaction and network congestion.

Theoretically, this is certainly a valid concern. If it becomes a serious
problem, couldn't the LAC/relay simply detect a retransmitted PADx packet and
not resend it over the reliable l2tp channel? Can you think of a reason this
would not work?

> stage is short, but it's something to keep in mind.

Right, we are really only talking about a few packets per host here.

---

From: "W. Mark Townsley" <[email-masked]>
Date: Thu, 11 Jul 2002 10:44:17 +0200

"David F. Skoll" wrote:
> the same LAC.  

One would expect to have similiar flood/DoS detection mechanisms at the PADI
processing level as you would need to deter overrun of the PPPoE process even
without relay over L2TP -- this would be particularly true if you are performing
some sort of off-box authorization for each PADI (such as for service
selection).

> I don't know how high the risk is.  It depends on who gets

If overloaded, the LNS can simply update Nr, drop the PAD message, and
periodically send ZLB acks to keep the control channel in sync. Since L2TP
doesn't *have* to respond to a relayed PAD message, the LNS burden can be
ratcheted down pretty low.

I'm actually more worried about PPPoE itself being able to handle message bursts
more than L2TP. I think we all have had to tweak our L2TP control channels to
handle mass message bursts for session flapping. A well-designed LNS shouldn't
be overly burdened by a spurt of relayed PAD messages. Again, I'd be more
worried about overloading PPPoE (which has to process, and potentially repond to
each PADx) than the L2TP relay mechanism itself.

---

From: "W. Mark Townsley" <[email-masked]>
Date: Thu, 11 Jul 2002 13:39:52 +0200

"David F. Skoll" wrote:
> 
> On Thu, 11 Jul 2002, W. Mark Townsley wrote:
> 
> Unfortunately, there's no way to distinguish between a retransmitted
> PADx and a request for another PPPoE session.  This is a shortcoming
> of PPPoE, because PADx packets don't have a unique identifier.

In practice, do you think one can try and discern this heuristically? I would
guess that this would be a good thing to know how to do to combat DOS attacks,
regardless of whether relay is being used or not.

> 
> Like I said, I think these problems are mostly theoretical and not a big
> deal in practice.

Agreed, but I still wouldn't mind working through all options just in case the
theoretical becomes real :-)

---

From: "David F. Skoll" <[email-masked]>
Date: Thu, 11 Jul 2002 07:24:25 -0400 (EDT)

Regards,

David.