Re: [v6ops] Fwd: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians?

"Fred Baker (fred)" <fred@cisco.com> Wed, 11 July 2012 18:55 UTC

Return-Path: <fred@cisco.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D33521F8672 for <v6ops@ietfa.amsl.com>; Wed, 11 Jul 2012 11:55:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.14
X-Spam-Level:
X-Spam-Status: No, score=-110.14 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCcE7MGioy8s for <v6ops@ietfa.amsl.com>; Wed, 11 Jul 2012 11:55:52 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 22D0A21F8666 for <v6ops@ietf.org>; Wed, 11 Jul 2012 11:55:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=8699; q=dns/txt; s=iport; t=1342032983; x=1343242583; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=zXddxmtkrigrMe3GXbzZj9TL3+sgv/RDQ2BvwpxD6YE=; b=hA1tEfpPzSm1cQP/1b29gCyZY0yINWqBqssR0FmfHYsBSAviMVTqd6ov 8A/6aZfQTqCjL858cbqWgBVM0RcHMXR3M7d6A1OWCWHct4/whzbD+HwsR h4O5A7eyNln2e89R5sbF1+HQCRxEUl+r/NIxOPIzdWozAQYw2CGuc5hBq E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhIFANrL/U+tJV2c/2dsb2JhbABFtUaCKIEHgiABAQEDARIBJzcNCwIBCDYQMiUCBDWHZQYLnSugJItAhQ5gA5U6gRKNDoFmgl+BWCM
X-IronPort-AV: E=Sophos;i="4.77,569,1336348800"; d="scan'208";a="100923479"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 11 Jul 2012 18:56:23 +0000
Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q6BIuMqT026819 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <v6ops@ietf.org>; Wed, 11 Jul 2012 18:56:23 GMT
Received: from xmb-rcd-x09.cisco.com ([169.254.9.118]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0298.004; Wed, 11 Jul 2012 13:56:22 -0500
From: "Fred Baker (fred)" <fred@cisco.com>
To: IPv6 Ops WG <v6ops@ietf.org>
Thread-Topic: [v6ops] Fwd: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians?
Thread-Index: AQHNX5bd4uPwF1EKkEetTmMMXftV8A==
Date: Wed, 11 Jul 2012 18:55:53 +0000
Message-ID: <2CFB6DD5-7BD4-4044-AB71-16DF0C28734F@cisco.com>
References: <4FFDACB2.9080106@switch.ch> <DDC4B1FE-68C7-4D3A-AB27-7F307C9F57BE@cisco.com> <CAJfR-+P+H8ufUcro-0ea0wPE-VU9mopumMZkxeK-tLFPaQ0HUw@mail.gmail.com>
In-Reply-To: <CAJfR-+P+H8ufUcro-0ea0wPE-VU9mopumMZkxeK-tLFPaQ0HUw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.21.75.177]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19034.001
x-tm-as-result: No--40.602100-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7C17D27F35CE1F49AD4488D3402E4E2A@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [v6ops] Fwd: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Jul 2012 18:55:53 -0000

On Jul 11, 2012, at 10:57 AM, Turchanyi Geza wrote:

> There were several people, including me, that openly argued against some new RIPE policies that neglect the consecquences at the routing level, however, there is a noisy minority acting at the RIPE policy working group, overlooking reasonable arguments.

There have been calls in the past for the IETF to make recommendations to the RIRs on such policy. One of the proposals, if memory serves, was to recommend that service providers filter prefixes longer than /48, and another was that they filter prefixes longer than were allocated by the RIR in question or the IANA. The general comment was to shout the suggestion down: "that's for the RIR communities to comment on, not the IETF".

