Subject: [L2tpext] Re: Doubt in L2TP

From: "W. Mark Townsley" <[email-masked]>
Date: Wed, 27 Mar 2002 01:15:51 -0500

Copying the L2TP list.

Ananth R wrote:
> 
> Hello Mr.Townsley,
> I had a couple of questions in L2TP. I would be grateful if you
> could help me out.
> #1. What is the use of Initial received Conf Req AVP? After all,
> the PPP at the LNS side would only be interested in the finally
> negotiated parameters, wouldn't it? How would one use the Initial
> recd CONFREQ, if there is one?

Some implementations use it to glean what options the original client *tried* to
negotiate (and presumably the LAC did not allow). For example, if MLP was
attempted, the LNS may use this as input into whether or not it will try and
renegotiate with this option.

That said, it is not a very commonly used AVP, but the functionality is there
just in case.

> 
> #2. The L2TP RFC states that if a malformed AVP with the M-bit set
> is received, then the associated session/tunnel should be brought
> down. Consider the case where the Message type AVP in ICRQ is
> corrupt, and we are not able to figure out what message it is.
> Since there is no session associated with this message so far,
> what should be the action taken. We cannot bring down the tunnel
> as there might be other sessions which will unnecessarily be
> brought down. Should we just ignore such a message then?

If UDP checksums are present (recommended), it is very unlikely that the message
was corrupted in transit and allowed to get to L2TP processing. So, if you see a
truly malformed message type AVP you have a highly misbehaving client and should
probably shut down the tunnel just so you know to debug this. I have never seen
a malformed message type AVP (unknown message types, yes, but not malformed).

As for unknown message types, the RFC states that the message should be ignored
if the M bit is not set in the Message Type AVP, and the entire tunnel brought
down if the M bit is set. You should take this as a suggestion to never set the
M bit in a newly defined Message Type AVP unless it is truly necessary for the
operation of the entire tunnel.

> Another scenario is when the Msg Type AVP is OK, but the Asgn
> Session Id is corrupt. In this case, altho we know it is a session
> set-up message, we won't know to which session Id to send the CDN
> to. What do we do in this case?

Again, UDP checksums should protect you from corruption. However, if you still
don't have the proper Assigned Session ID AVP or Session ID in your control
message header, then there is surely no way to know what session the message was
intended for beyond clairvoyance. e.g. if you don't tell me who you are, I can't
be expected to just "know." 

> 
> I would really be grateful if you could take the time out to
> answer my questions.

Hope that helps.

- Mark

> Thanks & Regards,
> Ananth.

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