Re: [pcp] fwd: I-D Action: draft-ietf-pcp-anycast-03.txt

Sebastian Kiesel <ietf-pcp@skiesel.de> Tue, 23 December 2014 00:08 UTC

Return-Path: <sebi@gw01.ehlo.wurstkaes.de>
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 589A21A6FE8 for <pcp@ietfa.amsl.com>; Mon, 22 Dec 2014 16:08:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.56
X-Spam-Level:
X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qrIC2DBnJrN for <pcp@ietfa.amsl.com>; Mon, 22 Dec 2014 16:08:06 -0800 (PST)
Received: from gw01.ehlo.wurstkaes.de (gw01.ehlo.wurstkaes.de [IPv6:2a02:a00:e000:116::41]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 981E61A1B8B for <pcp@ietf.org>; Mon, 22 Dec 2014 16:08:06 -0800 (PST)
Received: from sebi by gw01.ehlo.wurstkaes.de with local (Exim 4.80) (envelope-from <sebi@gw01.ehlo.wurstkaes.de>) id 1Y3D18-0006rF-6Y; Tue, 23 Dec 2014 01:08:02 +0100
Date: Tue, 23 Dec 2014 01:08:02 +0100
From: Sebastian Kiesel <ietf-pcp@skiesel.de>
To: Dave Thaler <dthaler@microsoft.com>
Message-ID: <20141223000802.GD6678@gw01.ehlo.wurstkaes.de>
References: <20141222170107.GC6678@gw01.ehlo.wurstkaes.de> <BY2PR03MB412E6CB3927B71832A91AB6A3560@BY2PR03MB412.namprd03.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <BY2PR03MB412E6CB3927B71832A91AB6A3560@BY2PR03MB412.namprd03.prod.outlook.com>
Accept-Languages: en, de
Organization: my personal mail account
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/mrUjbL3686LVMWp7cZA0Yj24AVU
Cc: "pcp@ietf.org" <pcp@ietf.org>
Subject: Re: [pcp] fwd: I-D Action: draft-ietf-pcp-anycast-03.txt
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Dec 2014 00:08:10 -0000

On Mon, Dec 22, 2014 at 09:00:59PM +0000, Dave Thaler wrote:
> Sebastian Kiesel writes: 
> > Section 2.1 (Client behavior) was reworded once again.  We decided to
> > explicitly write down in which order the addresses should be tried, and not to
> > simply reference RFC 6724 (as suggested in Honolulu); first because that RFC is
> > a rather long document and we need only a tiny bit and second, because RFC
> > 6724 is only for IPv6 and saying that the same rules should be applied
> > analogously to IPv4 seems awkward.
> 
> That is absolutely not true.  RFC 6724 applies to IPv4 as well, as its abstract
> clearly states.  RFC 6724, and RFC 3484 before it, have always applied to IPv4
> and have been implemented and used as such for over a decade now.

point taken, if I read it again after reading RFC 6540 first.

[...]
> Instead it should just say that the anycast addresses are to be
> treated as additional addresses at the end of the default router list
> mentioned in RFC 6887, and refer to server-selection.
> No text is then needed to "replace" the text in RFC 6887, as
> the text in RFC 6887 then becomes correct.

2.1.  PCP Discovery Client behavior

   The PCP anycast addresses (see Sections 4.1 and 4.2) are added after
   the default router list (for IPv4 and IPv6) to the list of PCP
   server(s) (see Section 8.1 of [RFC6887]).  This list is processed as
   specified in [I-D.ietf-pcp-server-selection].

   Note: If, in some specific scenario, it was desirable to use only the
   anycast address (and not the default router), this could be achieved
   by putting the anycast address into the configuration file, or DHCP
   option, etc.

2.2. ...



OK?  

I am not a native speaker. Please help with grammar if neccessary.

> 
> Section 1:
> > it cannot provide timely information which CGN to interact with.
> 
> s/which/on which/

fixed.

> Section 4.1 (and similarly in 4.2):
> > Typically used within a network operator's network domain, but in
> > principle globally routable.
> 
> It wouldn't be globally routable in practice today because of prefix
> length constraints in practice.

True. But I don't think we have a problem here.  RFC 5736 says:

   The IANA registry notes, as a general comment, that address prefixes
   listed in the IPv4 Special Purpose Address Registry are not
   guaranteed routability in any particular local or global context.

> So either remove that phrase or
> augment "in principle" with something like "(if a /32 route were
> allowed in the default-free zone)". 

In the context of Question 7 of RFC 5736, is "globally routable"
equivalent to "there is a route in the default-free zone"?

> My preference would be 
> to simply remove that phrase since section 5.1 already says
> "In the default-free zone, routers should be configured to drop such packets."

We need to answer Question 7 of RFC 5736 with routable only in scoped,
local, or private contexts, or globally.

The current approach is to say "globally" but relativize it. Are we sure
that we really want to restrict ourselves to one of the other options
(and can we define exactly what the appropriate scope is)?


> Section 5.1:	
> Since IPsec could in principle be used to secure communication
> with unicast PCP server addresses, it seems odd (though RFC 6887
> is just as odd in that sense) to not mention whether IPsec
> can work or not with the anycast server addresses and what the
> operational problems with trying it would be.  I believe that
> in theory it could work if the same keying material is used by
> all PCP servers with the same anycast address, but if
> there is a route change causing updates to go to a different PCP
> server, then the negotiated IPsec session state would not be
> present (I suspect IPsec would renegotiate and recover but
> someone more familiar with IPsec details should say).
> The other, perhaps bigger, operational problem is that the
> anycast address is the same in every network, but the PCP
> servers' keying information would be different in different
> networks, and so it may or may not be possible (again, I 
> would need an IPsec expert to say for sure) to configure clients
> with per-network IPsec security info.   Of course, this
> could all be avoided by using pcp-auth _instead of_ IPsec,
> but the doc should at least say so.  (It does at least mention
> pcp-auth which is good.)

These problems are not specific to the PCP use case of IP anycast.
I don't think we should try to find exhaustive answers within the
context of this document.


Thanks
Sebastian