If I understand the dialog here (and no, I'm not involved in RIPE Policy), it sounds like there might be value in comments on the architectural implications of policy decisions on routing.

If I were to make a filtering proposal, I might look at the RPKI work. I could imagine an RPKI database maintained by an RIR having a key for each allocated prefix and each aggregated prefix (e.g., I could imagine Europe and the Americas routing to "APNIC prefixes" as an aggregated class, and only to more specifics within or close to the Asia Pacific region), and a recommendation from v6ops to the effect that an ISP should filter to prefixes that are in the RPKI database (and attested to by it) barring specific business requirements; deaggregation by a business partner acceptable to a given network might be an example of a business requirement, as would acceptance of the announcement of a specific ULA. I could also imagine the RIR offering a service to a network that wants to deaggregate, that would allow it to file signed keys for the more specific prefixes it wants to announce.

I could also imagine the operators in the room saying "that's why we don't want advice from the IETF" :-)

Question for the accumulated folks "in the room": Is the architectural implications of routing and filtering policy an appropriate topic to invite a draft concerning? If so, who might constitute an appropriate design team?

Documents relevant to RPKI:

https://tools.ietf.org/html/rfc6382
6382 Unique Origin Autonomous System Numbers (ASNs) per Node for
     Globally Anycasted Services. D. McPherson, R. Donnelly, F. Scalzo.
     October 2011. (Format: TXT=25224 bytes) (Also BCP0169) (Status: BEST
     CURRENT PRACTICE)

https://tools.ietf.org/html/rfc6472
6472 Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP. W.
     Kumari, K. Sriram. December 2011. (Format: TXT=10673 bytes) (Also
     BCP0172) (Status: BEST CURRENT PRACTICE)

https://tools.ietf.org/html/rfc6480
6480 An Infrastructure to Support Secure Internet Routing. M.
     Lepinski, S. Kent. February 2012. (Format: TXT=62127 bytes) (Status:
     INFORMATIONAL)

https://tools.ietf.org/html/rfc6481
6481 A Profile for Resource Certificate Repository Structure. G.
     Huston, R. Loomans, G. Michaelson. February 2012. (Format: TXT=36117
     bytes) (Status: PROPOSED STANDARD)

https://tools.ietf.org/html/rfc6482
6482 A Profile for Route Origin Authorizations (ROAs). M. Lepinski, S.
     Kent, D. Kong. February 2012. (Format: TXT=15745 bytes) (Status:
     PROPOSED STANDARD)

https://tools.ietf.org/html/rfc6483
6483 Validation of Route Origination Using the Resource Certificate
     Public Key Infrastructure (PKI) and Route Origin Authorizations
     (ROAs). G. Huston, G. Michaelson. February 2012. (Format: TXT=19811
     bytes) (Status: INFORMATIONAL)

https://tools.ietf.org/html/rfc6484
6484 Certificate Policy (CP) for the Resource Public Key
     Infrastructure (RPKI). S. Kent, D. Kong, K. Seo, R. Watro. February
     2012. (Format: TXT=77855 bytes) (Also BCP0173) (Status: BEST CURRENT
     PRACTICE)

https://tools.ietf.org/html/rfc6485
6485 The Profile for Algorithms and Key Sizes for Use in the Resource
     Public Key Infrastructure (RPKI). G. Huston. February 2012. (Format:
     TXT=11377 bytes) (Status: PROPOSED STANDARD)

https://tools.ietf.org/html/rfc6486
6486 Manifests for the Resource Public Key Infrastructure (RPKI). R.
     Austein, G. Huston, S. Kent, M. Lepinski. February 2012. (Format:
     TXT=42913 bytes) (Status: PROPOSED STANDARD)

https://tools.ietf.org/html/rfc6487
6487 A Profile for X.509 PKIX Resource Certificates. G. Huston, G.
     Michaelson, R. Loomans. February 2012. (Format: TXT=69150 bytes)
     (Status: PROPOSED STANDARD)

https://tools.ietf.org/html/rfc6488
6488 Signed Object Template for the Resource Public Key Infrastructure
     (RPKI). M. Lepinski, A. Chi, S. Kent. February 2012. (Format:
     TXT=25130 bytes) (Status: PROPOSED STANDARD)

