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

"Christian Huitema" <huitema@huitema.net> Tue, 09 June 2015 22:33 UTC

Return-Path: <huitema@huitema.net>
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 3FDD81A6F2E for <secdir@ietfa.amsl.com>; Tue, 9 Jun 2015 15:33:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level:
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] 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 sD3x31rY49sd for <secdir@ietfa.amsl.com>; Tue, 9 Jun 2015 15:33:24 -0700 (PDT)
Received: from xsmtp04.mail2web.com (xsmtp04.mail2web.com [168.144.250.231]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D7C51A6F29 for <secdir@ietf.org>; Tue, 9 Jun 2015 15:33:24 -0700 (PDT)
Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1Z2S5C-0003f5-7H for secdir@ietf.org; Tue, 09 Jun 2015 18:33:23 -0400
Received: (qmail 10037 invoked from network); 9 Jun 2015 22:33:21 -0000
Received: from unknown (HELO huitema1) (Authenticated-user:_huitema@huitema.net@[131.107.147.223]) (envelope-sender <huitema@huitema.net>) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for <draft-ietf-pcp-anycast.all@tools.ietf.org>; 9 Jun 2015 22:33:21 -0000
From: Christian Huitema <huitema@huitema.net>
To: 'Yoav Nir' <ynir.ietf@gmail.com>
References: <06A85300-7DD9-4AC4-A5F5-EE9FE77F7466@gmail.com> <001801d0a2fb$ef31e560$cd95b020$@huitema.net> <C4E282B5-8A30-420D-BA7C-03CCB590D57E@gmail.com>
In-Reply-To: <C4E282B5-8A30-420D-BA7C-03CCB590D57E@gmail.com>
Date: Tue, 09 Jun 2015 15:33:19 -0700
Message-ID: <009001d0a304$4a518ec0$def4ac40$@huitema.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQM76S7OfzTHZVpZ8EJ9iD3mk4Q05gBUUmk8AhLhUUqauvprsA==
Content-Language: en-us
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/Bnyak3GEe2s9kwJefCBDtcQ3nEo>
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 22:33:25 -0000

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

But then, what is the point of mentioning TTL as a plausible mitigation if there is no practical way to use it? 

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

Except that currently deployed routers will not be updated for a long time. If they do support PCP, the router selection rule will discover them. But many don't. They will thus pass the unicast packets through, unmolested.

There are probably a bunch of heuristics that can be applied to reduce the leakage. But I don't see them in the draft.

-- Christian Huitema