Subject: [L2tpext] some v3 issues/questions

From: Jonathan Lynam <[email-masked]>
Date: Wed, 08 Sep 2004 00:35:16 -0700

Here are some v3 points that I do not think are entirely clear.
I know it's late in the cycle and it's unlikely that the draft 
will change,
but I think these are worthy of some consideration and perhaps 
discussion.
It's certainly possible I've missed something. I'd appreciate 
any feedback.

- Section 7.2 - "challenge response" in wait-ctl-conn state.
   I believe this was a mistake since there is no challenge 
response AVP in v3.
   "Challenge response" could be here used to indicate the 
expected Message-Digest,
   but it's more likely just a copy and paste error.

   This paragraph should be worded something like:
     wait-ctl-conn
         Awaiting an SCCCN.  Upon receipt, the Message-Digest 
AVP contained
         in the message is checked. If it is correct, 
authentication is to
         be considered successful and the control connection is
         established. If the Message-Digest value is incorrect, 
or if no
         Message-Digest AVP is present in the SCCCN and a Nonce 
AVP was
         sent in the SCCRP, the SCCCN is to be considered 
unacceptable
         and the control channel is torn down.

     Or, since none of the other states talk about message 
authentication,
     it could be changed to simply read:

     wait-ctl-conn
         Awaiting an SCCCN
         (short and sweet)

- Section 4.7.3 - automatic L2TPv2 Fallback
     "If the peer implementation is L2TPv3-capable, a control 
message with
       Ver set to 3 and corresponding header and message format 
will be
       sent in response to the SCCRQ."

     I know that by "control message", an SCCRP is meant, but 
someone else
     might think that a new SCCRQ with Ver set to 3 should be sent.

     In general, automatic fallback seems a little sketchy. Can 
we state that
     detection should be done by sending an SCCRQ with 
Assigned-Control-Connection-ID,
     with M=0 (so that it is always the same AVP)? That way, for 
conformance
     tests we can more easily still expect correct M-bit for all 
other AVPs.
     A new forwards-compatible protocol-version AVP would be 
even cleaner.

- clearer restrictions/permissions on "floating" the source IP 
address,
   meaning, using a different source address than the one used for
   this LCCE's address (source or dest) in the original SCCRQ.
   E.g.:
    SCCRQ dst=A src=B
    SCCRP dst=B src!=A

   The wording in RFC2661 was not clear enough on this point. It 
seems best
   to either allow/disallow it explicitly, or state that it is 
an implementation
   choice, with all due caveats.
   It's *almost* discussed in 4.1.2.2. I suggest that if it is 
addressed,
   it should be hoisted into a section applicable to L2TPv3 over IP
   as well as L2TPv3 over UDP.
   I think most people believe that only the source port can be 
floated, and
   only in the SCCRP message (this is what I like to believe 
also). I could live with
   allowing the source address to be floated but it changes a 
few assumptions.
   Either way I'd prefer it to be clearly defined.
   Of course, my comments apply to tunnels with a control 
connection, not data-only
   operation (e.g. l2 VPNs auto-configured via BGP).

Thanks,

Jonathan

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

---

From: "W. Mark Townsley" <[email-masked]>
Date: Wed, 08 Sep 2004 05:17:30 -0400

Jonathan Lynam wrote:

> I know it's late in the cycle and it's unlikely that the draft will change,
> but I think these are worthy of some consideration and perhaps discussion.
> It's certainly possible I've missed something. I'd appreciate any feedback.
> 
>   I believe this was a mistake since there is no challenge response AVP 
> in v3.
>   "Challenge response" could be here used to indicate the expected 
> Message-Digest,

Yes, copy and paste error. Editorial items such as these can be fixed in the 
final 48 hours before the RFC is posted.

>         Awaiting an SCCCN.  Upon receipt, the Message-Digest AVP contained
>         in the message is checked. If it is correct, authentication is to
>         established. If the Message-Digest value is incorrect, or if no
>         Message-Digest AVP is present in the SCCCN and a Nonce AVP was
>         sent in the SCCRP, the SCCCN is to be considered unacceptable
>     Or, since none of the other states talk about message authentication,

I'm tempted to just keep it short and sweet.

>     "If the peer implementation is L2TPv3-capable, a control message with
>       Ver set to 3 and corresponding header and message format will be
>     I know that by "control message", an SCCRP is meant, but someone else

Well, any control message would do here. Even a StopCCN with ver 3, in case you 
were rejecting the call with a v3 stack. Or, technically, an explicit ack 
message as well.

> 
>     In general, automatic fallback seems a little sketchy. Can we state 
> that
>     with M=0 (so that it is always the same AVP)? That way, for conformance
>     tests we can more easily still expect correct M-bit for all other AVPs.
>     A new forwards-compatible protocol-version AVP would be even cleaner.

I don't see the advantage of the Assigned-Control-Connection-ID always setting M 
to zero.

Currently, you can send an SCCRQ populated with both v2 and v3 AVPs, and 
continue in v2 or v3 mode based on the response received. It *should* work with 
an existing v2 implementation if M=0 for all v3 AVPs as they will be ignored as 
unknown. However, if you are v3-only, you can send with M=1 so that even a v2 
peer will reject the SCCRQ because it contains an unknown AVP with the M bit set.

One problem with the protocol version AVP is that we didn't really nail down 
what to do with it if there was a mismatch back in v2. I suspect there are some 
v2 implementations that simply report the version number and then go on their 
merry way through the control message.

> 
> - clearer restrictions/permissions on "floating" the source IP address,
>   The wording in RFC2661 was not clear enough on this point. It seems best
>   to either allow/disallow it explicitly, or state that it is an 
> implementation
>   It's *almost* discussed in 4.1.2.2. I suggest that if it is addressed,
>   I think most people believe that only the source port can be floated, and
>   only in the SCCRP message (this is what I like to believe also). I 
> could live with
>   allowing the source address to be floated but it changes a few 
> assumptions.
>   Of course, my comments apply to tunnels with a control connection, not 
> data-only

Early in v2, we allowed all manner of floating to support multihomed boxes. This 
was deemed a security concern by the IESG, and it was strongly recommended to us 
that we limit floating after the control connection is established.

The proper way to float an IP address is explicitly by restarting the control 
connection with the "try another directed" Error Code.

I agree that we could be more explicit in the document on this. I suppose 
nailing down the IP address at the very start (i.e., no floating at all) would 
be the most conservative approach. Given that we have an explicit mechanism 
defined if the address must be floated, we could point that out in section 4.1.1 
and say it is the only valid way to change the IP address.

Thanks for the review,

- Mark