Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11
Matthew Lepinski <mlepinski.ietf@gmail.com> Tue, 24 February 2015 17:38 UTC
Return-Path: <mlepinski.ietf@gmail.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF981A8765 for <sidr@ietfa.amsl.com>; Tue, 24 Feb 2015 09:38:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.099
X-Spam-Level:
X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=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 mT8ZVQtuberE for <sidr@ietfa.amsl.com>; Tue, 24 Feb 2015 09:38:08 -0800 (PST)
Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (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 30F401A8766 for <sidr@ietf.org>; Tue, 24 Feb 2015 09:38:08 -0800 (PST)
Received: by mail-oi0-f44.google.com with SMTP id a3so20596799oib.3 for <sidr@ietf.org>; Tue, 24 Feb 2015 09:38:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RzJwUD3iRo2IdpC6939iRzxHDWsuY/AjKVPNUEyweDI=; b=kH8Ewm62YKz8a8AjuAM7l/vbuMsBnxsK/3b5rlDW7YhTzfa8D0YMVVjIVfgzIDVRdv JUEFeZnsx9yChh2mlpqki7QZMEZsMSVCHH2g/yn7JU37/N3/um4wf7qJUUEvlgXEY8ui 2W+Azs/lq5kQ0bPI6AIOUxyrZ2dAPRJH0hsM6b2Wsy5DhBEHcl4HitJb3dt9LFbxthzH OEMgX8SN4NYZ5DlLZ5dIhyWvc9fifsmTCrqWuSNr1XJYYkIQmb8NvnE7rXMTR92QNvpK MIpUp+mi8NKLksXRzSp2Dr+dQTO1FElsAlwqPVs99cu66lkzAaxkrt5hAJyGcjRtJpjB oB8w==
MIME-Version: 1.0
X-Received: by 10.202.51.137 with SMTP id z131mr11302314oiz.10.1424799487394; Tue, 24 Feb 2015 09:38:07 -0800 (PST)
Received: by 10.202.135.17 with HTTP; Tue, 24 Feb 2015 09:38:07 -0800 (PST)
In-Reply-To: <54E3D163.1040600@mandelberg.org>
References: <54DA7C98.4040604@mandelberg.org> <D103DE3D.1041C%keyupate@cisco.com> <D104DC36.3310E%dougm@nist.gov> <m2wq3klab3.wl%randy@psg.com> <1423943624118.34986@nist.gov> <54E3D163.1040600@mandelberg.org>
Date: Tue, 24 Feb 2015 12:38:07 -0500
Message-ID: <CANTg3aAN9roAnK_3aeKnD3Y=maErB2=i5e+YaphxZe0hheWzVg@mail.gmail.com>
From: Matthew Lepinski <mlepinski.ietf@gmail.com>
To: David Mandelberg <david@mandelberg.org>
Content-Type: multipart/alternative; boundary="001a113cd3da528979050fd8fbef"
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/a2MJx2wFxJI6TC_1pEz6ejMX5fw>
Cc: "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Feb 2015 17:38:14 -0000
I am in the process of resolving issues in the bgpsec-protocol document in order to get out a new version before Dallas. Based on the discussion in this thread, I believe the best way forward is: 1) Add a small amount of security considerations text to address the original concern that David raised. (I believe the consensus is that this concern cannot be converted into an actual attack. However, other readers might reasonably have the same concern as David and so there is no harm laying the concern to rest in security considerations.) 2) Given that origin validation is now decoupled from path validation, we will put the AFI under the BGPsec signature to avoid potential IPv4 vs IPv6 issues. Any objections to this resolution of these issues? - Matt Lepinski On Tue, Feb 17, 2015 at 6:40 PM, David Mandelberg <david@mandelberg.org> wrote: > On 02/14/2015 02:53 PM, Sriram, Kotikalapudi wrote: > > I agree that the solution should not merely rely on the presence of a > validating ROA. > > But there is some more detail here that is worth looking into. The path > was fully signed > > and assume all signatures are valid. Then clearly the origin AS actually > announced it. > > The question or ambiguity is: Did the origin AS announce 1.2.0.0/16 > (v4) or 102::/16 (v6)? > > The ROA has AFI information, but the signed update does not (currently). > > https://tools.ietf.org/html/rfc6482#section-3.3 > > “Within the ROAIPAddressFamily structure, addressFamily contains the > > Address Family Identifier (AFI) of an IP address family. This > > specification only supports IPv4 and IPv6. Therefore, addressFamily > > MUST be either 0001 or 0002.” > > > > Hence, as Keyur has surmised, there is a possibility that the ROA can > help resolve the ambiguity here. > > But the ambiguity would still persist if the same origin AS happens to > have ROA(s) for > > both prefixes 1.2.0.0/16 (v4) and 102::/16 (v6) (though the > probability is extremely small). > > So, yes, a robust solution calls for something more than a validating > ROA. > > The ambiguity goes away if the AFI (of the announced prefix) is included > by the origin AS > > on the wire as well as in the sequence of octets that are signed. > > When there's no attack, I don't think there's any ambiguity about what > NLRI is being announced or withdrawn. RFC4760 seems to include (S)AFIs > in the right places on the wire. The only change that I think needs to > happen for this issue is including (S)AFIs in the data that's signed. > > -- > David Eric Mandelberg / dseomn > http://david.mandelberg.org/ > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > >
- Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protoc… David Mandelberg
- [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11 Sandra Murphy
- Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protoc… George, Wes
- Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protoc… Sriram, Kotikalapudi
- Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protoc… David Mandelberg
- Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protoc… Michael Baer
- Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protoc… David Mandelberg
- Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protoc… Michael Baer
- [sidr] David M's point about the bgpsec protocol … Sandra Murphy
- Re: [sidr] David M's point about the bgpsec proto… Randy Bush
- Re: [sidr] David M's point about the bgpsec proto… Randy Bush
- Re: [sidr] David M's point about the bgpsec proto… Sandra Murphy
- Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protoc… Keyur Patel (keyupate)
- Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protoc… Montgomery, Douglas
- Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protoc… Randy Bush
- Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protoc… Sriram, Kotikalapudi
- Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protoc… David Mandelberg
- Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protoc… Matthew Lepinski
- Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protoc… Michael Baer
- Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protoc… Sriram, Kotikalapudi
- [sidr] Levels of BGPsec/RPKI validation, was: Re:… Iljitsch van Beijnum
- Re: [sidr] [Idr] Levels of BGPsec/RPKI validation… Roque Gagliano (rogaglia)
- Re: [sidr] [Idr] Levels of BGPsec/RPKI validation… Iljitsch van Beijnum
- Re: [sidr] [Idr] Levels of BGPsec/RPKI validation… David Mandelberg
- Re: [sidr] [Idr] Levels of BGPsec/RPKI validation… Iljitsch van Beijnum
- Re: [sidr] [Idr] Levels of BGPsec/RPKI validation… Sandra Murphy
- Re: [sidr] [Idr] Levels of BGPsec/RPKI validation… Roque Gagliano (rogaglia)
- Re: [sidr] [Idr] Levels of BGPsec/RPKI validation… Randy Bush
- Re: [sidr] Levels of BGPsec/RPKI validation, was:… Geoff Huston
- Re: [sidr] [Idr] Levels of BGPsec/RPKI validation… Sriram, Kotikalapudi
- Re: [sidr] [Idr] Levels of BGPsec/RPKI validation… Randy Bush
- Re: [sidr] [Idr] Levels of BGPsec/RPKI validation… Jared Mauch
- Re: [sidr] [Idr] Levels of BGPsec/RPKI validation… Iljitsch van Beijnum
- Re: [sidr] [Idr] Levels of BGPsec/RPKI validation… Sriram, Kotikalapudi
- Re: [sidr] [Idr] Levels of BGPsec/RPKI validation… Iljitsch van Beijnum
- Re: [sidr] [Idr] Levels of BGPsec/RPKI validation… Randy Bush
- Re: [sidr] [Idr] Levels of BGPsec/RPKI validation… Tim Bruijnzeels
- Re: [sidr] Levels of BGPsec/RPKI validation, was:… Matthew Lepinski
- Re: [sidr] Levels of BGPsec/RPKI validation, was:… Iljitsch van Beijnum
- Re: [sidr] Levels of BGPsec/RPKI validation, was:… Matthew Lepinski
- Re: [sidr] Levels of BGPsec/RPKI validation, was:… Iljitsch van Beijnum
- Re: [sidr] Levels of BGPsec/RPKI validation, was:… Sriram, Kotikalapudi
- Re: [sidr] Levels of BGPsec/RPKI validation, was:… Stephen Kent
- Re: [sidr] Levels of BGPsec/RPKI validation, was:… Iljitsch van Beijnum
- Re: [sidr] Levels of BGPsec/RPKI validation, was:… Stephen Kent
- Re: [sidr] Levels of BGPsec/RPKI validation, was:… Sriram, Kotikalapudi