Subject: Re: draft-ietf-l2tpext-security--02

From: Bernard Aboba <[email-masked]>
Date: Fri, 13 Jul 2001 23:08:06 -0700 (PDT)

>It is not clear what "all mandated cipher suites" is. Can you list
>them, since they are a MUST?

We didn't want to list them, since they can and will change. For example,
DES may be deprecated in favor of 3DES. Since L2TP runs over IPSEC, it
inherits the same mandatory ciphersuites as IPSEC. If we list them, then
we create the danger of the specs getting out of sync.

>Also, I wonder if the "SHOULD protect confidentiality" should be a
>MUST. The IESG may have more to say about this. If its just a SHOULD,
>and a customer only controls one of the implementations, you may not
>get interoperability... And when it comes to security, you want the
>customer to be be able to enable it and have it work...

If both sides support ESP, then the side that wants confidentiality can
negotiate it, and there is no interoperability problem. So again, I think
we want to ride on top of IPSEC requirements, not create our own
(potentially contradictory) ones.  

>What does "this section" refer to? i.e., just what is not part of the
>specification?

Good catch. It only meant to refer to three sections but other
normative sections were added later. I'll put the non-normative
sections in an Appendix to clarify this. 

>My quick glance of 2661 doesn't find a mention of floating the IP
>address. Is it allowed there? 

I also don't see mention of it -- but it isn't explicitly prohibited
either. Are you saying that it should be? It seems like it might be useful
in clustering/load balancing situations. 

>For RFCs > 10 pages, its nice to have TOC; can you easily add one?

Done. 

>stray nroff commands?

Yup. Fixed this. 

>IPSEC vs. IPsec? (I think the preferred spelling is IPsec... change
>throughout...)

Fixed.

>null reference??

Fixed.

> Stray > in front of From (thanks to sendmail??)

Not due to sendmail... will investigate. 

> s/which/to which/ ??

Got it.

---

From: "W. Mark Townsley" <[email-masked]>
Date: Sat, 14 Jul 2001 11:49:05 -0400

> in clustering/load balancing situations.

It is built into l2tp-security, and l2tpbis, and now l2tp-base, as a "try
another directed" result code for just the reasons you mention here (and some
others as well).

---

From: Thomas Narten <[email-masked]>
Date: Sun, 15 Jul 2001 17:24:22 -0400

> we create the danger of the specs getting out of sync.

This makes sense, but I didn't understand that to be the intent from
the wording the first time I read it.

> (potentially contradictory) ones.

What the current wording seems to suggest is that one MUST implement
IPsec ESP for the control channel, but it is only a SHOULD for the
data channel. This latter SHOULD is what triggered the above
comment. However, thinking about it, it doesn't seem to make a lot of
sense to me. If you have to implement it for the control channel,
implementing for the data channel would presumably be trivial. Whether
someone chooses to enable it is another manner. So just make it a
MUST. I.e., how does it help an implementation to not bother
implementing IPsec for the data channel?

How about changing the  paragraph:

>   To meet above requirements, all L2TP security compliant
>   implementations MUST implement IPSEC ESP for securing L2TP control
>   packets and SHOULD implement IPSEC ESP for protection of L2TP data
>   packets.  All mandated cipher suites, including NULL encryption, of
>   IPSEC ESP MUST be supported. Note that if confidentiality is not
>   required (e.g., L2TP data traffic), ESP with NULL encryption may be
>   used.  The implementations MUST implement replay protection
>   mechanisms of IPSEC.

to something like:

   To meet above requirements, all L2TP security compliant
   implementations MUST implement IPSEC ESP for securing both L2TP
   control and data packets.  All the IPsec-mandated cipher suites
   [RFC 2406, RFC 2402], including NULL encryption MUST be
   supported. Note that although an implementation MUST support all
   IPsec cyphersuites, it is an operator choice which ones will be
   used.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Sun, 15 Jul 2001 17:24:44 -0400

> It is built into l2tp-security, and l2tpbis, and now l2tp-base, as a
> "try another directed" result code for just the reasons you mention
> here (and some others as well).

If this is what implementations are doing and the direction that
current specs are going in, I'm fine leaving it in.

However, I am interested in hearing folks reaction to the following:

Thomas Narten <[email-masked]> writes:

