Re: [secdir] SecDir Review of draft-ietf-pcp-anycast-06

Yoav Nir <ynir.ietf@gmail.com> Tue, 09 June 2015 21:47 UTC

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:
> 
>> 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. 
> 
> 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.

Doesn’t 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’d 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’s high enough to take a packet to any network on the Internet.

Expecting the NAT device / firewall to filter sounds more plausible to me.