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

From: Thomas Narten <[email-masked]>
Date: Wed, 29 Aug 2001 13:08:24 -0400

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: Bernard Aboba <[email-masked]>
Date: Wed, 29 Aug 2001 10:55:14 -0700 (PDT)

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.