https://tools.ietf.org/html/rfc6489
6489 Certification Authority (CA) Key Rollover in the Resource Public
     Key Infrastructure (RPKI). G. Huston, G. Michaelson, S. Kent.
     February 2012. (Format: TXT=23060 bytes) (Also BCP0174) (Status: BEST
     CURRENT PRACTICE)

https://tools.ietf.org/html/rfc6490
6490 Resource Public Key Infrastructure (RPKI) Trust Anchor Locator.
     G. Huston, S. Weiler, G. Michaelson, S. Kent. February 2012. (Format:
     TXT=15004 bytes) (Status: PROPOSED STANDARD)

https://tools.ietf.org/html/rfc6491
6491 Resource Public Key Infrastructure (RPKI) Objects Issued by IANA.
     T. Manderson, L. Vegoda, S. Kent. February 2012. (Format: TXT=23662
     bytes) (Status: PROPOSED STANDARD)

https://tools.ietf.org/html/rfc6492
6492 A Protocol for Provisioning Resource Certificates. G. Huston, R.
     Loomans, B. Ellacott, R. Austein. February 2012. (Format: TXT=65896
     bytes) (Status: PROPOSED STANDARD)

https://tools.ietf.org/html/rfc6493
6493 The Resource Public Key Infrastructure (RPKI) Ghostbusters
     Record. R. Bush. February 2012. (Format: TXT=15491 bytes) (Status:
     PROPOSED STANDARD)

https://tools.ietf.org/html/rfc6494
6494 Certificate Profile and Certificate Management for SEcure
     Neighbor Discovery (SEND). R. Gagliano, S. Krishnan, A. Kukec.
     February 2012. (Format: TXT=26425 bytes) (Updates RFC3971) (Status:
     PROPOSED STANDARD)


http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-ltamgmt
http://tools.ietf.org/html/draft-ietf-sidr-rpki-ltamgmt
  "Local Trust Anchor Management for the Resource Public Key
  Infrastructure", Stephen Kent, Mark Reynolds, 9-Jul-12

http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr
http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr
  "The RPKI/Router Protocol", Randy Bush, Rob Austein, 2-Feb-12

  "Definitions of Managed Objects for the RPKI-Router Protocol", Randy
  Bush, Bert Wijnen, Keyur Patel, Michael Baer, 26-Mar-12

  "RPKI Router Implementation Report", Randy Bush, Rob Austein, Keyur
  Patel, Hannes Gredler, Matthias Waehlisch, 27-Mar-12

http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr
http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr
  "The RPKI/Router Protocol", Randy Bush, Rob Austein, 2-Feb-12

  "Definitions of Managed Objects for the RPKI-Router Protocol", Randy
  Bush, Bert Wijnen, Keyur Patel, Michael Baer, 26-Mar-12

  "RPKI Router Implementation Report", Randy Bush, Rob Austein, Keyur
  Patel, Hannes Gredler, Matthias Waehlisch, 27-Mar-12

http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr-impl
http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-impl
  "RPKI Router Implementation Report", Randy Bush, Rob Austein, Keyur
  Patel, Hannes Gredler, Matthias Waehlisch, 27-Mar-12

http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr-impl
http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-impl
  "RPKI Router Implementation Report", Randy Bush, Rob Austein, Keyur
  Patel, Hannes Gredler, Matthias Waehlisch, 27-Mar-12

http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr-protocol-mib
http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-protocol-mib
  "Definitions of Managed Objects for the RPKI-Router Protocol", Randy
  Bush, Bert Wijnen, Keyur Patel, Michael Baer, 26-Mar-12

http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr-protocol-mib
http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-protocol-mib
  "Definitions of Managed Objects for the RPKI-Router Protocol", Randy
  Bush, Bert Wijnen, Keyur Patel, Michael Baer, 26-Mar-12

http://datatracker.ietf.org/doc/draft-ymbk-rpki-grandparenting
http://tools.ietf.org/html/draft-ymbk-rpki-grandparenting
  "Responsible Grandparenting in the RPKI", Randy Bush, 29-Jun-12