> > (General Error) and the Error Code SHOULD be set to 7 (Try Another).  If
> > the Error Code is set to 7, then the optional error message MUST be
> > present and the contents MUST contain the dotted decimal IP address
> > (UTF-8 encoded) that the Responder desires to use for subsequent
> > communications and the initiator MUST parse the result and error code
> > information and send a new SCCRQ to the new IP address contained in the
> > error message.  This approach reduces complexity since now the initiator
> > always knows precisely the IP address of its peer.  This also allows a
> > controlled mechanism for L2TP to tie IPSEC filters and policy to the
> > same peer.

> This seems like a bad way to go. My understanding is that the error
> message string is intended for human consumption, hence UTF-8. But
> above you are really using it to extend the protocol. Seems like it
> would be better to do this properly, i.e, by defining a new AVP or
> something (and perhaps putting this in the base L2TP spec?).

An important consideration (as I understand it) is that UTF-8 is a
character encoding scheme, but not a langauge. Thus, if someone puts a
dotted IP address into UTF-8, you are also assuming that a particular
language is being used. Presumably english.

Is the above redirector stuff already implemented and deployed as
described?

Thomas

---

From: "W. Mark Townsley" <[email-masked]>
Date: Sun, 15 Jul 2001 20:26:10 -0400

> language is being used. Presumably english.

The field is for english, thus it likely would be displayed via a log message of
some sort as part of the general parsing of the redult code. However, the
instruction here is that it MAY also be used to as a method for determining a
destination for redirection.

> Is the above redirector stuff already implemented and deployed as

I believe so. It's not so uncommon for text based instruction in this area when
you consider, for better or worse, many commands are received from RADIUS these
days via text commands within attribute value pairs.

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 15 Jul 2001 23:34:01 -0700

> language is being used. Presumably english.

If I understand Thomas correctly, he is saying that UTF-8 encoding IP
addresses is basically silly; I agree completely.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 16 Jul 2001 00:12:30 -0700 (PDT)

>    IPsec cyphersuites, it is an operator choice which ones will be

OK with me.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 16 Jul 2001 00:16:14 -0700 (PDT)

> addresses is basically silly; I agree completely.

Yup. I wish I had a dime for every recent RFC that suggests encoding of IP
addresses or routes in UTF-8.

---

From: "W. Mark Townsley" <[email-masked]>
Date: Mon, 16 Jul 2001 05:38:48 -0400

> addresses or routes in UTF-8.

And if I had a nickel for every feature in any implementation that did something
along these lines, I would still be ahead...

- Mark

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 17 Jul 2001 08:37:12 -0700 (PDT)

> > addresses is basically silly; I agree completely.

do we have recommended text to fix this?

---

From: "W. Mark Townsley" <[email-masked]>
Date: Tue, 17 Jul 2001 12:41:01 -0400

> do we have recommended text to fix this?

I think we would probably want to create a new AVP if we wanted to encode the IP
address in a more native form. Might want to get a sense of the state of
implementations here before we yank this out from under them. It has been in
draft form unchanged for a rather long time.

- Mark

---

From: Skip Booth <[email-masked]>
Date: Tue, 17 Jul 2001 12:55:06 -0400

> draft form unchanged for a rather long time.

Well we (cisco) are using this for a couple of features, so I think there's
interest in keeping this as is.  I don't think any of these features are in
production releases yet, so there is a small window of time where we could
change this.  If we where to change this, then I would definitely suggest a
new AVP.  The optional message text of the Result and Error code AVP is
supposed to be human readable if I recall correctly, so I think it's
appropriate that it be UTF-8 encoded.

-Skip

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 18 Jul 2001 09:01:12 -0700 (PDT)

> appropriate that it be UTF-8 encoded.
I can understand wanting to encode a human readable message in UTF-8. But
encoding an IP address that way? Perhaps we can clarify what parts are
UTF-8 and what is plan ASCII?

---

From: Skip Booth <[email-masked]>
Date: Wed, 18 Jul 2001 14:49:08 -0400

> UTF-8 and what is plan ASCII?

I think you are right.  This should just be defined as ASCII since I don't
even know what it means to have an IP address in another UTF-8 encoded
form.  My understanding is that ASCII is a subset of UTF-8 and thus the
original wording was technically correct but just not completely clear.
How about the following text:

In section 8.2.3:

The optional error message MUST be present and the contents MUST contain
the dotted decimal IP address (ASCII encoded) the Responder desires to use
for subsequent communications.  Only the ASCII encoded IP address should be
present in the error message.

-Skip