Return-Path: <ynir.ietf@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1])
 by ietfa.amsl.com (Postfix) with ESMTP id BFBC41A6ED9;
 Tue,  9 Jun 2015 14:47:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 
 DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,
 FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 2T9CMa8vhFjP; Tue,  9 Jun 2015 14:47:29 -0700 (PDT)
Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com
 [IPv6:2a00:1450:400c:c00::235])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by ietfa.amsl.com (Postfix) with ESMTPS id 1F4471A1F00;
 Tue,  9 Jun 2015 14:47:29 -0700 (PDT)
Received: by wgme6 with SMTP id e6so22048012wgm.2;
 Tue, 09 Jun 2015 14:47:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 
 h=content-type:mime-version:subject:from:in-reply-to:date:cc
 :content-transfer-encoding:message-id:references:to;
 bh=XqipQ0+D/cRmbRsMzoq+HNvV1PjBSZPGMUdP6UQFI8M=;
 b=OH6RvIbG74Mgbz05GotprAa53VC6YD5i1DQM/TvcHAuTZ3hxne1xcr5vt6NprggnRC
 RLYeQreEhhKkbZHxXSrfBMi6s9ftNLZ/F0+uS6xkB4ZaW3YqCbFqnJ2UoHY08jqRovat
 llaldpiVHIimvYbZ7tZ3obiNFcXFmAhOb0Fgwx0XYtyfdlCl8yv7pK3z9RkSh1bnb/Y/
 2eZU5vE7dFdbnzY14XGpMreAd7K3fjvFOmNW2aL7UFUS6/oQaOn4SuUA2t/Ta9RRl4XP
 3sU02T4ZtnXLxBW8WnaLp7qRigxnpYdXHYzfwOFykb6PaRe2qBtCWXSU+Lb1ESwbRqe6
 Ptpg==
X-Received: by 10.194.60.50 with SMTP id e18mr44739022wjr.109.1433886447909;
 Tue, 09 Jun 2015 14:47:27 -0700 (PDT)
Received: from [192.168.1.17] ([46.120.13.132])
 by mx.google.com with ESMTPSA id l6sm4769573wib.18.2015.06.09.14.47.25
 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
 Tue, 09 Jun 2015 14:47:27 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <001801d0a2fb$ef31e560$cd95b020$@huitema.net>
Date: Wed, 10 Jun 2015 00:47:23 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <C4E282B5-8A30-420D-BA7C-03CCB590D57E@gmail.com>
References: <06A85300-7DD9-4AC4-A5F5-EE9FE77F7466@gmail.com>
 <001801d0a2fb$ef31e560$cd95b020$@huitema.net>
To: Christian Huitema <huitema@huitema.net>
X-Mailer: Apple Mail (2.2098)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/5j6SwedZJBEnk3Z0eSgESp3IZwo>
Cc: draft-ietf-pcp-anycast.all@tools.ietf.org, The IESG <iesg@ietf.org>,
 secdir <secdir@ietf.org>
Subject: Re: [secdir] SecDir Review of draft-ietf-pcp-anycast-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>,
 <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>,
 <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jun 2015 21:47:30 -0000


> On Jun 10, 2015, at 12:33 AM, Christian Huitema <huitema@huitema.net> =
wrote:
>=20
>> 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
>=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...
>=20
>> ... 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.
>=20
> I would find the TTL mitigation would be more convincing if the draft =
actually specified a recommended TTL value.

Doesn=E2=80=99t that depend on the depth (diameter?) of the network?  =
The TTL should be high enough to reach the legitimate service but no =
higher. It does seem like a very fiddly thing. You=E2=80=99d need to =
re-adjust the TTL sent by all clients if you rearranged your servers a =
bit. I can see operators not taking the risk and just using the OS =
default TTL that=E2=80=99s high enough to take a packet to any network =
on the Internet.

Expecting the NAT device / firewall to filter sounds more plausible to =
me.


