From: Yoav Nir <ynir.ietf@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-Id: <06A85300-7DD9-4AC4-A5F5-EE9FE77F7466@gmail.com>
Date: Mon, 8 Jun 2015 18:00:38 +0300
To: secdir <secdir@ietf.org>, The IESG <iesg@ietf.org>,
 draft-ietf-pcp-anycast.all@tools.ietf.org
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/_-l5jzR8gcG_3D3FUvoE0A5bH80>
Subject: [secdir] SecDir Review of draft-ietf-pcp-anycast-06
Precedence: list

Hi.

I have reviewed this document as part of the security directorate's =
ongoing effort to review all IETF documents being processed by the IESG. =
 These comments were written primarily for the benefit of the security =
area directors.  Document editors and WG chairs should treat these =
comments just like any other last call comments.

TL;DR: Ready (with a question)

The document describes an alternative method for nodes behind a =
middlebox (such as NAT device or firewall) to contact the middlebox in =
order to manage port allocation. Existing methods (described in RFC 6887 =
and 7291 respectively) are to either assume that the default router is =
the device (suitable for small networks) or specify the middlebox =
address in a DHCP option (suitable for larger networks).

This document proposes a third alternative: use of a well-known anycast =
address. Sending a request to that anycast address will ensure delivery =
to the closest service address (which may or may not be co-located with =
the middlebox) by the routing on the network, supported by either BGP or =
IGP.

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. =
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.

The other specific concern is that a rogue machine would push routes to =
advertise itself as a PCP service, hijacking PCP traffic and causing =
network outages. Section 5.2 deals with this issue. The section makes =
the claim that within the first network segment, the nodes do not use =
dynamic routing protocols, so an attack there is equivalent to =
impersonating the default router. Outside the first segment, routing =
protocols are used, and there is a need for routing security anyway. In =
both cases an attacker capable of conducting these attacks can do a lot =
worse than impersonating a PCP service.

I find this argument almost convincing. What is still bothering me is =
the question of whether the more damaging attacks would be discovered =
immediately, whereas simply advertising a route to the anycast address =
can =E2=80=9Cfly under the radar=E2=80=9D so that the attacker can =
become the PCP server undetected. I don=E2=80=99t have a firm attack in =
mind, just a mild concern.

Yoav