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

From: Skip Booth <[email-masked]>
Date: Tue, 4 Sep 2001 13:36:13 -0400

Bernard Aboba writes:
> Propose changing 4.2.3 text to state:
> "MUST contain the IP address (ASCII encoded) the Responder desires to
> use for subsequent communications. The IP address is encoded in dotted
> decimal format for IPv4 or RFC 2373 [7] format for IPv6."
> 
> Have added a reference to RFC 2373, too. Similar text goes in section 4. 
> Also fixed spelling inconsistencies (still some uses of IPSEC instead of
> IPsec). 
> 
> Are there other instances where the draft is IPv4-centric? It should apply
> to IPv6 too.
> 
> On the floating port issue, if someone can propose text, I will insert it
> and resubmit.

I assume you are referring to the floating IP address issue since port
floating should be pretty clear at this point.

I believe Thomas's concern was whether the floating IP address requirements
where clearly spelled out.  I believe section 4.2.3, Responder chooses new
IP Address, adequately describes the requirements to support a floating IP
address.

-Skip

> 
> On Wed, 29 Aug 2001, Thomas Narten wrote:
> 
> > IETF last call has ended for this, and I gather there were no comments
> > or issues raised. So, I'd like to get the document before the IESG.
> > 
> > Some final cleanups:
> > 
> > Thomas Narten wrote:
> > > 
> > > "W. Mark Townsley" <[email-masked]> writes:
> > > 
> > > > Bernard Aboba wrote:
> > > > > >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.
> > > 
> > > > 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.
> > 
> > Question: where is it documented exactly what it means to support 
> > "floating the IP address"? I'm wondering whether the reference in this
> > document is clear enough to implementors in terms of what they are
> > supposed to implement. The wording at issue is:
> > 
> > > The responder is not required to support the ability to float it's IP
> > > address and port.  However, the initiator MUST allow the responder to
> > > float it's port and SHOULD allow the responder float it's IP address.
> > 
> > Skip Booth <[email-masked]> writes:
> > 
> > > Bernard Aboba writes:
> > > > On Tue, 17 Jul 2001, Skip Booth wrote:
> > > > 
> > > > > 
> > > > > W. Mark Townsley writes:
> > > > > > 
> > > > > > 
> > > > > > Bernard Aboba wrote:
> > > > > > > 
> > > > > > > > > If I understand Thomas correctly, he is saying that UTF-8 encoding IP
> > > > > > > > > addresses is basically silly; I agree completely.
> > > > > > > > >
> > > > > > > 
> > > > > > > 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.
> > > > > 
> > > > > 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
> > > > > 
> > > > 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?
> > 
> > > 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.
> > 
> > I think the above reference is to Section 4.2.3. That section
> > currently still refers to UTF-8 encoding (Section 4 does say use ascii
> > for the dotted decimal case).
> > 
> > Thomas
> >

---

From: Thomas Narten <[email-masked]>
Date: Tue, 04 Sep 2001 13:45:26 -0400

> where clearly spelled out.

Not just the requirements, but the actual mechanism itself.

> I believe section 4.2.3, Responder chooses new IP Address,
> adequately describes the requirements to support a floating IP
> address.

Ah, of course. I just did not make the connection between the text
mentioning "float it's (sic) IP address" and 4.2.3. Note that the
latter section doesn't even use the word "float".  [I was also
thinking about pre-RFC L2TP language that supported IP address
floating, and thought that was what might be meant.]

Putting in some sort of pointer to Section 4.2.3 in the paragraph that
talks about floating an addres would address the confusion.

I think with this issue closed, we just need a new ID and then the
document can go before the IESG.

Thomas

---

From: Skip Booth <[email-masked]>
Date: Tue, 4 Sep 2001 15:49:47 -0400

> talks about floating an addres would address the confusion.

Sounds reasonable.  Bernard, can you please make this change in the next
version?

> document can go before the IESG.

Great!

-Skip

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 4 Sep 2001 14:56:33 -0700 (PDT)

> Sounds reasonable.  Bernard, can you please make this change in the next
OK. Can someone provide the exact text that should be changed?

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 4 Sep 2001 15:07:28 -0700 (PDT)

> Bernard, can you make the changes? 

How about this language:

"The responder is not required to support the ability to float its IP
address and port.  However, the initiator MUST
allow the responder to float its port and SHOULD
allow the responder float its IP address. For
further details on the mechanism for this,
please consult section 4.2.3."

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 4 Sep 2001 15:25:12 -0700

> OK. Can someone provide the exact text that should be changed?

How about this?

Change the next to the last paragraph of section 4.2 from

to

The responder is not required to support the ability to float its IP
address and port.  However, the initiator MUST allow the responder to
float its port and SHOULD allow the responder to choose a new
IP address (see section 4.2.3, below).

I'm not sure that the forward reference is necessary now that the verbiage
is aligned, though...

---

From: Skip Booth <[email-masked]>
Date: Tue, 4 Sep 2001 20:41:29 -0400

Works for me.

-Skip

---

From: Thomas Narten <[email-masked]>
Date: Thu, 20 Sep 2001 15:43:37 -0400

The IESG discussed l2tpext-security today, and the one issue that
popped up related to the wording of the definitions:

> In this document, the key words "MAY", "MUST,  "MUST  NOT",  "optional",
> "recommended",  "SHOULD",  and  "SHOULD  NOT",  are to be interpreted as
> described in [2].

Not that "optional" and "recommended" (lower case) are not defined in
RFC 2119. Is the intention here to define the terms "RECOMMENDED" and
"OPTIONAL", which are defined in 2119?

Note that the document does use the word "optional" in a few places
where I think the intention is the normal english, not the 2119
definitions. I.e.:

> (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 IP address (ASCII encoded)
> that the Responder desires to use for subsequent communications. Only

and later

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

Also, the document says:

> Although the current L2TP specification allows the responder to use a
> new IP address when sending the SCCRP, this behavior is not recommended
> for implementations requiring protection of L2TP via IPsec.  To allow

Is the intent (i.e., would it be more clear) to say SHOULD NOT rather
than "not recommended" above? I.e., is the "recommended" wording
intended to have the 2119 meaning?

Thomas

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 20 Sep 2001 13:15:18 -0700

> "OPTIONAL", which are defined in 2119?

Yes.

> > for subsequent communications.  Only the ASCII encoded IP address should

Yes, you're right.

> intended to have the 2119 meaning?

Actually, I think that just capitalizing "not recommended" would do the
trick...