From: "Christian Huitema" <huitema@huitema.net>
To: "'Yoav Nir'" <ynir.ietf@gmail.com>, "'secdir'" <secdir@ietf.org>,
 "'The IESG'" <iesg@ietf.org>, <draft-ietf-pcp-anycast.all@tools.ietf.org>
References: <06A85300-7DD9-4AC4-A5F5-EE9FE77F7466@gmail.com>
In-Reply-To: <06A85300-7DD9-4AC4-A5F5-EE9FE77F7466@gmail.com>
Date: Tue, 9 Jun 2015 14:33:30 -0700
Message-ID: <001801d0a2fb$ef31e560$cd95b020$@huitema.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQM76S7OfzTHZVpZ8EJ9iD3mk4Q05prOIsqw
Content-Language: en-us
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/rq6z8yfpmqMVOkfSVGODOc9XIug>
Subject: Re: [secdir] SecDir Review of draft-ietf-pcp-anycast-06
Precedence: list

> There are two specific concerns about this method (other than the =
usual
> anycast or pcp concerns). The first is that information about the =
internal
> network might leak to a PCP service outside the network.=20

In fact, it is almost guaranteed to leak outside of the network. In the =
initial deployments, first hop routers will not be aware of the anycast =
address...

> ... Whereas a failure of
> a service whose address is given in DHCP will result in black-holed =
packets,
> failure of a service with an anycast address will cause the packets to =
be
> forwarded to some random PCP server on the Internet. Section 5.1 =
discusses
> this and recommends filtering in perimeter gateways and reduced TTL. I
> believe this addresses that threat adequately.

I would find the TTL mitigation would be more convincing if the draft =
actually specified a recommended TTL value.

-- Christian Huitema