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
- [v6ops] Fwd: RIPE-555 fundamentaly changes the wa… Fred Baker (fred)
- Re: [v6ops] Fwd: RIPE-555 fundamentaly changes th… Mikael Abrahamsson
- Re: [v6ops] Fwd: RIPE-555 fundamentaly changes th… Turchanyi Geza
- Re: [v6ops] Fwd: RIPE-555 fundamentaly changes th… Gert Doering
- Re: [v6ops] Fwd: RIPE-555 fundamentaly changes th… Brian E Carpenter
- Re: [v6ops] Fwd: RIPE-555 fundamentaly changes th… Fred Baker (fred)
- Re: [v6ops] Fwd: RIPE-555 fundamentaly changes th… David Farmer
- Re: [v6ops] Fwd: RIPE-555 fundamentaly changes th… Gert Doering
- Re: [v6ops] Fwd: RIPE-555 fundamentaly changes th… Gert Doering
- Re: [v6ops] Fwd: RIPE-555 fundamentaly changes th… Nick Hilliard
- Re: [v6ops] Fwd: RIPE-555 fundamentaly changes th… Nick Hilliard
- Re: [v6ops] Fwd: RIPE-555 fundamentaly changes th… David Farmer
- Re: [v6ops] Fwd: RIPE-555 fundamentaly changes th… Randy Bush
- Re: [v6ops] Fwd: RIPE-555 fundamentaly changes th… Turchanyi Geza
- Re: [v6ops] Fwd: RIPE-555 fundamentaly changes th… Gert Doering
- Re: [v6ops] Fwd: RIPE-555 fundamentaly changes th… Brian E Carpenter
- Re: [v6ops] Fwd: RIPE-555 fundamentaly changes th… Randy Bush
- Re: [v6ops] Fwd: RIPE-555 fundamentaly changes th… Gert Doering
- Re: [v6ops] Fwd: RIPE-555 fundamentaly changes th… Nick Hilliard
- Re: [v6ops] Fwd: RIPE-555 fundamentaly changes th… Turchanyi Geza
- Re: [v6ops] Fwd: RIPE-555 fundamentaly changes th… Gert Doering
- Re: [v6ops] Fwd: RIPE-555 fundamentaly changes th… Nick Hilliard
- Re: [v6ops] Fwd: RIPE-555 fundamentaly changes th… Brian E Carpenter
- Re: [v6ops] Fwd: RIPE-555 fundamentaly changes th… Brian E Carpenter
- Re: [v6ops] Fwd: RIPE-555 fundamentaly changes th… Randy Bush
- Re: [v6ops] Fwd: RIPE-555 fundamentaly changes th… STARK, BARBARA H
- Re: [v6ops] Fwd: RIPE-555 fundamentaly changes th… Nick Hilliard
- Re: [v6ops] Fwd: RIPE-555 fundamentaly changes th… Sascha Lenz
- Re: [v6ops] Fwd: RIPE-555 fundamentaly changes th… Gert Doering
- Re: [v6ops] Fwd: RIPE-555 fundamentaly changes th… Sascha Lenz
- Re: [v6ops] Fwd: RIPE-555 fundamentaly changes th… Havard Eidnes
- Re: [v6ops] Fwd: RIPE-555 fundamentaly changes th… Gert Doering
- Re: [v6ops] Fwd: RIPE-555 fundamentaly changes th… STARK, BARBARA H
- Re: [v6ops] Fwd: RIPE-555 fundamentaly changes th… Dmitry Burkov
- [v6ops] What can v6ops do? [was: RIPE-555 fundame… Brian E Carpenter
- Re: [v6ops] Fwd: RIPE-555 fundamentaly changes th… Dmitry Burkov
- Re: [v6ops] What can v6ops do? [was: RIPE-555 fun… Gert Doering
- Re: [v6ops] What can v6ops do? [was: RIPE-555 fun… Tim Chown
- Re: [v6ops] What can v6ops do? [was: RIPE-555 fun… Randy Bush
- Re: [v6ops] What can v6ops do? [was: RIPE-555 fun… Joel jaeggli
- Re: [v6ops] What can v6ops do? [was: RIPE-555 fun… Mikael Abrahamsson
- Re: [v6ops] What can v6ops do? [was: RIPE-555 fun… Brian E Carpenter
- Re: [v6ops] Fwd: RIPE-555 fundamentaly changes th… Vesna Manojlovic
- Re: [v6ops] Fwd: RIPE-555 fundamentaly changes th… Turchanyi Geza
- Re: [v6ops] Fwd: RIPE-555 fundamentaly changes th… Jeroen Massar
- Re: [v6ops] What can v6ops do? [was: RIPE-555 fun… Gert Doering
- Re: [v6ops] What can v6ops do? [was: RIPE-555 fun… Jeroen Massar
- Re: [v6ops] What can v6ops do? [was: RIPE-555 fun… Gert Doering
- Re: [v6ops] What can v6ops do? [was: RIPE-555 fun… Brian E Carpenter
- Re: [v6ops] What can v6ops do? [was: RIPE-555 fun… Jeroen Massar
- Re: [v6ops] What can v6ops do? [was: RIPE-555 fun… Jeroen Massar