From nobody Mon Jul 1 06:47:43 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D4A1200B8 for ; Mon, 1 Jul 2019 06:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=muada.com header.b=Ach1D3Tu; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=E/KFmvPq 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 Vh2ZUrShGWPh for ; Mon, 1 Jul 2019 06:47:28 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80C53120251 for ; Mon, 1 Jul 2019 06:47:28 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 93AA321650; Mon, 1 Jul 2019 09:47:27 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Mon, 01 Jul 2019 09:47:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=muada.com; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm3; bh=uV1X+qiQL4JkvMDAz3qjLWm aNKDwzstqrJyA1g5ACH4=; b=Ach1D3TuTqNQofmyUoioC7y72vGaCpAghb63PaZ mqGc7gFWniGn/4TbATdWlXk5sW8gZXsYbEbaTkOcKjQfoOHNWR9neprIVHBLt0Oq iIS2YoOcoXxlzrP+gLdbYI7W5GgLml9tGCI40jWDQJykRMtt0mVDz3FFzcxc/DVd RaYTZk0T/HuYCYjuyW2hMDeq2dyFK6eszXyuyS5gHK1dow8LMGC5ERsmvuB710ek 3snvdoEK7H8AHVF+Q1vRefhD5Di79obRDc8taJggq3Ti1LwVVO6DqzeRHM2PXSzS jvyk3Y5yMBXGWLs7I0vQ7zsxYbWxKAqkdsPhtmO7dEz56DA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=uV1X+q iQL4JkvMDAz3qjLWmaNKDwzstqrJyA1g5ACH4=; b=E/KFmvPqHhXEDZjmz6IpDq zWMB3L0rArVnAf/scWtPH+4SL9SkcnBqQGvTMxCzsN0zHUpBUGLKK6XU5ja7Xkt5 G7rEWseOXZurCgguT449EPVqO9QW64Q92GttwxqJtxEMBynibKEw8FIFvzqWiER1 K5WerxUNwfFlERQgsPjsLwhy9R/6ki+riUIH+AwMw9A6lzbh+cFbffxcKn5uUL8Q jkshLn5d30sFpYykiuHC/5sdDBKLyGIXutuid5z48J6mQG1zkxtGAmeTc5LDZIkX OqxKdZnLOYGAybbjdxXr6BN9iLnOBUNhceiX/aUuCXYxjpidc8FrvJhF4k3HFF+g == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrvdeigdeikecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhkfgtggfuffgjvfhfofesrgdtmherhhdtvdenucfhrhhomhepkfhljhhithhs tghhuchvrghnuceuvghijhhnuhhmuceoihhljhhithhstghhsehmuhgruggrrdgtohhmqe enucfkphepkeefrdekhedrjedurdelheenucfrrghrrghmpehmrghilhhfrhhomhepihhl jhhithhstghhsehmuhgruggrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from [192.168.178.17] (83-85-71-95.cable.dynamic.v4.ziggo.nl [83.85.71.95]) by mail.messagingengine.com (Postfix) with ESMTPA id 861AF8006C; Mon, 1 Jul 2019 09:47:26 -0400 (EDT) From: Iljitsch van Beijnum Message-Id: <10331B58-4353-417B-859B-8E78EF4A9F9D@muada.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E5B977E5-C713-43FB-8783-77ACD720CA70" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Mon, 1 Jul 2019 15:47:24 +0200 In-Reply-To: Cc: sidrops@ietf.org To: Alexander Azimov References: <9D1926FB-30B0-4A28-8AAF-32527BCC2F9F@muada.com> X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [Sidrops] On validating AS paths X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2019 13:47:42 -0000 --Apple-Mail=_E5B977E5-C713-43FB-8783-77ACD720CA70 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Alexander, On 26 Jun 2019, at 18:39, Alexander Azimov wrote: > I assume that after talking with Job Snijders you are aware of ASPA = drafts. Yes. > They cover the detection of anomalies (invalid ASPATHs) that are = received from customers and peers + specify RPKI object exactly for = customer-to-provider pairs. Yes. Note that in my previous message I was specifically addressing = validating the _entire_ path, while ASPA only concerns itself with = validating the "up" part of the path, where the only valid relationships = are provider-customer and sibling-sibling. Of course once we can validate the entire path, we can by definition = also validate any subset. > And of course, a path //^\ (in your notation) received from customer = or peer is invalid. But I assume that you also had this in mind. Yes, this is a valid full path but if you get it from a peer then it's = actually \//^\ (from a customer) or ^//^\ (from a peer) so that's not = valid. > What I find curious in your proposal is the goal to extend the = detection of invalid paths for prefixes that are received from = providers. > I was also considering this option, but it will not work with c2p = database only. The problem occurs with siblings.=20 Basically, a sibling relationship occurs when there is a customer - = provider relationship in both directions. (As per Gao/Rexford there is = the additional constraint that these relationships have the lowest local = preference, but that's probably not relevant for path validation.) So for the "up" part of the path we can use your algorithm for = validation. Then for the "down" part of the path (i.e., the part that = your customers see when they get updates from you, not covered in your = draft) the same procedure will work as long as we look at customer -> = provider relationships rather than provider <- customer relationships. = I.e.: 900 800 200 100 i You care 800. You see a valid 200 \ 100 relationship. You know that 800 = ^ 200 because you are 800. 900 sees a valid 900 / 800 relationship. 900 sees 800 ? 200 based on the = C2P database as there is no C2P relationship between 800 and 200 in = either direction. But as per my previous message, any path with exactly = one unknown relationship between a valid up part and a valid down part = is still valid so the entire path is valid. > Take a look at the next example: > a1 p2p a2 c2c a3 p2c a4 (p2p for peering, c2c for sibling, a4 is = checking ASPATH) Do you mean: a1 ^ a2 - a3 \ a4 Note that you are using the opposite order to how BGP AS paths are = normally shown, with the origin on the right. But as valley-freeness = doesn't depend on the direction, I'll ignore that here. a1 ^ a2 - a3 \ a4 =3D /-^ is a valid path, there are no valleys. > If records for a1 exists (so we know that a2 isn't in the set of = providers of a1), (a2, a3) records exist, but (a3, a2) doesn't, the = outcome of verification procedure at a4 will be invalid.=20 So a2 / a3 but not a2 \ a3 and thus not a2 - a3. This means the path a1 ^ a2 - a3 \ a4 is actually: a1 ^ a2 / a3 \ a4 ^/\ is not a valid path. So a3 has to register its C2P relationship with = a2. > Maybe it can be fixed by adding a sibling flag to the c2p record, but = at the moment I'm not sure about security consequences. In the draft you mention that it's important that the customer can claim = the relationship and not the provider. So I would be hesitant to have a = S2S relationship record is that would either be too easy to claim (if = one sibling can do it) or complex to implement (only valid when both = siblings claim the relationship). > And to follow up my previous email, if we have a network with = malicious intent that would hijack/disaggregate prefixes + create a = 'virtual peering link' between it and victim ASN, its customers will not = able to detect it anyway since it will look like a valid path: '-\'. You mean a virtual sibling link? No, we certainly don't want that to be = possible. Greetings, Iljitsch= --Apple-Mail=_E5B977E5-C713-43FB-8783-77ACD720CA70 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Alexander,

On 26 Jun = 2019, at 18:39, Alexander Azimov <a.e.azimov@gmail.com> wrote:

I assume that after talking with = Job Snijders you are aware of ASPA = drafts.

Yes.

They cover the detection of anomalies (invalid ASPATHs) that = are received from customers and peers + specify RPKI object exactly for = customer-to-provider pairs.

Yes. Note that in my previous message I was = specifically addressing validating the _entire_ path, while ASPA only = concerns itself with validating the "up" part of the path, where the = only valid relationships are provider-customer and = sibling-sibling.

Of course once we = can validate the entire path, we can by definition also validate any = subset.

And of course, a path //^\ (in = your notation) received from customer or peer is invalid. But I assume = that you also had this in mind.

Yes, this is a valid full path but if you get it = from a peer then it's actually \//^\ (from a customer) or ^//^\ (from a = peer) so that's not valid.

What I find curious in your = proposal is the goal to extend the detection of invalid paths for = prefixes that are received from providers.
I was also = considering this option, but it will not work with c2p database only. = The problem occurs with siblings.

Basically, = a sibling relationship occurs when there is a customer - provider = relationship in both directions. (As per Gao/Rexford there is the = additional constraint that these relationships have the lowest local = preference, but that's probably not relevant for path = validation.)

So for the "up" part of = the path we can use your algorithm for validation. Then for the "down" = part of the path (i.e., the part that your customers see when they get = updates from you, not covered in your draft) the same procedure will = work as long as we look at customer -> provider relationships rather = than provider <- customer relationships. I.e.:

900 800 200 100 i

You care 800. You see a valid 200 \ 100 = relationship. You know that 800 ^ 200 because you are 800.

900 sees a valid 900 / 800 relationship. 900 sees = 800 ? 200 based on the C2P database as there is no C2P relationship = between 800 and 200 in either direction. But as per my previous message, = any path with exactly one unknown relationship between a valid up part = and a valid down part is still valid so the entire path is = valid.

Take a look at = the next example:
a1 p2p a2 c2c a3 p2c a4 = (p2p for peering, c2c for sibling, a4 is checking = ASPATH)

Do you = mean: a1 ^ a2 - a3 \ a4

Note that = you are using the opposite order to how BGP AS paths are normally shown, = with the origin on the right. But as valley-freeness doesn't depend on = the direction, I'll ignore that here.

a1 ^ a2 - a3 \ a4 =3D /-^ is a valid path, there = are no valleys.

If records for a1 = exists (so we know that a2 isn't in the set of providers of a1), (a2, = a3) records exist, but (a3, a2) doesn't, the outcome of verification = procedure at a4 will be invalid.

So a2 = / a3 but not a2 \ a3 and thus not a2 - a3.

This means the path a1 ^ a2 - a3 \ a4 is = actually:

a1 ^ a2 / a3 \ = a4

^/\ is not a valid path. So a3 = has to register its C2P relationship with a2.

Maybe it can be fixed by adding a sibling flag to the c2p = record, but at the moment I'm not sure about security consequences.

In the = draft you mention that it's important that the customer can claim the = relationship and not the provider. So I would be hesitant to have a S2S = relationship record is that would either be too easy to claim (if one = sibling can do it) or complex to implement (only valid when both = siblings claim the relationship).

And to follow up = my previous email, if we have a network with malicious intent that would = hijack/disaggregate prefixes + create a 'virtual peering link' between = it and victim ASN, its customers will not able to detect it anyway since = it will look like a valid path: '-\'.

You mean a virtual sibling link? No, we = certainly don't want that to be possible.

Greetings,

Iljitsch
= --Apple-Mail=_E5B977E5-C713-43FB-8783-77ACD720CA70-- From nobody Mon Jul 1 07:40:05 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C180F1200D8 for ; Mon, 1 Jul 2019 07:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=muada.com header.b=qb3TsxFv; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=RQOw9wg2 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 FVkJ_mAzegAI for ; Mon, 1 Jul 2019 07:40:00 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E76F1200D6 for ; Mon, 1 Jul 2019 07:40:00 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 81A7821FC1; Mon, 1 Jul 2019 10:39:59 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Mon, 01 Jul 2019 10:39:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=muada.com; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=N HXH64cRMtz+rQdeLIyn9C1i+/ZHC9EU7v//wq0TG+A=; b=qb3TsxFvCA4E3TqlF LvVlZflQs8HH6xiL8oVnPnVr72/osznQmw9jSJzoV2jjTPdjvi3JgftoTTh0aFTH c9sAg9yERbmrOehhPT/NnqBWTFH06DHtLl2h5hSiMhIVRrfE8/HRjezEubSLCZWK S7B8w5URbHhKOIACpxiDXJC7nQzDy0MHvBcuFq8Y9KlHnZXkL71EgotCJhSZNsBD SMsRGhObWTeJ2vKoOB5gtPB7f8ItAWFMM64oEO0ebMCb4fciBsl5vy6n3CVtDLQ1 i3zFFb9ALQ+b8zqloufqpQTgqQ3ZAEkkm8BpY7rZ+41v7f8PYUj6r5MJHsL8zfBE k951g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=NHXH64cRMtz+rQdeLIyn9C1i+/ZHC9EU7v//wq0TG +A=; b=RQOw9wg2HxWDWlXjG9kX2PHCgDpUeD3PPYXLVwWtcEb3RMYuJBYgS16Ow UzUEcFqGZb/wMXpUptbz1OYrzLvhxZmQJ+c44yI61wMb7DRPQKgzd75ajiYMUrZb OsMOr5w28fU7h2DPbwhWW0KDmVTQUVBhtElEqcbPfkvLLtn8pf/i/27MRutKTF89 aw+ErmfdzI8SazGtynnmZ084o574lWJZbGBTNLgEYhHLA3Vjlgj0WpHdxwpgOILR dtrWgoCvsJALBsgyNEXd2dRV4r6ljzRfHd6HwcVypdkDRlGe9tnFB+mcfRMh1oEQ sqLSmRmfM3Yz5pET63oX/qg6Inb+A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrvdeigdektdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpefklhhjihht shgthhcuvhgrnhcuuegvihhjnhhumhcuoehilhhjihhtshgthhesmhhurggurgdrtghomh eqnecuffhomhgrihhnpehivghtfhdrohhrghenucfkphepkeefrdekhedrjedurdelheen ucfrrghrrghmpehmrghilhhfrhhomhepihhljhhithhstghhsehmuhgruggrrdgtohhmne cuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from [192.168.178.17] (83-85-71-95.cable.dynamic.v4.ziggo.nl [83.85.71.95]) by mail.messagingengine.com (Postfix) with ESMTPA id F14C3380087; Mon, 1 Jul 2019 10:39:57 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Iljitsch van Beijnum In-Reply-To: Date: Mon, 1 Jul 2019 16:39:55 +0200 Cc: "sidrops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Sriram, Kotikalapudi (Fed)" X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [Sidrops] Path validation with RPKI X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2019 14:40:04 -0000 Hi Kotikalapudi, On 28 Jun 2019, at 00:53, Sriram, Kotikalapudi (Fed) = wrote: > Just in case you are not aware, there is another effort in the GROW WG=20= > for route leaks solution: > = https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigatio= n-00 =20 Indeed, I wasn't aware of this one. Any particular reason these efforts = are split between sidrops and grow? And are idr and/or sidr also in some = way involved? The ASPA draft and my draft assume out of band information to validate = (parts of) the AS path. The other approach is convey the necessary = information in band, and as I was reading this draft I thought this was = a good way to do it. Obviously there are limitations to in band, most = notably, the ability of a malicious AS to manipulate any in band = information in the absense of cryptographic protections like the ones = BGPsec offer. So basically, using the notation I invented last week, RLDM conveys a ^ = or / somewhere in the path (assuming origin on the right direction). And = as the validating AS knows whether it has a ^ or \ relationship with the = next AS, we can detect invalid paths like these: ^??^?? ^??/?? \??^?? \??/?? (With more or fewer ? as desired.) I think that could work well. But: I have two issues: The first issue: this uses the large communities feature. I'm not sure = how this is implemented, but with regular communities, routers must = sometimes be configured to propagate them, and can be configured to = _not_ propagate them. If this is the same for large communities, then = the feature won't be as robust as it could be, as the community may not = be propagated over eBGP sessions. And less than well meaning networks = have plausible deniability "oh no we turn off large communities because = of ...". So it would be better to make this its own transitive path attribute. = The BGP spec is very clear on how these need to be propagated. Second, this is makes the whole thing not work: 2. Else, when propagating a route that already includes a DO (i.e., was received with a DO) to a customer or lateral peer, replace the DO value with the local ASN. So assume the following path: 5 4 3 2 1 With 5 being the validating AS (which would normally not show up in the = AS path) and 1 being the origin AS. Now suppose the relationships are: 5 ^ 4 \ 3 ^ 2 \ 1 AS 2 includes DO=3D2. So if AS 5 has access to that information, it can = determine that this is an invalid path. However, AS 4 replaces DO=3D2 = with DO=3D4. However, now AS 5 only gets to see that the prefixes it = gets from AS 4 are from peering, which is not news to AS 5. The = actionable fact that AS 2 was sending the prefix in question over = peering and that prefix is now leaked by AS 4 is now hidden from AS 5, = so AS 5 is not in the position to take any action. What needs to happen is that the community or attribute is ONLY added = when it's not present and a prefix is sent over a ^ or / relationships, = and then subsequently never touched. > You mention, "We implement this by extending RPKI ROAs so that=20 > in addition to the origin AS, they also list all possible transit = ASes." > The idea of "extended ROA" was considered during BGPsec=20 > design discussions. See Section 6.5.2, list item #3 in RFC 8374: > https://tools.ietf.org/html/rfc8374=20 > The extended ROA was proposed to include the transit AS of the origin = AS. > The purpose was to make it easier for resource-constrained stub ASes=20= > to participate in BGPsec without incurring the upgrade costs. It says: This approach was rejected due to possible complications with the creation and use of a new RPKI object, namely, the extended ROA. What would be the possible complications with creating such extended = ROAs? Obviously there is some extra work, but I can't imagine any show = stoppers. > In your design, you seem to include in the ROA a sequence AS1, AS2, = AS3, ... where > AS1 is the origin AS, AS2 is transit of AS2, AS3 is transit of AS3, = etc. Is that right?=20 Well, sort of. Suppose AS1 is the origin and AS2 and AS3 provide = transit. Then that would result in: AS1 AS2 AS3 or: AS1 AS3 AS2 But now suppose AS1 gets transit from AS2 and AS2 gets transit from AS3. = Then you get: AS1 AS2 AS3 but not: AS1 AS3 AS1 So the two different transit scenarios can't be determined from the = extended ROA. I don't think this is an issue because the unintended = paths that would be declared valid in this case would still have to = appear in a BGP AS path, which is very unlikely. > Prefix owner may know the origin AS (AS1) and one level higher transit = AS (AS2). > But they would typically not know the transit ASes further up in the = hierarchy. > Does that pose a challenge for your design?=20 I think the main challenge is not determining this information once, = that seems doable. But now if there is a change in the transit providers = for AS2, AS2 has to inform all of its customers and these customers have = to take action. Also, if internet exchange route servers are present in the path, then = that could potentially add a large number of "transit" ASes. In this sense, the ASPA approach works better. On the other hand, my = approach gives origin ASes more options to determine their policy. Perhaps a hybrid solution that allows origin ASes to indicate "these = ASes, plus any transit ASes specified by these ASes" or "these ASes, and = nothing else". Thanks, Iljitsch= From nobody Mon Jul 1 09:48:20 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2851206A7; Mon, 1 Jul 2019 09:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov 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 KAu6A5XxndUN; Mon, 1 Jul 2019 09:48:07 -0700 (PDT) Received: from GCC01-DM2-obe.outbound.protection.outlook.com (mail-eopbgr840130.outbound.protection.outlook.com [40.107.84.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00E5B1206A3; Mon, 1 Jul 2019 09:47:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nqeP+W1yVAJpfL0loqlmwoFA8sIhFjwPyGX7T/FJLZ8=; b=tbs8J1lFRGnwROb+8HxVHYw/yp5dPrIdwwGOcQn9l3yBZIPp+GONJaCQENDeqGNM/TZua9MrcGWC54I8MSh6Tvmt2ZP9o3AlT9w4d8OncbxbE/trnBHfgUw4sqDSn7VbpE0n/eA3/1/qLGI6/8PqPc/SUgYRyyv5+wICTDo9mhc= Received: from DM6PR09MB3019.namprd09.prod.outlook.com (20.178.2.203) by DM6PR09MB2763.namprd09.prod.outlook.com (20.176.97.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.20; Mon, 1 Jul 2019 16:47:54 +0000 Received: from DM6PR09MB3019.namprd09.prod.outlook.com ([fe80::146b:72d7:952f:2424]) by DM6PR09MB3019.namprd09.prod.outlook.com ([fe80::146b:72d7:952f:2424%7]) with mapi id 15.20.2032.019; Mon, 1 Jul 2019 16:47:54 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Iljitsch van Beijnum CC: "sidrops@ietf.org" , "grow@ietf.org" Thread-Topic: [Sidrops] Path validation with RPKI Thread-Index: AQHVMBrl1W3p3kqzpUmY8Mpnbpsql6a16dbg Date: Mon, 1 Jul 2019 16:47:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.140.161] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ec9e7bb6-c90a-4cf0-e5bf-08d6fe43dd0e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:DM6PR09MB2763; x-ms-traffictypediagnostic: DM6PR09MB2763: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00851CA28B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(366004)(376002)(136003)(396003)(189003)(31014005)(199004)(51444003)(6916009)(8676002)(81166006)(81156014)(66946007)(6506007)(229853002)(6436002)(73956011)(66446008)(66556008)(66476007)(7736002)(2906002)(64756008)(52536014)(74316002)(66066001)(3846002)(6116002)(102836004)(76116006)(478600001)(8936002)(86362001)(966005)(76176011)(446003)(476003)(55016002)(7696005)(316002)(6246003)(33656002)(71200400001)(14454004)(9686003)(486006)(71190400001)(186003)(68736007)(305945005)(25786009)(5660300002)(6306002)(256004)(14444005)(4326008)(99286004)(26005)(11346002)(54906003)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR09MB2763; H:DM6PR09MB3019.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: bN9jsp1DWoyU5cRKboOdtp+AHQ1sZVjtNtjfCl977dbupO3ozkdqU6+CHSdXOt2cApRSBJ1I+ltYtQWViLw3sJG+6Id1t4dviBmzBhP1I8hSmOYYj0kjeWTh6YmSFmmEjt2K9/jbwjlyVCsrfQ6VSiu4++Ip17tlNRk8CF4NH2r7qyWZv+erAbS4uR6nDIUQuWSDBv7f7nlVcyG1HDuc5irkHN09HknslZ8OgHluwf7npmLXFoj1fKfaYqZqKKLd7dj26fPHhj+Ur11eIRcuDV6O6hHSHlKGDg6lMeVqTIUyiCaXSIJMC0/98Gv//UwHQq3gpz0wEv4Gb/XXphSeAeV6a49+hvzA+O46hDWJmm0byNgiMuzf9cXFUJ7N7rb6TeqzuPvKqdpwlC5piJNb+MwuLGf8Tq/5H+K/hGIs6Xk= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: ec9e7bb6-c90a-4cf0-e5bf-08d6fe43dd0e X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jul 2019 16:47:54.2769 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ksriram@nist.gov X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR09MB2763 Archived-At: Subject: Re: [Sidrops] Path validation with RPKI X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2019 16:48:11 -0000 [Including GROW list because some members there would be interested given the RLP draft has home in GROW]=20 Iljitsch, >> Just in case you are not aware, there is another effort in the GROW WG=20 >> for route leaks solution: >> https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigat= ion-00 =20 >Indeed, I wasn't aware of this one. -- snip -- >=20 > I think that could work well. But: I have two issues: >=20 > The first issue: this uses the large communities feature. I'm not sure ho= w this is > implemented, but with regular communities, routers must sometimes be > configured to propagate them, and can be configured to _not_ propagate > them. If this is the same for large communities, then the feature won't b= e as > robust as it could be, as the community may not be propagated over eBGP > sessions. And less than well meaning networks have plausible deniability = "oh > no we turn off large communities because of ...". The current feeling in GROW is that it is possible to make transitivity wor= k for=20 Large Communities. Ruediger talks about providing strong policy guidance for operators about this. =20 >=20 > So it would be better to make this its own transitive path attribute. The= BGP > spec is very clear on how these need to be propagated. >=20 > Second, this is makes the whole thing not work: >=20 > 2. Else, when propagating a route that already includes a DO (i.e., > was received with a DO) to a customer or lateral peer, replace > the DO value with the local ASN. >=20 > So assume the following path: >=20 > 5 4 3 2 1 >=20 > With 5 being the validating AS (which would normally not show up in the A= S > path) and 1 being the origin AS. Now suppose the relationships are: >=20 > 5 ^ 4 \ 3 ^ 2 \ 1 >=20 > AS 2 includes DO=3D2. So if AS 5 has access to that information, it can d= etermine > that this is an invalid path. However, AS 4 replaces DO=3D2 with DO=3D4. = However, > now AS 5 only gets to see that the prefixes it gets from AS 4 are from pe= ering, > which is not news to AS 5. The actionable fact that AS 2 was sending the = prefix > in question over peering and that prefix is now leaked by AS 4 is now hid= den > from AS 5, so AS 5 is not in the position to take any action. >=20 AS5 can take action. No issue there. I'll explain. Is 3 not doing RLP? If 3 is doing RLP, it would not propagate the update to= 4. But to try to get to your point, let us say 3 is not participating in RLP and leaked the update to 4. Now, 4 detects the update to be a route leak because it does not expect a DO set in a route received on a customer link. If 4 has an alternate path for the prefix that is clean (not route leak), it would prefer that. Else, 4 accepts and propagates the leaked route from= =20 3 (customer) in order to avoid unreachability. Yes, 4 replaces DO=3D2 with = DO=3D4, but there is something more that 4 does. The draft specifies (p. 5): 2. Leak detected (L) indication: ASN of the first RLP-aware AS in the path to assert that it forwarded the route from a customer or lateral peer despite detecting a leak (to avoid unreachability). So 4 also adds L =3D 4. This L informs 5 that the route is tainted (Leaked)= . 5 would prefer an alternate route that is clean, if available. So, yes, 5 can take action. This will become even more clear if you take look at slide 14, scenario 2 in our scenario analyses slide deck: https://www.nist.gov/sites/default/files/documents/2018/10/22/rlp_using_bgp= _community-v4.pdf=20 > What needs to happen is that the community or attribute is ONLY added whe= n > it's not present and a prefix is sent over a ^ or / relationships, and th= en > subsequently never touched. We did consider this. But it is not necessary because L=20 prevents what you apprehended.=20 It was felt that DO should convey the latest AS that needs to assert down o= nly. In general, that AS is in closer proximity to the receiver in question than the very first AS that initially set DO. >=20 > > You mention, "We implement this by extending RPKI ROAs so that > > in addition to the origin AS, they also list all possible transit ASes.= " > > The idea of "extended ROA" was considered during BGPsec > > design discussions. See Section 6.5.2, list item #3 in RFC 8374: > > https://datatracker.ietf.org/doc/rfc8374/=20 -- snip -- > > The extended ROA was proposed to include the transit AS of the origin A= S. > > The purpose was to make it easier for resource-constrained stub ASes > > to participate in BGPsec without incurring the upgrade costs. >=20 > It says: >=20 > This approach was rejected due to possible complications with the > creation and use of a new RPKI object, namely, the extended ROA. >=20 > What would be the possible complications with creating such extended ROAs= ? > Obviously there is some extra work, but I can't imagine any show stoppers= . It was many years ago (the design phase).=20 I think it was just the extra work that concerned us. > -- snip -- > Iljitsch Thanks, Sriram From nobody Mon Jul 1 11:27:42 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC0A712069E for ; Mon, 1 Jul 2019 11:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Vx7dM9aZ0iTh for ; Mon, 1 Jul 2019 11:27:39 -0700 (PDT) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 3E62F120106 for ; Mon, 1 Jul 2019 11:27:39 -0700 (PDT) Received: by mail-qt1-x834.google.com with SMTP id y57so15709922qtk.4 for ; Mon, 01 Jul 2019 11:27:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=h8RESQCzw/l5WfkBTKOL5UJrusEKOQ7vyND1h3hR7/w=; b=ss2lgebyzteKHKrQdLvf/r67Oop5JFOvWPXLHUeiqKv02doLKOVucnUJWvzYrWjp9O G9aI/8Xxz4H3N6hi4ztbhjI4LXv3WNop+IL5bvZaCv7iWQXkZji8DnFIk2hCjD4FfHR1 rOrj6jyRSbbo5+/0fJxZlZyxZ9vNSJ+4PtwMubTIyco6J9Vq+FYvT+pnA4Tx2tRE8G+Q N8PFA7TQhHydQlz6oAb2dKW8YKkQ197Q2Ob5TfCBEV538HX4CECKwFHqq9x5fGiwYOPm 19Axmd/wUn1tIhEXHfCrwDdF2IuQrP76SUbiy+yBEW3rQo3xRXS6Qz3LllcQ8lvxupms nZkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=h8RESQCzw/l5WfkBTKOL5UJrusEKOQ7vyND1h3hR7/w=; b=deV0N6VBxYjOOkNg7mHaKoieI3YMpFUkPxInSZ4WxsvA8KzCA30Kq+jvAtxqvE7Kjl vf2htvbQTV+iOVPBh5jy8sk9MNESlaJcbZGAyyDzZ6B1v0MVEjMb6ksBVLaVxlz6OEuI 0ZnZsJpT+/moCk0eHHAhdGt7GGhfrugpI+OflwX0wGWY++Yj8w+Wc1K4sYZryBlF3ehP RDeL+sKq/kitTW8hhvcDM997T6LoMbK9kwPT7x8A2rP9kTj1bmab6d/YVOtt8gGLrnnf MMq2aVxFNJzzvaHCSHfgbIekQNQeqP2AY196pQH8MWrkQLVTAxL6GdSJ3oPUNG5n492Q Z9Jg== X-Gm-Message-State: APjAAAUhA4RjqK6lOH6jtLmwGsWAhQk81DPBbtXtUDtoIIwqNChZo+b6 Wc9uM8f8ADfi46pmyRQidfC5ebRLfoMaOZCxz+8= X-Google-Smtp-Source: APXvYqylKEhpYDS1H2/uGCQCd28fluJl9qWxa3VdY8xbmUY1iCLCPIcWPLu1Uq5fXplQPZgVPiGoKYS7lTX2xLLsXkc= X-Received: by 2002:aed:3f0c:: with SMTP id p12mr21826797qtf.109.1562005658140; Mon, 01 Jul 2019 11:27:38 -0700 (PDT) MIME-Version: 1.0 References: <9D1926FB-30B0-4A28-8AAF-32527BCC2F9F@muada.com> <10331B58-4353-417B-859B-8E78EF4A9F9D@muada.com> In-Reply-To: <10331B58-4353-417B-859B-8E78EF4A9F9D@muada.com> From: Christopher Morrow Date: Mon, 1 Jul 2019 14:27:27 -0400 Message-ID: To: Iljitsch van Beijnum Cc: Alexander Azimov , SIDR Operations WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Sidrops] On validating AS paths X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2019 18:27:41 -0000 On Mon, Jul 1, 2019 at 9:47 AM Iljitsch van Beijnum wrote: > Yes. Note that in my previous message I was specifically addressing validating the _entire_ path, while ASPA only concerns itself with validating the "up" part of the path, where the only valid relationships are provider-customer and sibling-sibling. isn't this the point of 'bgpsec'? meaning: "you can do this when you see bgpsec signed paths from bgp peers" > > Of course once we can validate the entire path, we can by definition also validate any subset. > > And of course, a path //^\ (in your notation) received from customer or peer is invalid. But I assume that you also had this in mind. From nobody Mon Jul 1 12:34:02 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C49120177 for ; Mon, 1 Jul 2019 12:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=muada.com header.b=MKCzy2wA; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=zKCClqZ7 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 z77nC9cY_RPg for ; Mon, 1 Jul 2019 12:33:58 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE8E9120170 for ; Mon, 1 Jul 2019 12:33:57 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 7A4EB20D12; Mon, 1 Jul 2019 15:33:54 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Mon, 01 Jul 2019 15:33:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=muada.com; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=D 2KyD/+hwd7DP32V+DnsXfK4zCItXBhrbZibjuB6ekM=; b=MKCzy2wAa2CsCEnIh tkzCioRRj8X1+gtpEm6bVhnFcJs0TKWLoWkqd4xgIVUOipDRbl4YTgDcYRmcZu2c bnRt/PglUrNkzejT1Rdva9jFZogEcXl62C1gN16Ura/xjujuv1Du02Cxp+kd9X1f r2ylDxZdvsbhc+dMpB0uUeJSB8wgiP4tg5rzbaZnZwG036+MtA/G/x3+m1G8ZCkv 1p/5lKAdCyYkb+LOzEPc12H2jFRrPuPNYKeiQedY9VPwM9B0B6mMMplNN6TBjoD/ ohaKLpsSWD8rVAPsEG4WAV/LVjksCoakQ3otZyhZ8zmCARs5ajPAm4ZRjSvIuQqt xp9Pg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=D2KyD/+hwd7DP32V+DnsXfK4zCItXBhrbZibjuB6e kM=; b=zKCClqZ7EGLFpUF62pNHe3TFM6iFJgT8hrmmSVG+o+TKwqGLpLCWr3MoK kjqrH/N++L+5oTyLEzZK2zIl7mYThBuO/W/2LqM5284S++cdR8Nw7EWaIXZHxffM k5JxUjBc+CgGkrLtohm7YI0pWYEKIxOVvLRSXCMVTO/0TSipxCt8p0Hp+4tvn6w3 VUsn95nBkbc0Ealpc8apWWgGuUZH4phWD/fpl5sSB/Pl16N8T5WzoGfuhaBtkm66 DTFukC9vl3jBc4btFJ/69PSpElSs1VTCOo1ONPAgqmu07ZfneO8DceRwWEd8Xv1v iZpK3ADjPUW+7wBHoH3qCeo55Q1Cw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrvdeigddufeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepkfhljhhi thhstghhuchvrghnuceuvghijhhnuhhmuceoihhljhhithhstghhsehmuhgruggrrdgtoh hmqeenucffohhmrghinhepuhhsfhdrvgguuhenucfkphepkeefrdekhedrjedurdelheen ucfrrghrrghmpehmrghilhhfrhhomhepihhljhhithhstghhsehmuhgruggrrdgtohhmne cuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from [192.168.178.24] (83-85-71-95.cable.dynamic.v4.ziggo.nl [83.85.71.95]) by mail.messagingengine.com (Postfix) with ESMTPA id 146C3380085; Mon, 1 Jul 2019 15:33:52 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Iljitsch van Beijnum In-Reply-To: Date: Mon, 1 Jul 2019 21:33:50 +0200 Cc: Alexander Azimov , SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: <15E1C5FA-C511-4377-A582-3320BEBD8AAD@muada.com> References: <9D1926FB-30B0-4A28-8AAF-32527BCC2F9F@muada.com> <10331B58-4353-417B-859B-8E78EF4A9F9D@muada.com> To: Christopher Morrow X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [Sidrops] On validating AS paths X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2019 19:34:01 -0000 On 1 Jul 2019, at 20:27, Christopher Morrow = wrote: >> Yes. Note that in my previous message I was specifically addressing = validating the _entire_ path, while ASPA only concerns itself with = validating the "up" part of the path, where the only valid relationships = are provider-customer and sibling-sibling. > isn't this the point of 'bgpsec'? meaning: "you can do this when you > see bgpsec signed paths from bgp peers" Unless I'm missing something (I don't think so, but it's a complicated = system so maybe I am), BGPsec gives you two things: 1. Signatures on all the hops in the path, so you can check that the BGP = update did traverse those routers/ASes and no others 2. A signature from any given AS in the path on the next hop AS, so you = can determine that the update was propagated as intended by each = previous hop These features are orthogonal to the issue of route leaks as defined as = types 1 - 4 in RFC 7908: these break the valley-freeness property that = we expect to see in valid paths, but as they're accidental, they don't = do anything that BGPsec doesn't like. Note that the second feature seems impressive until you realize that = it's a feature of the internet that ALL BGP updates reach ALL ASes, and = that the source only gets to select the next hop AS, but that any ASes = after that can apply any mistaken or malicious policy that they see fit. Of course if it turns out that some of these route leaks are NOT = accidental and when we manage to stop them by validating the AS path in = non-BGPsec BGP and then the culprits start creating fake AS paths to get = around that validation, at that point BGPsec can fix that problem. But as it is today BGPsec is an unimplemented fix for unimplemented = problems. :-) :-( :-) Once we can validate paths then BGPsec will be of additional value, but = I expect that the huge overhead that it carries will never justify the = benefits. If people are leaking routes maliciously, as some people have = accused China Telecom of doing [*], then path validation even on = unprotected paths they'd have to inject fake paths to get through the = validation to keep doing that. At that point, there's really no = plausible deniability anymore. [*] = https://scholarcommons.usf.edu/cgi/viewcontent.cgi?article=3D1050&context=3D= mca= From nobody Mon Jul 1 14:18:52 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442F5120106 for ; Mon, 1 Jul 2019 14:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ITj4YTsF0gyF for ; Mon, 1 Jul 2019 14:18:49 -0700 (PDT) Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) (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 40B1B1200E7 for ; Mon, 1 Jul 2019 14:18:49 -0700 (PDT) Received: by mail-qt1-x844.google.com with SMTP id m29so16290923qtu.1 for ; Mon, 01 Jul 2019 14:18:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=X1WTb1+VmT0X8M4/BLGZ/yxIgr0e2JE5VSJy3+py4e0=; b=JKsAY5t1ipePPbpuOc4WpGs6t1fKcOje/g3n0QjqClx22XW6QiFTteV4jIWJXLnO9/ d3kcPPpGUiPqUqjlbpeeZ8Yk0WfCG95EMgc032uaGpps8u7QogeDJ0Iimhf1TwYCFeSi 0iURCPq2KQfyoujLF2CBMTGN5BoR3LBuRij0mc2MYygcGm1wVIs9v4Hv8C9ZE50Gg7gQ l1v8cl6vxswlBBqrQBoF1zJEviR/upsbnxjSBSIPBJkFdLGSIuHv3i+ep09Nv9dFBA4Y WAsy9T6/wU3Ys7hsxqASiTzSnnwtdBAhFxbXzX0mob0kcHMLwTBiqbscfRnSD8HkLLdZ YiNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=X1WTb1+VmT0X8M4/BLGZ/yxIgr0e2JE5VSJy3+py4e0=; b=A1PMn8RvfMYc2BOHYpgqfrrE3DpZbPqL44NtGZO+vI+WqEzplAYXpMiN9TRovmZWMa TEOSPoBIvPfxPtg/UEJR4qW7hjLNcMSxssE8PX9yH/Td+slr6rfknw5kihur0a6R3uFi BePCl9GzZU16kLFhYU66b/7IqLxsXotLLBJ7edOFg+RCpeh61rvHpAz83U4HJM2HbKgW wyV/pdgsTltHz4wFNyLhwMZ5j4rYZqSPC90T2n58s+9bV2763RBYJfW7EsHMRFl2P8ZV 2Vf9NPNUP1O9prpXfENZj3sbUWxiDoUHmom/Ek+jqX5LImrKURdam/Q58QoKmoxLOJvH j8ZQ== X-Gm-Message-State: APjAAAXhMcC5bDCC/HkNRVlNb/lodsa7L7STzYo2rbdINA2ysVXjjEgM 9SIBEHpAdoj5DMx8FMejObChaRrPbP765DlWbmA= X-Google-Smtp-Source: APXvYqzNYHpTxiz0VWt5MaCP7+b96cEidaZ7NOgaqw7ZgUZdbqTGXgagmp1X6BZ1HaX77d4NAoozLVYn+e/Wb+4AHcM= X-Received: by 2002:ac8:2fb7:: with SMTP id l52mr21076593qta.93.1562015928118; Mon, 01 Jul 2019 14:18:48 -0700 (PDT) MIME-Version: 1.0 References: <9D1926FB-30B0-4A28-8AAF-32527BCC2F9F@muada.com> <10331B58-4353-417B-859B-8E78EF4A9F9D@muada.com> <15E1C5FA-C511-4377-A582-3320BEBD8AAD@muada.com> In-Reply-To: <15E1C5FA-C511-4377-A582-3320BEBD8AAD@muada.com> From: Christopher Morrow Date: Mon, 1 Jul 2019 17:18:36 -0400 Message-ID: To: Iljitsch van Beijnum Cc: Alexander Azimov , SIDR Operations WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] On validating AS paths X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2019 21:18:51 -0000 On Mon, Jul 1, 2019 at 3:33 PM Iljitsch van Beijnum wr= ote: > > On 1 Jul 2019, at 20:27, Christopher Morrow wrote: > > >> Yes. Note that in my previous message I was specifically addressing va= lidating the _entire_ path, while ASPA only concerns itself with validating= the "up" part of the path, where the only valid relationships are provider= -customer and sibling-sibling. > > > isn't this the point of 'bgpsec'? meaning: "you can do this when you > > see bgpsec signed paths from bgp peers" > > Unless I'm missing something (I don't think so, but it's a complicated sy= stem so maybe I am), BGPsec gives you two things: > > 1. Signatures on all the hops in the path, so you can check that the BGP = update did traverse those routers/ASes and no others > > 2. A signature from any given AS in the path on the next hop AS, so you c= an determine that the update was propagated as intended by each previous ho= p > yup, that's bgpsec. > These features are orthogonal to the issue of route leaks as defined as t= ypes 1 - 4 in RFC 7908: these break the valley-freeness property that we ex= pect to see in valid paths, but as they're accidental, they don't do anythi= ng that BGPsec doesn't like. > ah! yes, this is the same sort of stuff sahron goldberg,. et-al wrangled in several papers over the last 10 or so years: "RPKI, SIDR, BGPSEC are nice, but you STILL have to plan to do some prefix filtering" (note that also danny mcpherson was an 'early adoptor' of this premise... "Hey, this won't stop leaks, so.. like... wtf dudes?" perhaps a tad more eloquently put by danny) > Note that the second feature seems impressive until you realize that it's= a feature of the internet that ALL BGP updates reach ALL ASes, and that th= e source only gets to select the next hop AS, but that any ASes after that = can apply any mistaken or malicious policy that they see fit. > "all" - where there isn't some policy enforcing a block/etc, or where best-path didn't cause the route to propagate. sure. > Of course if it turns out that some of these route leaks are NOT accident= al and when we manage to stop them by validating the AS path in non-BGPsec = BGP and then the culprits start creating fake AS paths to get around that v= alidation, at that point BGPsec can fix that problem. > > But as it is today BGPsec is an unimplemented fix for unimplemented probl= ems. :-) :-( :-) my guess is we don't know the shape of today's problem :( but ok. > Once we can validate paths then BGPsec will be of additional value, but I= expect that the huge overhead that it carries will never justify the benef= its. If people are leaking routes maliciously, as some people have accused = China Telecom of doing [*], then path validation even on unprotected paths = they'd have to inject fake paths to get through the validation to keep doin= g that. At that point, there's really no plausible deniability anymore. > > [*] https://scholarcommons.usf.edu/cgi/viewcontent.cgi?article=3D1050&con= text=3Dmca From nobody Tue Jul 2 03:22:42 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33566120052; Tue, 2 Jul 2019 03:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=muada.com header.b=fkxDuodX; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=V/AdIiIq 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 T19zeOAiNc_t; Tue, 2 Jul 2019 03:22:29 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 447B5120044; Tue, 2 Jul 2019 03:22:29 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 6620A471; Tue, 2 Jul 2019 06:22:28 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Tue, 02 Jul 2019 06:22:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=muada.com; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=X g4+df9HQmKBe+QApMV3Qz+CBVG1GAh9XOgqQKEfjVs=; b=fkxDuodXRsxqBk3x9 qb4Bx6FnWcn6E+uznMAOPjssNgtTq/KJQEFSG5RhxZMV3kUA7JcXf2RGHsJ7GxSb ayK4NnZJ11gC/IgEMnskH17przx5uI1MV39ncFiW1XNsK8kF8whrzwu8IoqamdUf 4dkEhpDloUfvWf9rUxh6NbowxZhWBJ+Sp2RLr8pEYKTOov04IgrGbQOuoOPoCWQL ykdC+iKhNfpyLAYNLyUMRqtOiPPaEIZYlAcJEmgMuyLeuD/MEWKOq3DSV50A10Ew usfMBtYCdzPM+v4+i//i3sgtkoSu+XGfYK4g+TUL8KzH9FjpzH8y04rVO3J08lGK S5iQg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=Xg4+df9HQmKBe+QApMV3Qz+CBVG1GAh9XOgqQKEfj Vs=; b=V/AdIiIqjitC2PYDEKArjQ+PDTUBwOshF70nbDGIsURDsulbQxIfRTIPT DOtAjkiY54x1SVRmmuFIyhKIYhEXnalTRoT+v5E8QIi2kGzHt7aU44OlsgFT7/+V FwqGIr/5teVOJR8u0RSTg6BtDj1BahLk2g5im/iIMHwOeOTYcSPXJuo5LnXu96HW UX08Hu0SNT9sDPGmCEUeSrXWEzpSNuP3P8t+iwnPGQS+rcy4oMLD+LH6e8F8atan 1W5YincXdvxIU3ZqVzFnIpwBadzLYCYmyw6j1FTzuiPhCKugKeQfPXgUiwr1NknA mJoh18AZw0Q1/CbRmhR4y2E+IvHIw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrvdekgddvlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggguffhjgffgffkfhfvofesthhqmh dthhdtvdenucfhrhhomhepkfhljhhithhstghhuchvrghnuceuvghijhhnuhhmuceoihhl jhhithhstghhsehmuhgruggrrdgtohhmqeenucfkphepkeefrdekhedrjedurdelheenuc frrghrrghmpehmrghilhhfrhhomhepihhljhhithhstghhsehmuhgruggrrdgtohhmnecu vehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from [192.168.178.17] (83-85-71-95.cable.dynamic.v4.ziggo.nl [83.85.71.95]) by mail.messagingengine.com (Postfix) with ESMTPA id 365FE80065; Tue, 2 Jul 2019 06:22:27 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Iljitsch van Beijnum In-Reply-To: Date: Tue, 2 Jul 2019 12:22:24 +0200 Cc: sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <465695D1-51CD-49A6-9126-A7125E12062F@muada.com> References: <20190528162707.GD29921@hanna.meerval.net> To: grow@ietf.org X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: [Sidrops] An alternative approach to draft-ietf-grow-route-leak-detection-mitigation X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 10:22:32 -0000 Hi all, I was made aware of this draft in sidrops, and wrote there that I don't = think it'll work because the AS in DO is overwritten with _last_ AS that = propagates a route over peering rather than the _first_ (origin) AS. = Maybe with the L thing everything will still work, but now that I see = here that the point is to make it work using existing mechanisms, I = don't see how that can happen. The community filters and route maps to = make it all work would be way too complex. Also, if you _really_ want to deploy tomorrow, don't use large = communities or extended communities, because those aren't implemented = widely enough: use regular communities. But it all comes back to this: if you see a DO, how do you know it's one = from multiple hops away that indicates a leak, rather than one from the = neighboring AS that is not problematic? My conclusion: this can't work and be deployed realistically with any = type of communities. But you know where you can stick information that will be linked to a = specific place in the AS path? In the AS path. What if we prepend all prefixes we announce to a peer with a 1, and = prepend all prefixes that we receive from a peer wit a 2. So if there's a 1 or a 2 more than one hop beyond our peer AS, we have a = leak. Adding a provider - customer indicator is left as an exercise for the = reader. The only downside that I see is that with partial deployment, certain = paths will be longer while others remain the same length for now, which = will have impact on traffic engineering. Iljitsch= From nobody Wed Jul 3 10:20:15 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 085181203C3; Wed, 3 Jul 2019 10:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 by5uPxPDOxkD; Wed, 3 Jul 2019 10:20:10 -0700 (PDT) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 582AC1203CA; Wed, 3 Jul 2019 10:20:10 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id y57so2351448qtk.4; Wed, 03 Jul 2019 10:20:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mkfFK+dPzR9gM1ZrgSCS2Jhz8CHsxU8nUkuf6XWHNko=; b=LGEQ3Ts9bLhPvcWyhBQEy8hMVGRNj360AqlP5tQ3xtxcTbX+XPFXb9jlySzL6to9Mv vQB8gIFpSrWOIwo1yTIpfB6T4cahiQ/5YWdg2lN9xG1ry/6toOy/HhxlchbJFCp8c6xB Rua+jipldNnE/DIQt7aVUkt0u2EuOtbd0TXLlRuC8Oa3A4UksvRbCps4FKSDZOeVlZJ/ i5vzBwzSUIMGZN78OxhTWvxC2pBVa6ZUJq2tJL1C+x/2Y+qwUQZJPHIzvp7UO++pdOg1 wsR6Vzagy9otPMvpO2L+cfEfIZJZq4M/xzgU/ahg1zIlAGyXLbsquPy0D+8VzC7JDFiG vHiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mkfFK+dPzR9gM1ZrgSCS2Jhz8CHsxU8nUkuf6XWHNko=; b=WsJ9DbB3XX18VVX9K8ES2fpmuDVyRtSKX6VBiGxzeTSh+9zHxN5qQTegKkWM7/1DWu civhJYV2eHnHJiaPQBONM2jj3Vxl1OMFdJJ/fFjqSt7oHnQ1FLZAOwdw+5lOpKV93Huy dwI82IB87CKe4432pjTTBar6F9QJIMDKCqzHpC6hPul9BD0K98TCrWBSa38QaUdjaYOx TgWJxPe1g7zmfkOdrY8Z4yGZjfy3DvBHOeCHNewZnyWeMI3eLRNW8bw3wnQyN37ZGELY vb5RQyMjkQ2/xdE11wSbiiBcnOT9x2XyLcKn5bJb8Kafitlc/wfF7LJknC0ZxJA0WL8h FKGw== X-Gm-Message-State: APjAAAVcC6sF66Huc5ZrcAins5KlKqWS0mFm6+elTeellw0yQdaXqZVh UB3UAF67SNB215LmD+LPECPYt/luirT7Llv8/UwnNQ== X-Google-Smtp-Source: APXvYqxJ3BqWGnjbsmHhxM4uXUes553PYW4lbQwlvT2Q2MeDUhrI85D5SEBW+SDk3UAv4wxXgUZu37temV5a3var4uw= X-Received: by 2002:ac8:30a4:: with SMTP id v33mr32274192qta.249.1562174409498; Wed, 03 Jul 2019 10:20:09 -0700 (PDT) MIME-Version: 1.0 References: <20190528162707.GD29921@hanna.meerval.net> <465695D1-51CD-49A6-9126-A7125E12062F@muada.com> In-Reply-To: <465695D1-51CD-49A6-9126-A7125E12062F@muada.com> From: Brian Dickson Date: Wed, 3 Jul 2019 10:19:58 -0700 Message-ID: To: Iljitsch van Beijnum Cc: grow@ietf.org, sidrops@ietf.org Content-Type: multipart/alternative; boundary="000000000000c165f1058cca128b" Archived-At: Subject: Re: [Sidrops] [GROW] An alternative approach to draft-ietf-grow-route-leak-detection-mitigation X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 17:20:13 -0000 --000000000000c165f1058cca128b Content-Type: text/plain; charset="UTF-8" Hi, Iljitch, The document is being revised by the authors. The rewrite of any DO will be going away as part of that, as will L. The end result will be that the Large communities (for RLP) will be a complete list of all DO ASNs (i.e. as appropriate to the topology wrt transit relationships), and nothing else new. This makes it simple, reliable, deployable, and scalable, and allows non-adjacent ASNs to identify/stop leaks (even if an intermediate ASN deliberately allows the leak to pass, for whatever reason.) (BTW: You should only ever receive DO-marked prefixes from upstream transit providers, or from a peer where the peer ASN is the only DO=N value.) Putting a first entry for blocking leaks at the top of route-maps won't interfere with any other route-map mechanics. If a route-map didn't previously exist, it will need to but consist only of the block. Route-maps for blocking will only need to be modified or created on customer and peer facing connections. Transit connections won't have the need or ability to detect leaks; this is a trade-off on simplicity, reliability, and scalability. Brian On Tue, Jul 2, 2019 at 3:22 AM Iljitsch van Beijnum wrote: > Hi all, > > I was made aware of this draft in sidrops, and wrote there that I don't > think it'll work because the AS in DO is overwritten with _last_ AS that > propagates a route over peering rather than the _first_ (origin) AS. Maybe > with the L thing everything will still work, but now that I see here that > the point is to make it work using existing mechanisms, I don't see how > that can happen. The community filters and route maps to make it all work > would be way too complex. > > Also, if you _really_ want to deploy tomorrow, don't use large communities > or extended communities, because those aren't implemented widely enough: > use regular communities. > > But it all comes back to this: if you see a DO, how do you know it's one > from multiple hops away that indicates a leak, rather than one from the > neighboring AS that is not problematic? > > My conclusion: this can't work and be deployed realistically with any type > of communities. > > But you know where you can stick information that will be linked to a > specific place in the AS path? > > In the AS path. > > What if we prepend all prefixes we announce to a peer with a 1, and > prepend all prefixes that we receive from a peer wit a 2. > > So if there's a 1 or a 2 more than one hop beyond our peer AS, we have a > leak. > > Adding a provider - customer indicator is left as an exercise for the > reader. > > The only downside that I see is that with partial deployment, certain > paths will be longer while others remain the same length for now, which > will have impact on traffic engineering. > > Iljitsch > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow > --000000000000c165f1058cca128b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Iljitch,

The document is being revi= sed by the authors.
The rewrite of any DO will be going away as p= art of that, as will L.
The end result will be that the Large com= munities (for RLP) will be a complete list of all DO ASNs (i.e. as appropri= ate to the topology wrt transit relationships), and nothing else new.
=
This makes it simple, reliable, deployable, and scalable, and allows n= on-adjacent ASNs to identify/stop leaks (even if an intermediate ASN delibe= rately allows the leak to pass, for whatever reason.)
(BTW: You s= hould only ever receive DO-marked prefixes from upstream transit providers,= or from a peer where the peer ASN is the only DO=3DN value.)
Putting a first entry for blocking leaks at the top of route-ma= ps won't interfere with any other route-map mechanics.
If a r= oute-map didn't previously exist, it will need to but consist only of t= he block.
Route-maps for blocking will only need to be modified o= r created on customer and peer facing connections.
Transit connec= tions won't have the need or ability to detect leaks; this is a trade-o= ff on simplicity, reliability, and scalability.

Br= ian

On Tue, Jul 2, 2019 at 3:22 AM Iljitsch van Beijnum <iljitsch= =3D40muada.com@dmarc.ietf.org= > wrote:
= Hi all,

I was made aware of this draft in sidrops, and wrote there that I don't= think it'll work because the AS in DO is overwritten with _last_ AS th= at propagates a route over peering rather than the _first_ (origin) AS. May= be with the L thing everything will still work, but now that I see here tha= t the point is to make it work using existing mechanisms, I don't see h= ow that can happen. The community filters and route maps to make it all wor= k would be way too complex.

Also, if you _really_ want to deploy tomorrow, don't use large communit= ies or extended communities, because those aren't implemented widely en= ough: use regular communities.

But it all comes back to this: if you see a DO, how do you know it's on= e from multiple hops away that indicates a leak, rather than one from the n= eighboring AS that is not problematic?

My conclusion: this can't work and be deployed realistically with any t= ype of communities.

But you know where you can stick information that will be linked to a speci= fic place in the AS path?

In the AS path.

What if we prepend all prefixes we announce to a peer with a 1, and prepend= all prefixes that we receive from a peer wit a 2.

So if there's a 1 or a 2 more than one hop beyond our peer AS, we have = a leak.

Adding a provider - customer indicator is left as an exercise for the reade= r.

The only downside that I see is that with partial deployment, certain paths= will be longer while others remain the same length for now, which will hav= e impact on traffic engineering.

Iljitsch
_______________________________________________
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
--000000000000c165f1058cca128b-- From nobody Thu Jul 4 14:55:40 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED9731200D8 for ; Thu, 4 Jul 2019 14:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 OiDzdYdPbWav for ; Thu, 4 Jul 2019 14:55:35 -0700 (PDT) Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (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 D873F1200C1 for ; Thu, 4 Jul 2019 14:55:34 -0700 (PDT) Received: by mail-ot1-x32c.google.com with SMTP id l15so7137777otn.9 for ; Thu, 04 Jul 2019 14:55:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VLFYucnfIBzSrnqpVuuNWuK9+uemyvgIRSGAdsCBh1I=; b=iHC4tM69fOc0MlmoXBZoqmRt/LTsrVlssZs3VDiLto2wXx1gfXxPkul2u+P2+evtis 1D3pvB2FGBXuLxZfTDoF3oAO0GeEsUPwMryKDcrFa5DuE2fhIBOjHwCLZQJPApDwD4+8 oFH7l7ONFqp0LqGLRGgkUs1Rb8qzib3HPRvAGG40wnleP8HxoTecB59Vox86eT+Y43I8 76DqZy+4Fog1z3U8J/s5oMixjGTT0F1Abmu1yPU2jGh4oag3vfPcOVWnLOsVzQEYvnZ4 qq/vMSTB31I3JybP9AWLPRegAmom9LWCadThhzldKShxUmO7vLIZywlOAweH7eWj5SoE YetA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VLFYucnfIBzSrnqpVuuNWuK9+uemyvgIRSGAdsCBh1I=; b=UXotuUbpgBxOc94RAw5qB2Q8KVAbFoBXa22crM0vPwLsBDQBYE+N4LBnNOI8clgisv WF91zMIdqHGlISytcnPW+Xd/GgQOHr20cZJuU8RkUfIqf3HWb13NHeNt95pZgHVXuDPk gODylzrIkjiomJoklS83oQI2GXqYhU1hTR70CjfVEaHuu96ZTH67NGnMQ9m8gmKpo9Sf aDT8SjGzDFdyLnhY6vP8kQxrUKWo7yoq5MU6AggQsquWQhy7SiH6Z/K2gDYwVGuI+M7o ZlUOeAGRd8C1i/W0at8BNV8FRg4mdogvbj+Rl+b98bcPUPU3qBFfd1bhHu/X0JGCpKsA h5jw== X-Gm-Message-State: APjAAAUHSxDJsqa2GrwtRLRhU4t9kBGNbgLflhVjA9eaAtLNe0FlXVIh UdV82sN8TCesqEwXOco+UCkxqeSM0fTVZj6WXs1hUnmt X-Google-Smtp-Source: APXvYqzzodpqi7mwJu4rB5ijKFwYyRJ6xfz/6p+roqPpCoodSsB8jAFA0ie7KnbV97W5QD1Y96CoEfYFpCEx3vs4/sg= X-Received: by 2002:a9d:28:: with SMTP id 37mr132563ota.289.1562277334107; Thu, 04 Jul 2019 14:55:34 -0700 (PDT) MIME-Version: 1.0 References: <9D1926FB-30B0-4A28-8AAF-32527BCC2F9F@muada.com> <10331B58-4353-417B-859B-8E78EF4A9F9D@muada.com> In-Reply-To: <10331B58-4353-417B-859B-8E78EF4A9F9D@muada.com> From: Alexander Azimov Date: Fri, 5 Jul 2019 00:55:20 +0300 Message-ID: To: Iljitsch van Beijnum Cc: sidrops@ietf.org Content-Type: multipart/alternative; boundary="0000000000008a4a16058ce209ff" Archived-At: Subject: Re: [Sidrops] On validating AS paths X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2019 21:55:38 -0000 --0000000000008a4a16058ce209ff Content-Type: text/plain; charset="UTF-8" Hi, bellow my additional comments. Just in case - I removed from quote those parts where we are on the same side. a1 ^ a2 / a3 \ a4 > > ^/\ is not a valid path. So a3 has to register its C2P relationship with > a2. > You can't enforce it. Sibling occurs not only between parties under single administrative control. And you don't want to have such kind of dependency for your security configuration. > Maybe it can be fixed by adding a sibling flag to the c2p record, but at > the moment I'm not sure about security consequences. > > > In the draft you mention that it's important that the customer can claim > the relationship and not the provider. So I would be hesitant to have a S2S > relationship record is that would either be too easy to claim (if one > sibling can do it) or complex to implement (only valid when both siblings > claim the relationship). > IMO the moment we require two (or more) independent parties synchronize their configuration without automation - we lose. My idea was to add one-side s2s (or c2c) to make it work. But I'm still not sure about this. > And to follow up my previous email, if we have a network with malicious > intent that would hijack/disaggregate prefixes + create a 'virtual peering > link' between it and victim ASN, its customers will not able to detect it > anyway since it will look like a valid path: '-\'. > > > You mean a virtual sibling link? No, we certainly don't want that to be > possible. > No. Imagine I'm an attacker (or BGP optimizer) and I want to send prefixes with a malformed path to my customer. To bypass filters based on your proposal I just need to have a 'virtual' link with the originator. If the original path was 'a1 a2 a3 attacker customer', the path 'a1 attacker customer' will be also valid. (the path is again reversed, just to keep it same to the previous email). So, if we are not speaking about BGPSec-like signatures, your approach will not protect from ASPATH violation. The thing it might bring is the detection of mistake route leaks that are received from providers. So, it can bring benefit at the state of early adoption. I will try to integrate into ASPA logic. I have a feeling that it can be done without registering siblings. -- Best regards, Alexander Azimov --0000000000008a4a16058ce209ff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, bellow my additional comments.
Just in case - = I removed from quote those parts where we are on the same side.
<= br>
a1 ^ a2 / a3 \ a4

^/\ is= not a valid path. So a3 has to register its C2P relationship with a2.
You can't enforce it. Sibling occurs not only= between parties under single administrative control.
And you don't = want to have such kind of dependency for your security configuration.
=C2=A0
<= div>
Maybe it can be fixed by add= ing a sibling flag to the c2p record, but at the moment I'm not sure ab= out security consequences.

In the= draft you mention that it's important that the customer can claim the = relationship and not the provider. So I would be hesitant to have a S2S rel= ationship record is that would either be too easy to claim (if one sibling = can do it) or complex to implement (only valid when both siblings claim the= relationship).
IMO the moment we requir= e two (or more) independent parties synchronize their configuration without= automation - we lose.=C2=A0
My idea was to add one-side s2s (or = c2c) to make it work. But I'm still not sure about this.
=C2= =A0
And to follow up my previous = email, if we have a network with malicious intent that would hijack/disaggr= egate prefixes + create a 'virtual peering link' between it and vic= tim ASN, its customers will not able to detect it anyway since it will look= like a valid path: '-\'.

You mean a virtual sibling link? No, we cert= ainly don't want that to be possible.
No. Imagine I'm an attacker (or BGP optimizer) and I want to se= nd prefixes with a malformed path to my customer.
To bypass filte= rs based on your proposal I just need to have a 'virtual' link with= the originator.

If the original path was 'a1 = a2 a3 attacker customer', the path 'a1 attacker customer' will = be also valid. (the path is again reversed, just to keep it same to the pre= vious email).

So, if we are not speaking about BGP= Sec-like signatures, your approach will not protect from ASPATH violation. =
The thing it might bring is the detection of mistake route leaks that a= re received from providers. So, it can bring benefit at the state of early = adoption.

I will try to integrate into ASPA logic. I have a feeling = that it can be done without registering siblings.

<= div>--=C2=A0
Best regards,
Al= exander Azimov
--0000000000008a4a16058ce209ff-- From nobody Sun Jul 7 08:34:49 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D235912009C for ; Sun, 7 Jul 2019 08:34:46 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains text/plain,.exe X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 KF4AeYYhW9oP for ; Sun, 7 Jul 2019 08:34:43 -0700 (PDT) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (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 A4265120058 for ; Sun, 7 Jul 2019 08:34:43 -0700 (PDT) Received: by mail-ot1-x333.google.com with SMTP id d17so13720028oth.5 for ; Sun, 07 Jul 2019 08:34:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AEfQDSBNescFjGPtRJnpKHuNM7xX/aeP4WyZP3slxKc=; b=sEGnhtN++mojcIvdNZAick9FBBrIkEhzI2FlF0Se9JPQeyDmS8+arudfBOOGOs3Wa/ hscdU4ON1GPeQL6qhtid/RjdPRqYBQS/lY2+j/EKBcHdCOXAMCSdrukZTPckDC8Cpr90 kUXNSr2e0XyUyFYZAF+h1ekNRjDwLhTSeXprS2gGhMOTucIScZSFM7wOsrPX0ejToT0a qpdPOKwWyIRRj3LG68dpfhpepdpO3f9Op/I2SYwGh89hoQzx1AacminV4K9f4FQZ9zM4 hUxyJTwyhlVMgvawQKuANYjyCYB+li90VO6HLS72Cx1NdEiBmthun9nTbfFlrOd8BdHa VTTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AEfQDSBNescFjGPtRJnpKHuNM7xX/aeP4WyZP3slxKc=; b=T14bQqU7K7Qfcd6p8dM6ia/AadgJWtcv7ig/CZUavdHbhvBjz7zUtMRyUeeA9o76ec /PyKi2t+3tS3MkBwVWieaqPVTnBj+Dhxhi2ijuteCJIqFOE7szL6gc+saek9Caj+3X8L DVwZJBxTwCJbrAH3TcPbjknsRY3Z126DZwCCPQaW2Ba0jVXzYVtMxfJV/xW52gdtFJgx fgXZKDZhV5hTEGA9+JSv4RKX24snLYRdpLTmDVtef/1t0WVe2osHNiCiAKGS40zKhd3C HhYDGsQpiw3HVl3gEu5CiOdurIRCBG/HsY+vP6TbrwriavluhW1M2AXz+x1ehNwE4xUB pJCw== X-Gm-Message-State: APjAAAWw7M3Es+To/3ZUR4ChJSlcxKg8PxI9IUhLDsK3s9Z4sKqctJeb 2jUKU1M2xZkOU+wvL0oGw7u2sezI7ZIO1EsR4xO+l9dj X-Google-Smtp-Source: APXvYqwvCV7zLs63+3WCWJR5YFesNqeSrF7kiGyronhxuoIEl8dwAQzqW5zWQK6bGhmKOSSoPLzsINFfslml1ioDPnA= X-Received: by 2002:a9d:7411:: with SMTP id n17mr9965500otk.27.1562513682945; Sun, 07 Jul 2019 08:34:42 -0700 (PDT) MIME-Version: 1.0 References: <9D1926FB-30B0-4A28-8AAF-32527BCC2F9F@muada.com> <10331B58-4353-417B-859B-8E78EF4A9F9D@muada.com> In-Reply-To: From: Alexander Azimov Date: Sun, 7 Jul 2019 18:34:31 +0300 Message-ID: To: Iljitsch van Beijnum Cc: sidrops@ietf.org Content-Type: multipart/alternative; boundary="00000000000007592b058d19113e" Archived-At: Subject: Re: [Sidrops] On validating AS paths X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2019 15:34:47 -0000 --00000000000007592b058d19113e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Here is a sample of pseudocode: def verify_aspath(local_role, reverse_aspath, neigbor_asn): > if not len(reverse_aspath) or local_role in (customer, peer, rs, > provider) and neigbor_asn !=3D reverse_aspath[0]: > return False > > if local_role in (provider, peer, rs): > for i in range(len(reverse_aspath)): > if not i or reverse_aspath[i-1] =3D=3D reverse_aspath[i]: > continue > > if verify_pair(reverse_aspath[i-1], reverse_aspath[i]) =3D=3D > invalid: > return False > elif local_role in (customer, rs_client): > going_up =3D True > for i in range(len(reverse_aspath)): > if not i or reverse_aspath[i-1] =3D=3D reverse_aspath[i]: > continue > > if going_up and verify_pair(reverse_aspath[i-1], > reverse_aspath[i]) =3D=3D invalid: > going_up =3D False > continue > > if not going_up and verify_pair(reverse_aspath[i], > reverse_aspath[i-1]) =3D=3D invalid: > return False > > return True It's slightly simplified (I ignored AS_SETs) but it shows that it is possible to add route leak detection for prefixes that are received from providers without changing ASPA profile. =D0=BF=D1=82, 5 =D0=B8=D1=8E=D0=BB. 2019 =D0=B3. =D0=B2 00:55, Alexander Az= imov : > Hi, bellow my additional comments. > Just in case - I removed from quote those parts where we are on the same > side. > > a1 ^ a2 / a3 \ a4 >> >> ^/\ is not a valid path. So a3 has to register its C2P relationship with >> a2. >> > You can't enforce it. Sibling occurs not only between parties under singl= e > administrative control. > And you don't want to have such kind of dependency for your security > configuration. > > >> Maybe it can be fixed by adding a sibling flag to the c2p record, but at >> the moment I'm not sure about security consequences. >> >> >> In the draft you mention that it's important that the customer can claim >> the relationship and not the provider. So I would be hesitant to have a = S2S >> relationship record is that would either be too easy to claim (if one >> sibling can do it) or complex to implement (only valid when both sibling= s >> claim the relationship). >> > IMO the moment we require two (or more) independent parties synchronize > their configuration without automation - we lose. > My idea was to add one-side s2s (or c2c) to make it work. But I'm still > not sure about this. > > >> And to follow up my previous email, if we have a network with malicious >> intent that would hijack/disaggregate prefixes + create a 'virtual peeri= ng >> link' between it and victim ASN, its customers will not able to detect i= t >> anyway since it will look like a valid path: '-\'. >> >> >> You mean a virtual sibling link? No, we certainly don't want that to be >> possible. >> > No. Imagine I'm an attacker (or BGP optimizer) and I want to send prefixe= s > with a malformed path to my customer. > To bypass filters based on your proposal I just need to have a 'virtual' > link with the originator. > > If the original path was 'a1 a2 a3 attacker customer', the path 'a1 > attacker customer' will be also valid. (the path is again reversed, just = to > keep it same to the previous email). > > So, if we are not speaking about BGPSec-like signatures, your approach > will not protect from ASPATH violation. > The thing it might bring is the detection of mistake route leaks that are > received from providers. So, it can bring benefit at the state of early > adoption. > > I will try to integrate into ASPA logic. I have a feeling that it can be > done without registering siblings. > > -- > Best regards, > Alexander Azimov > --=20 Best regards, Alexander Azimov --00000000000007592b058d19113e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Here is a sample of pseudocode:

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">def verify_aspath(loca= l_role, reverse_aspath, neigbor_asn):
=C2=A0 =C2=A0 if= not len(reverse_aspath) or local_role in (customer, peer, rs, provider) an= d neigbor_asn !=3D reverse_aspath[0]:
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 return False

=C2= =A0 =C2=A0 if local_role in (provider, peer, rs):
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 for i in range(len(reverse_aspath)):=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if not i or reverse_aspat= h[i-1] =3D=3D reverse_aspath[i]:
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 continue

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if verify_pair(revers= e_aspath[i-1], reverse_aspath[i]) =3D=3D invalid:
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return False
=C2=A0 =C2=A0 elif local_role in (customer, rs_client):<= /font>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 going_up =3D True=C2=A0 =C2=A0 =C2=A0 =C2=A0 for i in range(len(reverse_aspath)):
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if not i or reve= rse_aspath[i-1] =3D=3D reverse_aspath[i]:
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 continue

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if going_u= p and verify_pair(reverse_aspath[i-1], reverse_aspath[i]) =3D=3D invalid:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= going_up =3D False
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 continue

= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if not going_up and verify_pair(r= everse_aspath[i], reverse_aspath[i-1]) =3D=3D invalid:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return False

=C2=A0 =C2=A0 return True
=C2=A0
It's slightly simplified (I ignore= d AS_SETs) but it shows that it is possible to add route leak detection for= prefixes that are received from providers without changing ASPA profile.

=D0=BF=D1=82, 5 =D0=B8=D1=8E=D0=BB. 2019 =D0=B3. =D0=B2 00:55, Alex= ander Azimov <a.e.azimov@gmail.c= om>:
Hi, bellow my additional comments.
Just in case - I re= moved from quote those parts where we are on the same side.

<= /div>
a1 ^ a2 / a3 \ a4

^/\ is not= a valid path. So a3 has to register its C2P relationship with a2.
You can't enforce it. Sibling occurs not only bet= ween parties under single administrative control.
And you don't want= to have such kind of dependency for your security configuration.
= =C2=A0
Maybe it can be fixed by adding= a sibling flag to the c2p record, but at the moment I'm not sure about= security consequences.

In the dr= aft you mention that it's important that the customer can claim the rel= ationship and not the provider. So I would be hesitant to have a S2S relati= onship record is that would either be too easy to claim (if one sibling can= do it) or complex to implement (only valid when both siblings claim the re= lationship).
IMO the moment we require t= wo (or more) independent parties synchronize their configuration without au= tomation - we lose.=C2=A0
My idea was to add one-side s2s (or c2c= ) to make it work. But I'm still not sure about this.
=C2=A0<= br>
And to follow up my previous emai= l, if we have a network with malicious intent that would hijack/disaggregat= e prefixes + create a 'virtual peering link' between it and victim = ASN, its customers will not able to detect it anyway since it will look lik= e a valid path: '-\'.

You mean a virtual sibling link? No, we certai= nly don't want that to be possible.
No. Imagine I'm an attacker (or BGP optimizer) and I want to send= prefixes with a malformed path to my customer.
To bypass filters= based on your proposal I just need to have a 'virtual' link with t= he originator.

If the original path was 'a1 a2= a3 attacker customer', the path 'a1 attacker customer' will be= also valid. (the path is again reversed, just to keep it same to the previ= ous email).

So, if we are not speaking about BGPSe= c-like signatures, your approach will not protect from ASPATH violation. The thing it might bring is the detection of mistake route leaks that are= received from providers. So, it can bring benefit at the state of early ad= option.

I will try to integrate into ASPA logic. I have a feeling th= at it can be done without registering siblings.

--=C2=A0
Best regards,
Alexander Azimov


--
Best regards,
Alexander Azi= mov
--00000000000007592b058d19113e-- From nobody Mon Jul 8 06:08:47 2019 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 94F84120226; Mon, 8 Jul 2019 06:08:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <156259131243.1064.15875667074400089237@ietfa.amsl.com> Date: Mon, 08 Jul 2019 06:08:32 -0700 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-signed-tal-03.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 13:08:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIDR Operations WG of the IETF. Title : RPKI Signed Object for Trust Anchor Keys Authors : Tim Bruijnzeels Carlos Martinez Rob Austein Filename : draft-ietf-sidrops-signed-tal-03.txt Pages : 15 Date : 2019-07-08 Abstract: Trust Anchor Locators (TALs) [I-D.ietf-sidrops-https-tal] are used by Relying Parties in the RPKI to locate and validate Trust Anchor certificates used in RPKI validation. This document defines an RPKI signed object for Trust Anchor Keys (TAK), that can be used by Trust Anchors to signal their set of current keys and the location(s) of the accompanying CA certiifcates to Relying Parties, as well as changes to this set in the form of revoked keys and new keys, in order to support both planned and unplanned key rolls without impacting RPKI validation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-signed-tal/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-signed-tal-03 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-signed-tal-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-signed-tal-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 8 06:26:07 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C651B120189 for ; Mon, 8 Jul 2019 06:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl 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 vZEPq-pkOYy4 for ; Mon, 8 Jul 2019 06:26:03 -0700 (PDT) Received: from dicht.nlnetlabs.nl (open.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2792120044 for ; Mon, 8 Jul 2019 06:26:02 -0700 (PDT) Received: from yoda.fritz.box (unknown [IPv6:2001:981:4b52:1:5811:df63:8dca:2399]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id C01DF1B18A; Mon, 8 Jul 2019 15:26:00 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1562592360; bh=zKXz/bZIqGZnICxx5CfVKU+cL0O3MdBrGK/bblw5PCA=; h=Subject:From:In-Reply-To:Date:References:To; b=or+603GL4UdcgwhVEo2m5vWPMl/k0EsDPdiS6QWG43NbvkOYQVAtepXfp9M4tDyJ0 f0d1ALB8neQmC7vpANNZu5q/wyF9wcpn0iDhB/1RYnRNIlUtrrRknF5L55ggPBgJEM qt/9sFvdADnjkUYZFv31G1+25MpaCkSsoOqDOY4U= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Tim Bruijnzeels In-Reply-To: <156259131243.1064.15875667074400089237@ietfa.amsl.com> Date: Mon, 8 Jul 2019 15:25:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <156259131243.1064.15875667074400089237@ietfa.amsl.com> To: SIDR Operations WG X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-signed-tal-03.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 13:26:06 -0000 Dear WG, chairs, @chairs: I noticed this has WG last call on the datatracker. I think = this is in error and the last call was meant for https in TALs, which is = now in Auth48. @chiars: 10 minutes on the agenda? The TL;DR is: - Now using unique URIs in TAK objects to track if RPs are capable and = learn the new keys, before retiring the old (comment Wes in Bangkok). - I still plan to do an actual implementation, but I haven't had the = time yet. - This version is still a discussion document..=20 In fact.. I haven't even been able to discuss this version with my = co-authors as I needed to post before cut-off. Time permitting I would like to talk about this in Montreal for 10 = minutes. If there is no official agenda time, then I encourage anyone = interested in this to have a chat if you are going to be in Montreal. = And of course, if you care to read it and provide feedback on list that = is also greatly appreciated! Tim > On 8 Jul 2019, at 15:08, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the SIDR Operations WG of the IETF. >=20 > Title : RPKI Signed Object for Trust Anchor Keys > Authors : Tim Bruijnzeels > Carlos Martinez > Rob Austein > Filename : draft-ietf-sidrops-signed-tal-03.txt > Pages : 15 > Date : 2019-07-08 >=20 > Abstract: > Trust Anchor Locators (TALs) [I-D.ietf-sidrops-https-tal] are used = by > Relying Parties in the RPKI to locate and validate Trust Anchor > certificates used in RPKI validation. This document defines an RPKI > signed object for Trust Anchor Keys (TAK), that can be used by Trust > Anchors to signal their set of current keys and the location(s) of > the accompanying CA certiifcates to Relying Parties, as well as > changes to this set in the form of revoked keys and new keys, in > order to support both planned and unplanned key rolls without > impacting RPKI validation. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidrops-signed-tal/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-sidrops-signed-tal-03 > https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-signed-tal-03 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidrops-signed-tal-03 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Mon Jul 8 13:24:24 2019 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B4A26120296; Mon, 8 Jul 2019 13:24:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <156261745169.795.2065451040259760356@ietfa.amsl.com> Date: Mon, 08 Jul 2019 13:24:11 -0700 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-aspa-verification-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 20:24:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIDR Operations WG of the IETF. Title : Verification of AS_PATH Using the Resource Certificate Public Key Infrastructure and Autonomous System Provider Authorization Authors : Alexander Azimov Eugene Bogomazov Keyur Patel Job Snijders Filename : draft-ietf-sidrops-aspa-verification-01.txt Pages : 10 Date : 2019-07-08 Abstract: This document defines the semantics of an Autonomous System Provider Authorization object in the Resource Public Key Infrastructure to verify the AS_PATH attribute of routes advertised in the Border Gateway Protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-verification/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-aspa-verification-01 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-verification-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-aspa-verification-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 9 06:36:47 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 055B7120164 for ; Tue, 9 Jul 2019 06:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=muada.com header.b=KhnQ/yjo; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XXpldYbn 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 bfCsENt60nPP for ; Tue, 9 Jul 2019 06:36:41 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C5CB120157 for ; Tue, 9 Jul 2019 06:36:41 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 8B06020E89; Tue, 9 Jul 2019 09:36:40 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Tue, 09 Jul 2019 09:36:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=muada.com; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm3; bh=nNzoqzYSdCP1dYNqXiXppoX CudSgRe+BJUW96SZl3bs=; b=KhnQ/yjos7g0xCpBwRTwUlOkL+RRARwCiqSl+8M ODlj8s/39M1C91bgFTKpceS3h8J8zMDWBsDLDw2cPG9DY4qDSDPMV+7e9mrRJd5o jVHwFL4EORbKnOSWs0nryIh6e5E8DXjeE2ZkNsPS/wVLktrzFXsycGdlGgsiw7ku 0kbtW8hwouBwTYab0642+hCSfrDrhL4yeeltLkv0LAh7remKYko0PKimB6hoZpw0 +lNbvxe8kiZ5ScKswhGhO9IkGw7JgCo5AJH0jmIJfvaFrfeqTIde9GEv6/RbDmEi CwOZOh2gKzOUu5O8mXkd/hI3bpHcuXWQmkzujCX/B0AvH4g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=nNzoqz YSdCP1dYNqXiXppoXCudSgRe+BJUW96SZl3bs=; b=XXpldYbnrS3+yhcnj62mDs R6pmSBig+umjzQC2G1xbnvO3JrW8SVXjfAxKjnSrbZCo9M5eGkbPnxUDd600m/od q7wxD5oaMvjUd4zAG+kO8kO9LlpEOJztQUKIcs/9v6atld9IYDHfB1WWXMaythob 9DvK8MGFkEJ9xVWmRO66t4mj1mlvcM+2uZ0NvXtb1fbFgU8TecrEoN49yH/1bUb7 VBIxAhr3gbiKSNUWOd0ckc/nK1o5VxmRWq2AfcqWYlFvmg2yQbyQ0FigaX+9M13a ox5auVXR65D9IlKvq1hb6kyHWc4OKL4KmpzOlhLZWDBvtJ0hf40KXuPkloxUv/dA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrgedvgdejtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhkfgtggfuffgjvfhfofesrgdtmherhhdtvdenucfhrhhomhepkfhljhhithhs tghhuchvrghnuceuvghijhhnuhhmuceoihhljhhithhstghhsehmuhgruggrrdgtohhmqe enucfkphepkeefrdekhedrjedurdelheenucfrrghrrghmpehmrghilhhfrhhomhepihhl jhhithhstghhsehmuhgruggrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from [192.168.178.17] (83-85-71-95.cable.dynamic.v4.ziggo.nl [83.85.71.95]) by mail.messagingengine.com (Postfix) with ESMTPA id 3B8C4380084; Tue, 9 Jul 2019 09:36:39 -0400 (EDT) From: Iljitsch van Beijnum Message-Id: <7ACD9CEF-21F5-47FD-9737-C020365071F4@muada.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_ABB37B29-B494-421A-8AAD-51A173353CC0" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 9 Jul 2019 15:36:36 +0200 In-Reply-To: Cc: sidrops@ietf.org To: Alexander Azimov References: <9D1926FB-30B0-4A28-8AAF-32527BCC2F9F@muada.com> <10331B58-4353-417B-859B-8E78EF4A9F9D@muada.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Sidrops] On validating AS paths X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 13:36:45 -0000 --Apple-Mail=_ABB37B29-B494-421A-8AAD-51A173353CC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Alexander, On 4 Jul 2019, at 23:55, Alexander Azimov wrote: > Hi, bellow my additional comments. > Just in case - I removed from quote those parts where we are on the = same side. :-) > a1 ^ a2 / a3 \ a4 >=20 > ^/\ is not a valid path. So a3 has to register its C2P relationship = with a2. > You can't enforce it. Sibling occurs not only between parties under = single administrative control. > And you don't want to have such kind of dependency for your security = configuration. Not sure what you mean... =20 >> Maybe it can be fixed by adding a sibling flag to the c2p record, but = at the moment I'm not sure about security consequences. >=20 > In the draft you mention that it's important that the customer can = claim the relationship and not the provider. So I would be hesitant to = have a S2S relationship record is that would either be too easy to claim = (if one sibling can do it) or complex to implement (only valid when both = siblings claim the relationship). > IMO the moment we require two (or more) independent parties = synchronize their configuration without automation - we lose.=20 Well, yes, life without automation is hard. But then again, not = everything is about making life easy. In this case, if two ASes disagree about their relationship, then we = have a problem. The only question is how the problem manifests itself. = Today, too often it manifests itself as a route leak. We want to stop = that. Assuming we can't magically make the disagreeing about the relationship = disappear, this means the problem must be pushed elsewhere. I.e., rather = than adopt the most optimistic interpretation (allowing all prefixes = allowed by _one_ AS) we should adopt a more pessimistic interpretation = (only the prefixes allowed by _both_ ASes) or maybe even the most = pessimistic interpretation (no prefixes allowed through unless there is = agreement). > My idea was to add one-side s2s (or c2c) to make it work. But I'm = still not sure about this. I don't think we have to do anything special. Assume AS1 and AS2, these = are the possibilities: AS1->AS2 AS2->AS1 Relationship claim claim C2P - AS1 =3D customer, AS2 =3D provider - C2P AS1 =3D provider, AS2 =3D customer - - AS1 and AS2 are peers C2P C2P AS1 and AS2 are siblings So by overclaiming a peer can upgrade to a customer relationship or a = provider to a sibling relationship. However, this is relatively harmless as the outgoing filters that a peer = uses towards a peer are the same as a customer uses towards a provider, = and the same for provider to customer and sibling to sibling. So as long as each AS independently determines its relationship with = other ASes and sets up filtering accordingly, C2P overclaiming is not = problematic. Of course incorrect C2P claims by one AS combined with incorrect filters = by the next AS will still result in a route leak. But at least two = incorrect actions by two different organizations are now required. As a result, it's imperative that we don't use automation to propagate = the relationship information from a single mistaken source. If fact, I would go as far as to depeer any peer who registers an = incorrect C2P claim. >> And to follow up my previous email, if we have a network with = malicious intent that would hijack/disaggregate prefixes + create a = 'virtual peering link' between it and victim ASN, its customers will not = able to detect it anyway since it will look like a valid path: '-\'. >=20 >=20 > You mean a virtual sibling link? No, we certainly don't want that to = be possible. > No. Imagine I'm an attacker (or BGP optimizer) and I want to send = prefixes with a malformed path to my customer. > To bypass filters based on your proposal I just need to have a = 'virtual' link with the originator. Hm, that sounds like the logic that gave us SSL inspection. It would be better to turn off path validation if you know there is = going to be manipulation of the AS path. > If the original path was 'a1 a2 a3 attacker customer', the path 'a1 = attacker customer' will be also valid. (the path is again reversed, just = to keep it same to the previous email). Yes, in the sense that if the path "a1 a2 a3 attacker customer" is = considered a valid path, then the mechanism I propose will also allow = "a1 attacker customer". However, I don't think that that makes a difference here, as surely = customer hasn't registered attacker as a valid transit AS. If attacker = is not a valid provider, then both paths above, the long one as well as = the short one, will be rejected. The more problematic situation is the one where a1 peers with attacker, = and attacker now sends the AS path "a1 a2 a3 customer". RFC 4271 only = suggests that an implementation MAY want to check whether the left most = AS in the path matches the AS of the BGP neighbor. Cisco does this by default, hence you need to configure "no bgp = enforce-fist-as" on Cisco routers when you peer with a route server that = doesn't add its own AS to the AS path. Juniper routers don't perform = this check by default but can be configured to do so. Extreme doesn't = have a configuration option for this so I assume they don't perform the = check. Of course when attacker sets up peering (or a customer relationship) = with a1, it can claim to have AS a2 and thus circumvent the checks done = by the routers. > So, if we are not speaking about BGPSec-like signatures, your approach = will not protect from ASPATH violation.=20 Yes. When we have figured out how to validate paths, we still have some = work to do to make sure those paths are not faked. Iljitsch= --Apple-Mail=_ABB37B29-B494-421A-8AAD-51A173353CC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Alexander,

On 4 Jul = 2019, at 23:55, Alexander Azimov <a.e.azimov@gmail.com> wrote:

Hi,= bellow my additional comments.
Just in case - I removed = from quote those parts where we are on the same = side.

:-)

a1 ^ a2 / a3 \ a4

^/\ is not a valid path. So a3 has to = register its C2P relationship with a2.
You = can't enforce it. Sibling occurs not only between parties under single = administrative control.
And you don't want to have such = kind of dependency for your security configuration.

Not sure what you = mean...
 
Maybe it can be fixed by adding a sibling flag to the c2p = record, but at the moment I'm not sure about security consequences.

In the draft you mention that it's important that the = customer can claim the relationship and not the provider. So I would be = hesitant to have a S2S relationship record is that would either be too = easy to claim (if one sibling can do it) or complex to implement (only = valid when both siblings claim the = relationship).

IMO = the moment we require two (or more) independent parties synchronize = their configuration without automation - we = lose. 

Well, yes, life without automation is hard. But = then again, not everything is about making life easy.

In this case, if two ASes disagree about their = relationship, then we have a problem. The only question is how the = problem manifests itself. Today, too often it manifests itself as a = route leak. We want to stop that.

Assuming we can't magically make the disagreeing = about the relationship disappear, this means the problem must be pushed = elsewhere. I.e., rather than adopt the most optimistic interpretation = (allowing all prefixes allowed by _one_ AS) we should adopt a more = pessimistic interpretation (only the prefixes allowed by _both_ ASes) or = maybe even the most pessimistic interpretation (no prefixes allowed = through unless there is agreement).

My idea was to add one-side s2s = (or c2c) to make it work. But I'm still not sure about = this.

I= don't think we have to do anything special. Assume AS1 and AS2, these = are the possibilities:

AS1->AS2 =    AS2->AS1   =  Relationship
 claim       = claim

  C2P       =    -        AS1 =3D customer, AS2 =3D = provider
   -          C2P =       AS1 =3D provider, AS2 =3D customer
   -           -   =      AS1 and AS2 are peers
  C2P         C2P     =   AS1 and AS2 are = siblings

So by = overclaiming a peer can upgrade to a customer relationship or a provider = to a sibling relationship.

However, = this is relatively harmless as the outgoing filters that a peer uses = towards a peer are the same as a customer uses towards a provider, and = the same for provider to customer and sibling to sibling.

So as long as each AS independently determines its = relationship with other ASes and sets up filtering accordingly, C2P = overclaiming is not problematic.

Of = course incorrect C2P claims by one AS combined with incorrect filters by = the next AS will still result in a route leak. But at least two = incorrect actions by two different organizations are now = required.

As a result, it's = imperative that we don't use automation to propagate the relationship = information from a single mistaken source.

If fact, I would go as far as to depeer any peer = who registers an incorrect C2P claim.

And to follow up my previous email, if we = have a network with malicious intent that would hijack/disaggregate = prefixes + create a 'virtual peering link' between it and victim ASN, = its customers will not able to detect it anyway since it will look like = a valid path: '-\'.

You mean a virtual sibling link? No, we certainly don't want = that to be = possible.

No. Imagine I'm an attacker (or BGP optimizer) and I want to = send prefixes with a malformed path to my customer.
To bypass filters based on your proposal I just need to have = a 'virtual' link with the = originator.

Hm, that sounds like the logic that gave us SSL = inspection.

It would be better to = turn off path validation if you know there is going to be manipulation = of the AS path.

If the original path was 'a1 a2 a3 = attacker customer', the path 'a1 attacker customer' will be also valid. = (the path is again reversed, just to keep it same to the previous = email).

Yes, in the sense that if the path "a1 a2 a3 = attacker customer" is considered a valid path, then the mechanism I = propose will also allow "a1 attacker customer".

However, I don't think that that makes a = difference here, as surely customer hasn't registered attacker as a = valid transit AS. If attacker is not a valid provider, then both paths = above, the long one as well as the short one, will be = rejected.

The more problematic = situation is the one where a1 peers with attacker, and attacker now = sends the AS path "a1 a2 a3 customer". RFC 4271 only suggests that an = implementation MAY want to check whether the left most AS in the path = matches the AS of the BGP neighbor.

Cisco does this by default, hence you need to = configure "no bgp enforce-fist-as" on Cisco routers when you peer with a = route server that doesn't add its own AS to the AS path. Juniper routers = don't perform this check by default but can be configured to do so. = Extreme doesn't have a configuration option for this so I assume they = don't perform the check.

Of course = when attacker sets up peering (or a customer relationship) with a1, it = can claim to have AS a2 and thus circumvent the checks done by the = routers.

So, if we are not speaking about BGPSec-like signatures, your = approach will not protect from ASPATH violation. 

Yes. When we have figured out how to validate = paths, we still have some work to do to make sure those paths are not = faked.

Iljitsch
= --Apple-Mail=_ABB37B29-B494-421A-8AAD-51A173353CC0-- From nobody Tue Jul 9 08:15:02 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C787F120165; Tue, 9 Jul 2019 08:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=muada.com header.b=LaQmPAwg; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VhM8fv5n 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 6JXcjHIoxW-k; Tue, 9 Jul 2019 08:14:55 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4382212023C; Tue, 9 Jul 2019 08:14:54 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 47F04218BB; Tue, 9 Jul 2019 11:14:53 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Tue, 09 Jul 2019 11:14:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=muada.com; h= from:content-type:mime-version:subject:date:references:to :in-reply-to:message-id; s=fm3; bh=jrAmQzX5UfMDGLwfc6x+6fCvSMuI6 lvplfiPjuUC2HI=; b=LaQmPAwgdwzdw3NeaC4l25XRYcQTjtQBLnUSzsUEEYTFd cyRZ9UJtLGqBkJZtHmR2xJL1XaHfnVbacwvaPYXCkT7Y5O30hD7K9d0gnDFMehdI 5ae9euJJRPafl5mkEFivLH5mDuQBPKPiJrceAq7yJnTqqsnLnQ7yRSUmH2sXCOQO 2P6IXNvQ0aNJfKKLGzZf5ep7Rj7oTuedF0kLdgZEnV8DJXpKO5j+OCL2kw26VW/i 1JNLTadspztjEkwlixRiLNONyhI3enTr9hT68vC0W+Bq4CA5lQtRjqpbspgN+jxE IXCTJkLmsTRcWjSyUmLBKtknwNFDyC8PpAjszyJBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=jrAmQz X5UfMDGLwfc6x+6fCvSMuI6lvplfiPjuUC2HI=; b=VhM8fv5nvTEAT/ZpWii0f9 TwDAOPkc2DdW2LccfuvGs2MUcL6q4MqqfyllVo0tZv8BLtZOcgu+jTX0cmMlykY/ EbOvI9ADYGzYp2XTW2uF4SyBo951/Je9v+bbKgbNhRFTPP12ZrlUPvEaoDS//KSE 0Tg9bgd5DsUd30Rp10aWKyHn39XtVDfJK8NaMhwlhYqhHxOX5nHnprPtjGqo/ibu BtDRP55vA0jme8Rpf2uXzOhblpoiMxC6wcq1li57yFEiEf3sUZx6XimFgOatg7dK epNvd/G1OKG8Rss1Kf0Wlo/Ep8Yw+jtAKwMaesBhaZaAPPTpNXKMXho7Aay47vHw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrgedvgdeltdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhephfgtggfuffhfvfgjkffosegrtdhmre hhtddvnecuhfhrohhmpefklhhjihhtshgthhcuvhgrnhcuuegvihhjnhhumhcuoehilhhj ihhtshgthhesmhhurggurgdrtghomheqnecukfhppeekfedrkeehrdejuddrleehnecurf grrhgrmhepmhgrihhlfhhrohhmpehilhhjihhtshgthhesmhhurggurgdrtghomhenucev lhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from [192.168.178.17] (83-85-71-95.cable.dynamic.v4.ziggo.nl [83.85.71.95]) by mail.messagingengine.com (Postfix) with ESMTPA id 4589C380076; Tue, 9 Jul 2019 11:14:52 -0400 (EDT) From: Iljitsch van Beijnum Content-Type: multipart/alternative; boundary="Apple-Mail=_2EBB6D47-F9BA-4C4B-88ED-E91D42B03DB4" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 9 Jul 2019 17:14:49 +0200 References: <9D1926FB-30B0-4A28-8AAF-32527BCC2F9F@muada.com> To: sidrops@ietf.org, grow@ietf.org In-Reply-To: <9D1926FB-30B0-4A28-8AAF-32527BCC2F9F@muada.com> Message-Id: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [Sidrops] Different path validation options X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 15:14:59 -0000 --Apple-Mail=_2EBB6D47-F9BA-4C4B-88ED-E91D42B03DB4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii There are now four drafts about AS path validation to remedy routing = leaks that I'm aware of: LDM: draft-ietf-grow-route-leak-detection-mitigation ASPA: draft-ietf-sidrops-aspa-verification ASCones: draft-ietf-grow-rpki-as-cones PathRPKI: draft-van-beijnum-sidrops-pathrpki The TL;DR on the four: LDM Add in-band information to BGP that signals that a peer-peer hop has = been traversed to avoid having two peer-peer hops. The idea is to do = this without new code, at first at least. As the checks must thus be = implemented with existing policy options, those will probably be easy to = implement in code on the routers later. ASPA Register customer-to-provider (C2P) relationships with extensions to = RPKI. Based on this, check the upstream and downstream parts of the AS = path, making sure there are no valleyfreeness violations and that if the = customer in the relationship between two ASes has registered a set of = provider ASes, the upstream AS is indeed one of the registered = providers. If not, then the path is considered invalid. The hop between the upstream and downstream parts of the path may be an = unregistered hop; peer relationships are not registered and in this part = of the path any relationship is a valid one anyway. If there are = additional unregistered relationships in the path, validation is not = possible and the path is considered valid. ASCones Register provider-to-customer (P2C) relationships with extensions to = RPKI. Recursively collect this information to resolve all ASes that may = be visible behind a given AS. Then do a reverse lookup in the ROA = database to obtain all the prefixes that are authorized to be advertised = by these ASes and generate a prefix filter that can be applied to a BGP = neighbor. Unclear what happens to prefixes that aren't included in the filter = because of a missing AS-Cone (P2C record) or ROA. PathRPKI The RPKI ROA format is extended to include a set of authorized transit = ASes in the upstream part of the path. Authorized ASes in the downstream = part of the path are known through local configuration. For each prefix, = the two halves of the path are combined into a list of ASes that may = appear in the AS path. These paths are sent to routers using an extended version of the RPKI to = router protocol. Routers mark a prefix as invalid if the origin AS = doesn't match as usual, and if an extended list of ASes is present, if = there are ASes in the BGP AS path that are not in the filter list (or = appear in the wrong order). So let's compare. In-band vs out-of-band LDM is the only mechanism that works in-band. In-band is inherently less = effective because the same issues that create a route leak in the first = place may also send incorrect in-band information. Deployment LDM: although it was supposed to be easy to deploy, discussion has been = going on for four years, and in my opinion, as per my earlier email = about the draft, deployment issues haven't been solved at this time. ASPA, ASCone and PathRPKI all require changes in the RIR RPKI front- and = backends and the RPKI relying party software implementations. ASPA: requires unspecified changes to the RPKI to router protocol to = convey C2P records, and for routers to implement the validation logic. = (Maybe this is not necessary, but this is my best guess at this time.) = If so, that may take considerable time and subsequent updates to the = filtering logic will be difficult because of the slow update cycle in = routers. Lack of an "unknown" validation state with partial deployment = may be problematic. ASCone: generating router filters to be included in configurations is = easy to deploy, but very clumsy. Not clear how reusing the RPKI to = router protocol would work. Unclear what partial deployment would look = like. PathRPKI: changes to RPKI to router protocol necessary. However, the = scope of these changes is small. Good partial deployment as each = combination of origin AS and destination AS is immediately protected = agains route leaks even if ASes in the middle don't implement PathRPKI. Who is involved LDM: transit ASes. Leaf ASes that don't peer have no actions. ASPA: All ASes. Origin ASes and transit ASes that have transit ASes of = their own register C2P records. All other ASes filter based on this, = most notably ASes that peer. ASCone: Transit ASes register P2C records, ASes that peer filter based = on this. Leaf ASes that don't peer have no actions. PathRPKI: origin AS registers authorized transit ASes. No specific = actions for transit ASes. ASes in the downstream part of the path filter = based on this. Security LDM: relatively low, as a malicious AS could modify the in-band = information. ASCone: middle, as ASes can incorrectly claim a P2C relationship with no = obvious recourse for the AS that is incorrectly labeled as a customer. ASPA: high, as only customers claim the customer-provider relationship. PathRPKI: a little higher, as the upstream part of the path is solely = determined by the origin AS (however, at the cost of flexibility as = transit relationship changes further upstream now require work by all = the ASes downstream of the change) What now? There are some good ideas here, but it sure looks like we haven't = figured out the best way to attack this problem. Publish four RFCs, = throw them to the wall, see what sticks? Hopefully we can come up with a = better process than that. Iljitsch= --Apple-Mail=_2EBB6D47-F9BA-4C4B-88ED-E91D42B03DB4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
There = are now four drafts about AS path validation to remedy routing leaks = that I'm aware of:

LDM: = draft-ietf-grow-route-leak-detection-mitigation
ASPA: = draft-ietf-sidrops-aspa-verification
ASCones: = draft-ietf-grow-rpki-as-cones
PathRPKI: draft-van-beijnum-sidrops-pathrpki
The TL;DR on the four:

LDM

Add in-band information = to BGP that signals that a peer-peer hop has been traversed to avoid = having two peer-peer hops. The idea is to do this without new code, at = first at least. As the checks must thus be implemented with existing = policy options, those will probably be easy to implement in code on the = routers later.

ASPA

Register customer-to-provider (C2P) relationships with = extensions to RPKI. Based on this, check the upstream and downstream = parts of the AS path, making sure there are no valleyfreeness violations = and that if the customer in the relationship between two ASes has = registered a set of provider ASes, the upstream AS is indeed one of the = registered providers. If not, then the path is considered = invalid.

The = hop between the upstream and downstream parts of the path may be an = unregistered hop; peer relationships are not registered and in this part = of the path any relationship is a valid one anyway. If there are = additional unregistered relationships in the path, validation is not = possible and the path is considered valid.

ASCones

Register provider-to-customer (P2C) = relationships with extensions to RPKI. Recursively collect this = information to resolve all ASes that may be visible behind a given AS. = Then do a reverse lookup in the ROA database to obtain all the prefixes = that are authorized to be advertised by these ASes and generate a prefix = filter that can be applied to a BGP neighbor.

Unclear what happens to prefixes that = aren't included in the filter because of a missing AS-Cone (P2C record) = or ROA.

PathRPKI

The RPKI ROA format is extended to include a set of = authorized transit ASes in the upstream part of the path. Authorized = ASes in the downstream part of the path are known through local = configuration. For each prefix, the two halves of the path are combined = into a list of ASes that may appear in the AS path.

These paths are sent to = routers using an extended version of the RPKI to router protocol. = Routers mark a prefix as invalid if the origin AS doesn't match as = usual, and if an extended list of ASes is present, if there are ASes in = the BGP AS path that are not in the filter list (or appear in the wrong = order).

So = let's compare.

In-band vs out-of-band

LDM is the only mechanism that works = in-band. In-band is inherently less effective because the same issues = that create a route leak in the first place may also send incorrect = in-band information.

Deployment

LDM: although it was supposed to be easy to deploy, = discussion has been going on for four years, and in my opinion, as per = my earlier email about the draft, deployment issues haven't been solved = at this time.

ASPA, ASCone and PathRPKI all require changes in the RIR RPKI = front- and backends and the RPKI relying party software = implementations.

ASPA: requires unspecified changes to the RPKI to router = protocol to convey C2P records, and for routers to implement the = validation logic. (Maybe this is not necessary, but this is my best = guess at this time.) If so, that may take considerable time and = subsequent updates to the filtering logic will be difficult because of = the slow update cycle in routers. Lack of an "unknown" validation state = with partial deployment may be problematic.

ASCone: generating router filters to be = included in configurations is easy to deploy, but very clumsy. Not clear = how reusing the RPKI to router protocol would work. Unclear what partial = deployment would look like.

PathRPKI: changes to RPKI to router protocol necessary. = However, the scope of these changes is small. Good partial deployment as = each combination of origin AS and destination AS is immediately = protected agains route leaks even if ASes in the middle don't implement = PathRPKI.

Who = is involved

LDM:= transit ASes. Leaf ASes that don't peer have no actions.

ASPA: All ASes. Origin = ASes and transit ASes that have transit ASes of their own register C2P = records. All other ASes filter based on this, most notably ASes that = peer.

ASCone: = Transit ASes register P2C records, ASes that peer filter based on this. = Leaf ASes that don't peer have no actions.

PathRPKI: origin AS registers = authorized transit ASes. No specific actions for transit ASes. ASes in = the downstream part of the path filter based on this.

Security

LDM: relatively low, as = a malicious AS could modify the in-band information.

ASCone: middle, as ASes = can incorrectly claim a P2C relationship with no obvious recourse for = the AS that is incorrectly labeled as a customer.
ASPA: high, as only customers claim = the customer-provider relationship.

PathRPKI: a little higher, as the = upstream part of the path is solely determined by the origin AS = (however, at the cost of flexibility as transit relationship changes = further upstream now require work by all the ASes downstream of the = change)

What = now?

There are = some good ideas here, but it sure looks like we haven't figured out the = best way to attack this problem. Publish four RFCs, throw them to the = wall, see what sticks? Hopefully we can come up with a better process = than that.

Iljitsch
= --Apple-Mail=_2EBB6D47-F9BA-4C4B-88ED-E91D42B03DB4-- From nobody Tue Jul 9 10:08:43 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30EDC1207CF; Tue, 9 Jul 2019 10:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.602 X-Spam-Level: X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, TRACKER_ID=0.1, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 vDRQcbRguAep; Tue, 9 Jul 2019 10:08:31 -0700 (PDT) Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (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 AAABD1207C2; Tue, 9 Jul 2019 10:08:31 -0700 (PDT) Received: by mail-ua1-x936.google.com with SMTP id 34so6689496uar.8; Tue, 09 Jul 2019 10:08:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oirdonexy3KunBxTMFImz0bvkb6w5dePIxU2VBxA9W0=; b=htIiimazb8Nib9x5bZFztjZYQEsrZPZNwcODRch9eH5b3x5qAwUNP0OWYa6ZDvAN+4 BT0AS6sgBlJ5NrAff974StCdHB5xtnYUukWL8nybxUgWJdI4WZn39YT5jLpytWSFznaq rqjtK5bInqJN8HawgdJzUwbmg32uvADbtDNNKQyhfjK2h/T1wnSQEuH2cM8EaUbDHUxH LmbVHYuwCIkiIWqVWkFYo12w+4NnzZIDy0p0NpPwrgIPI3EWragxhibmt1kBZZ9Ca0/+ oJe7xt3dUx4YPdZnXMbS9C3hAswYRJBrTLD8GFeycAgnob98j/UweutNxZzW7FMUXbjp snMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oirdonexy3KunBxTMFImz0bvkb6w5dePIxU2VBxA9W0=; b=aRuEGsiefKddegp+8icmQXsDNDnu9TANSJxJQBuQA+Slibk6PfamuyIafqFKfLR3oq XDkbJDhs6UMCP4Sj/lIk7HVuJ+nR7wIf+y7P9K8YxE00jQsnovipK3g0DDsuzp/BaHlc 0NKZnBuLzQ7qsI6KsMRcCzolFAHfKXJdjFiU2E28XIuahf4loOgUvks962CwdJz2zCyc 6zYkFEXB5mv4mambH6O8Q6ImGG9zy5L/dZFRr786eAkmqyTm9+WKfSkq/0fK26S6szHA rME1Hh0fI8ZfW1Y4aK4vFUPyEy96IuMZ83ohbX96e3ZKwz7ADvhI8z7EL8cNgv6OmsKZ lLFQ== X-Gm-Message-State: APjAAAWnFxk3pFvJlZCvfige56bQ7K4JkRboWOyzyKbhrMVWPj3PkkZA pqnsBZ8dBiU9+YzLcwZT+xm3tEzypMJ6vFQ7p2o= X-Google-Smtp-Source: APXvYqyGNNetVyuYwzYzaLmXkdwe50l7yUD5NNUvOcPLggEFXivmYlGCvhtdQZN+vqCBPJEWNtEshVAgD0wkMFbV4KI= X-Received: by 2002:ab0:6390:: with SMTP id y16mr5552571uao.62.1562692110507; Tue, 09 Jul 2019 10:08:30 -0700 (PDT) MIME-Version: 1.0 References: <9D1926FB-30B0-4A28-8AAF-32527BCC2F9F@muada.com> In-Reply-To: From: Brian Dickson Date: Tue, 9 Jul 2019 10:08:19 -0700 Message-ID: To: Iljitsch van Beijnum Cc: sidrops@ietf.org, grow@ietf.org Content-Type: multipart/alternative; boundary="00000000000023e34e058d429c07" Archived-At: Subject: Re: [Sidrops] [GROW] Different path validation options X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 17:08:34 -0000 --00000000000023e34e058d429c07 Content-Type: text/plain; charset="UTF-8" Minor clarifications/comments inline about LDM. On Tue, Jul 9, 2019 at 8:15 AM Iljitsch van Beijnum wrote: > There are now four drafts about AS path validation to remedy routing leaks > that I'm aware of: > > LDM: draft-ietf-grow-route-leak-detection-mitigation > ASPA: draft-ietf-sidrops-aspa-verification > ASCones: draft-ietf-grow-rpki-as-cones > PathRPKI: draft-van-beijnum-sidrops-pathrpki > > The TL;DR on the four: > > LDM > > Add in-band information to BGP that signals that a peer-peer hop has been > traversed to avoid having two peer-peer hops. The idea is to do this > without new code, at first at least. As the checks must thus be implemented > with existing policy options, those will probably be easy to implement in > code on the routers later. > LDM marks prefixes in-band, on peer-to-peer AND on transit-to-customer (assuming at least one party is doing LDM.) LDM checks prefixes in-band upon receipt, on peer-to-peer AND on customer-to-transit (assuming recipient is doing LDM.) This prevents all of the major leak paths: transit-customer-peer transit-customer-transit peer-peer-transit peer-peer-peer The marking is propagated if large communities are being sent, so even if intermediate networks involved don't mark or check, the leakage is still detectable under many scenarios. > > ASPA > > Register customer-to-provider (C2P) relationships with extensions to RPKI. > Based on this, check the upstream and downstream parts of the AS path, > making sure there are no valleyfreeness violations and that if the customer > in the relationship between two ASes has registered a set of provider ASes, > the upstream AS is indeed one of the registered providers. If not, then the > path is considered invalid. > > The hop between the upstream and downstream parts of the path may be an > unregistered hop; peer relationships are not registered and in this part of > the path any relationship is a valid one anyway. If there are additional > unregistered relationships in the path, validation is not possible and the > path is considered valid. > > ASCones > > Register provider-to-customer (P2C) relationships with extensions to RPKI. > Recursively collect this information to resolve all ASes that may be > visible behind a given AS. Then do a reverse lookup in the ROA database to > obtain all the prefixes that are authorized to be advertised by these ASes > and generate a prefix filter that can be applied to a BGP neighbor. > > Unclear what happens to prefixes that aren't included in the filter > because of a missing AS-Cone (P2C record) or ROA. > > PathRPKI > > The RPKI ROA format is extended to include a set of authorized transit > ASes in the upstream part of the path. Authorized ASes in the downstream > part of the path are known through local configuration. For each prefix, > the two halves of the path are combined into a list of ASes that may appear > in the AS path. > > These paths are sent to routers using an extended version of the RPKI to > router protocol. Routers mark a prefix as invalid if the origin AS doesn't > match as usual, and if an extended list of ASes is present, if there are > ASes in the BGP AS path that are not in the filter list (or appear in the > wrong order). > > So let's compare. > > In-band vs out-of-band > > LDM is the only mechanism that works in-band. In-band is inherently less > effective because the same issues that create a route leak in the first > place may also send incorrect in-band information. > "send incorrect in-band information" is limited (in the latest draft) to only "fails to send in-band information". The only incorrect in-band information that would have any effect is if the peer-peer marking uses the wrong ASN, at which point the recipient will block the incoming announcements. I.e. it will treat that error as a leak. Failure to mark, or failure to check, looks exactly the same as not participating, and is no worse. > > Deployment > > LDM: although it was supposed to be easy to deploy, discussion has been > going on for four years, and in my opinion, as per my earlier email about > the draft, deployment issues haven't been solved at this time. > The finalized versions are being discussed among the authors and will be discussed at the Montreal meeting. Modulo uptake by providers, I believe we are crossing the threshold to actual deployment, at which point this is entirely in the hands of the operators. We can lead them to water, but cannot make them drink. > > ASPA, ASCone and PathRPKI all require changes in the RIR RPKI front- and > backends and the RPKI relying party software implementations. > > ASPA: requires unspecified changes to the RPKI to router protocol to > convey C2P records, and for routers to implement the validation logic. > (Maybe this is not necessary, but this is my best guess at this time.) If > so, that may take considerable time and subsequent updates to the filtering > logic will be difficult because of the slow update cycle in routers. Lack > of an "unknown" validation state with partial deployment may be problematic. > > ASCone: generating router filters to be included in configurations is easy > to deploy, but very clumsy. Not clear how reusing the RPKI to router > protocol would work. Unclear what partial deployment would look like. > > PathRPKI: changes to RPKI to router protocol necessary. However, the scope > of these changes is small. Good partial deployment as each combination of > origin AS and destination AS is immediately protected agains route leaks > even if ASes in the middle don't implement PathRPKI. > > Who is involved > > LDM: transit ASes. Leaf ASes that don't peer have no actions. > Mostly correct; we are potentially adding the ability of Leaf ASes to mark prefixes on ingress (identical to the marking that their transit ISPs would have marked), allowing (but not requiring) leaf ASes to allow upstreams to detect leaks that these same leaf ASes might have caused. > > ASPA: All ASes. Origin ASes and transit ASes that have transit ASes of > their own register C2P records. All other ASes filter based on this, most > notably ASes that peer. > > ASCone: Transit ASes register P2C records, ASes that peer filter based on > this. Leaf ASes that don't peer have no actions. > > PathRPKI: origin AS registers authorized transit ASes. No specific actions > for transit ASes. ASes in the downstream part of the path filter based on > this. > > Security > > LDM: relatively low, as a malicious AS could modify the in-band > information. > A malicious AS modifying the in-band information can only remove leak marking, or add leak marking. If they add leak marking, the only impact would be to block announcements that would otherwise be accepted. Removing leak marking would allow the malicious AS to leak, but potentially be visible to third parties that are able to see the modification (differentiate based on the ASN in the leak marking received on other connections, vs AS path and absence of marking). The latter would at least allow for non-repudiation (it would be theoretically possible to identify the specific ASN). Lack of protection on the AS-path is equally problematic WRT malicious ASes. Brian > > ASCone: middle, as ASes can incorrectly claim a P2C relationship with no > obvious recourse for the AS that is incorrectly labeled as a customer. > > ASPA: high, as only customers claim the customer-provider relationship. > > PathRPKI: a little higher, as the upstream part of the path is solely > determined by the origin AS (however, at the cost of flexibility as transit > relationship changes further upstream now require work by all the ASes > downstream of the change) > > What now? > > There are some good ideas here, but it sure looks like we haven't figured > out the best way to attack this problem. Publish four RFCs, throw them to > the wall, see what sticks? Hopefully we can come up with a better process > than that. > > Iljitsch > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow > --00000000000023e34e058d429c07 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Minor clarifications/comments inline about LDM.
=
On Tue= , Jul 9, 2019 at 8:15 AM Iljitsch van Beijnum <iljitsch=3D40muada.com@dmarc.ietf.org> wrote:
There are now four drafts about AS path valid= ation to remedy routing leaks that I'm aware of:

LDM: draft-ietf-grow-route-leak-detection-mitigat= ion
ASPA: draft-ietf-sidrops-aspa= -verification
ASCones: draft-ietf-grow-rpki-a= s-cones
PathRPKI: draft-van-beijnum-sid= rops-pathrpki

The TL;DR on the four:
LDM

Add in-band information to BGP tha= t signals that a peer-peer hop has been traversed to avoid having two peer-= peer hops. The idea is to do this without new code, at first at least. As t= he checks must thus be implemented with existing policy options, those will= probably be easy to implement in code on the routers later.

LDM marks prefixes in-band, on peer-to-peer A= ND on transit-to-customer (assuming at least one party is doing LDM.)
=
LDM checks prefixes in-band upon receipt, on peer-to-peer AND on custo= mer-to-transit (assuming recipient is doing LDM.)

= This prevents all of the major leak paths:
transit-customer-peer<= /div>
transit-customer-transit
peer-peer-transit
pe= er-peer-peer

The marking is propagated if large co= mmunities are being sent, so even if intermediate networks involved don'= ;t mark or check, the leakage is still detectable under many scenarios.
=C2=A0

ASPA

=
Register customer-to-provider (C2P) relationships with extension= s to RPKI. Based on this, check the upstream and downstream parts of the AS= path, making sure there are no valleyfreeness violations and that if the c= ustomer in the relationship between two ASes has registered a set of provid= er ASes, the upstream AS is indeed one of the registered providers. If not,= then the path is considered invalid.

The hop betw= een the upstream and downstream parts of the path may be an unregistered ho= p; peer relationships are not registered and in this part of the path any r= elationship is a valid one anyway. If there are additional unregistered rel= ationships in the path, validation is not possible and the path is consider= ed valid.

ASCones

Registe= r provider-to-customer (P2C) relationships with extensions to RPKI. Recursi= vely collect this information to resolve all ASes that may be visible behin= d a given AS. Then do a reverse lookup in the ROA database to obtain all th= e prefixes that are authorized to be advertised by these ASes and generate = a prefix filter that can be applied to a BGP neighbor.

=
Unclear what happens to prefixes that aren't included in the filte= r because of a missing AS-Cone (P2C record) or ROA.

PathRPKI

The RPKI ROA format is extended to incl= ude a set of authorized transit ASes in the upstream part of the path. Auth= orized ASes in the downstream part of the path are known through local conf= iguration. For each prefix, the two halves of the path are combined into a = list of ASes that may appear in the AS path.

These= paths are sent to routers using an extended version of the RPKI to router = protocol. Routers mark a prefix as invalid if the origin AS doesn't mat= ch as usual, and if an extended list of ASes is present, if there are ASes = in the BGP AS path that are not in the filter list (or appear in the wrong = order).

So let's compare.

=
In-band vs out-of-band

LDM is the only mechan= ism that works in-band. In-band is inherently less effective because the sa= me issues that create a route leak in the first place may also send incorre= ct in-band information.

"s= end incorrect in-band information" is limited (in the latest draft) to= only "fails to send in-band information".
The only inc= orrect in-band information that would have any effect is if the peer-peer m= arking uses the wrong ASN, at which point the recipient will block the inco= ming announcements. I.e. it will treat that error as a leak.
Fail= ure to mark, or failure to check, looks exactly the same as not participati= ng, and is no worse.
=C2=A0

=
Deployment

LDM: although it was supposed to b= e easy to deploy, discussion has been going on for four years, and in my op= inion, as per my earlier email about the draft, deployment issues haven'= ;t been solved at this time.

Th= e finalized versions are being discussed among the authors and will be disc= ussed at the Montreal meeting. Modulo uptake by providers, I believe we are= crossing the threshold to actual deployment, at which point this is entire= ly in the hands of the operators.
We can lead them to water, but = cannot make them drink.
=C2=A0

ASPA, ASCone and PathRPKI all require changes in the RIR RPKI front= - and backends and the RPKI relying party software implementations.

ASPA: requires unspecified changes to the RPKI to router = protocol to convey C2P records, and for routers to implement the validation= logic. (Maybe this is not necessary, but this is my best guess at this tim= e.) If so, that may take considerable time and subsequent updates to the fi= ltering logic will be difficult because of the slow update cycle in routers= . Lack of an "unknown" validation state with partial deployment m= ay be problematic.

ASCone: generating router filte= rs to be included in configurations is easy to deploy, but very clumsy. Not= clear how reusing the RPKI to router protocol would work. Unclear what par= tial deployment would look like.

PathRPKI: changes= to RPKI to router protocol necessary. However, the scope of these changes = is small. Good partial deployment as each combination of origin AS and dest= ination AS is immediately protected agains route leaks even if ASes in the = middle don't implement PathRPKI.

Who is involv= ed

LDM: transit ASes. Leaf ASes that don't pee= r have no actions.

Mostly corre= ct; we are potentially adding the ability of Leaf ASes to mark prefixes on = ingress (identical to the marking that their transit ISPs would have marked= ), allowing (but not requiring) leaf ASes to allow upstreams to detect leak= s that these same leaf ASes might have caused.
=C2=A0

ASPA: All ASes. Origin ASes and transit ASes= that have transit ASes of their own register C2P records. All other ASes f= ilter based on this, most notably ASes that peer.

= ASCone: Transit ASes register P2C records, ASes that peer filter based on t= his. Leaf ASes that don't peer have no actions.

PathRPKI: origin AS registers authorized transit ASes. No specific action= s for transit ASes. ASes in the downstream part of the path filter based on= this.

Security

LDM: rela= tively low, as a malicious AS could modify the in-band information.

A malicious AS modifying the in-band i= nformation can only remove leak marking, or add leak marking.=C2=A0
If they add leak marking, the only impact would be to block announcement= s that would otherwise be accepted.

Removing leak = marking would allow the malicious AS to leak, but potentially be visible to= third parties that are able to see the modification (differentiate based o= n the ASN in the leak marking received on other connections, vs AS path and= absence of marking).
The latter would at least allow for non-rep= udiation (it would be theoretically possible to identify the specific ASN).=

Lack of protection on the AS-path is equally prob= lematic WRT malicious ASes.

Brian
=C2=A0=

ASCone: middle, as ASes can inco= rrectly claim a P2C relationship with no obvious recourse for the AS that i= s incorrectly labeled as a customer.

ASPA: high, a= s only customers claim the customer-provider relationship.

PathRPKI: a little higher, as the upstream part of the path is sol= ely determined by the origin AS (however, at the cost of flexibility as tra= nsit relationship changes further upstream now require work by all the ASes= downstream of the change)

What now?
There are some good ideas here, but it sure looks like we haven= 't figured out the best way to attack this problem. Publish four RFCs, = throw them to the wall, see what sticks? Hopefully we can come up with a be= tter process than that.

Iljitsch
______= _________________________________________
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
--00000000000023e34e058d429c07-- From nobody Thu Jul 11 04:57:54 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EAE412010E for ; Thu, 11 Jul 2019 04:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=muada.com header.b=pJznIbAp; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VjlwAJMq 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 TfUBfeQIahqF for ; Thu, 11 Jul 2019 04:57:49 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EB8E1200F5 for ; Thu, 11 Jul 2019 04:57:48 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 4426E21FA9 for ; Thu, 11 Jul 2019 07:57:47 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Thu, 11 Jul 2019 07:57:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=muada.com; h= from:content-type:mime-version:subject:message-id:date:to; s= fm3; bh=VPPAKzs333VVyuadufWsQVDAIbnTLvtDUDjrNQF1bZo=; b=pJznIbAp wk3CVRtxZUOtdH2MPRJz0KwVoWupA+XUaruPvz7iNcHh+40ok8RtNqxThkepZxwQ M4FD8CnT1ZG3NdD9gv4bZSvCuXlQF03JVtIgnY+UDncJioG2aXa6Wev1/6hvMHh+ q/kjbS+Aaf0C9RL/rydQgzcvN280D/k9I+FxO6x+5LQfWjL32fHigU+31kOqMGGW H/9GqnVw3IcOOBcvUqL82obwi0pkhmtf241/vd7em6RhhFghaJdt/mGrjupyVhCu 4GDTHuETd4tkqwD0hQFCXwD+HlnTocWvHTe/aAjXZC26XWNqpqXBOT2E/kj7Pbkt 5ss7UJ9z2pM5tA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=VPPAKzs333VVyuadufWsQVDAIbnTL vtDUDjrNQF1bZo=; b=VjlwAJMq6vkx3z/KqCxTKRWHLZQNjzYiYlciQDMh8SnPT ntx5wGMn4092B8MGXzSOzecZ5ntqR6bebMJQ2jMgC1opxkd27iutPkgEwlhVf7T9 Ko3zCOFR8n5FoZZdSCmtJfZrX5nv4qng0y2YQpxwH4veRmq29wvceYT6ByNhC6X9 r394NE1MKlK1iOOyKFce9LUNRxVpUL3lhiEgtXVYKK8SDa7ichdNvRXP45lpb8PU 85722Siensp0f4AoDJ+NRG03kY4IPvjxyP9Kv7E+hGd6AsBgT7L7WErTVVlbxi2f ZHyi73bhCNQpJy4IuJlLHFt7/mA9t2l3UKbLv2xIQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrgeekgdegkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhephfgtggfukfffvffosegrtdhmrehhtd dvnecuhfhrohhmpefklhhjihhtshgthhcuvhgrnhcuuegvihhjnhhumhcuoehilhhjihht shgthhesmhhurggurgdrtghomheqnecuffhomhgrihhnpehmuhgruggrrdgtohhmnecukf hppeekfedrkeehrdejuddrleehnecurfgrrhgrmhepmhgrihhlfhhrohhmpehilhhjihht shgthhesmhhurggurgdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from [192.168.178.17] (83-85-71-95.cable.dynamic.v4.ziggo.nl [83.85.71.95]) by mail.messagingengine.com (Postfix) with ESMTPA id 229BB380084 for ; Thu, 11 Jul 2019 07:57:46 -0400 (EDT) From: Iljitsch van Beijnum Content-Type: multipart/alternative; boundary="Apple-Mail=_5FE8F65C-043E-4D6B-B08C-86A26023E839" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <7855DABC-E278-46E6-840B-3A536C0023B2@muada.com> Date: Thu, 11 Jul 2019 13:57:41 +0200 To: sidrops@ietf.org X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [Sidrops] Extending RPKI-Router protocol to do more X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 11:57:52 -0000 --Apple-Mail=_5FE8F65C-043E-4D6B-B08C-86A26023E839 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii [Posted to sidrops, grow and RIPE routing-wg] Hi all, A few weeks ago I wrote a draft on extending RPKI to make it possible to = validate the full AS path rather than just the origin AS. Rather than ignore other work in this area such as ASPA and AS Cones, = I've decided to focus on the thing that all these efforts will benefit = from: extensions to the RPKI-Router protocol so that more types of = filtering become possible under the RPKI model than just origin = validation as per RFC 6811. I think the RPKI model is a powerful one: you run the software that uses = complex algorithms on a small set of central boxes. This is very = flexible software that can be changed quickly (often open source). Then = you send filters over to the routers using very well-defined semantics, = so you know exactly what the routers are going to do and the risks are = minimal, with no need to keep changing the router implementations when = there are new validation mechanisms. My additions are: - a way to filter entire AS paths (such as created by ASPA or my = PathRPKI draft) - a way to allow prefixes from a given set of ASes, which could be used = to implement a system like AS Cones - a way to deny prefixes from a given set of ASes, which could be used = to react to route leaks etc on the fly These are just examples, I'm sure there are many different things that = could be done with these filter extensions. I wrote a draft about the whole thing, but draft submissions are = currently closed so read it here for now: = http://www.muada.com/drafts/draft-van-beijnum-sidrops-rpki-rtr-ext-00.txt = I'm very interested to hear what you think. Iljitsch --Apple-Mail=_5FE8F65C-043E-4D6B-B08C-86A26023E839 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
[Posted to sidrops, grow and RIPE routing-wg]

Hi all,

A few weeks ago I wrote a draft on = extending RPKI to make it possible to validate the full AS path rather = than just the origin AS.

Rather than ignore other work in this area such as ASPA and = AS Cones, I've decided to focus on the thing that all these efforts will = benefit from: extensions to the RPKI-Router protocol so that more types = of filtering become possible under the RPKI model than just origin = validation as per RFC 6811.

I think the RPKI model is a powerful one: you run the = software that uses complex algorithms on a small set of central boxes. = This is very flexible software that can be changed quickly (often open = source). Then you send filters over to the routers using very = well-defined semantics, so you know exactly what the routers are going = to do and the risks are minimal, with no need to keep changing the = router implementations when there are new validation = mechanisms.

My = additions are:

-= a way to filter entire AS paths (such as created by ASPA or my PathRPKI = draft)
- a way to allow prefixes from a given set = of ASes, which could be used to implement a system like AS = Cones
- a way to deny prefixes from a given set of = ASes, which could be used to react to route leaks etc on the = fly

These are = just examples, I'm sure there are many different things that could be = done with these filter extensions.

I wrote a draft about the whole thing, = but draft submissions are currently closed so read it here for = now:

http://www.muada.com/drafts/draft-van-beijnum-sidrops-rpki-rtr-= ext-00.txt

I'm very interested to hear what you think.

Iljitsch

= --Apple-Mail=_5FE8F65C-043E-4D6B-B08C-86A26023E839-- From nobody Fri Jul 12 08:53:34 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 428EC12078A; Fri, 12 Jul 2019 08:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.704 X-Spam-Level: X-Spam-Status: No, score=-0.704 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 grVSKk7tp1ss; Fri, 12 Jul 2019 08:53:30 -0700 (PDT) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 90BC7120789; Fri, 12 Jul 2019 08:53:30 -0700 (PDT) Received: by mail-qt1-x82c.google.com with SMTP id 44so8520148qtg.11; Fri, 12 Jul 2019 08:53:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=/X+lTfcHpEczvq66m2LzkiO6dBe4auTHF+2tbOA1IlM=; b=i+DGI+V3qZIbyNbDiAg3r1uJbltPEkrALRFiPTbJDcyIcfwPpqrbyZu2dNolLxzOTa 4QLSSsZ3ux/ruqVNjXQA8WhCVe4ShtsL3AJQw70+dpGJsP/0+2K7qVpJwMj2Zn1wjz9t WxL2SIPqS56RDzbXjB8chU/1XVZ3HELg8uINrpPaKDmSL2gKYfqKU+XxlwkZyUKadWv+ 7cMPjMwpI+1QUe3Dp0E1GkzElFu9YRV+wQxEhRg5hKdeAWmxNEQR0REGao0gCNGAHB27 o/fv9ksR3oDRteAFENvSNGMRQoHv5t3Tmqvl9G5nM2im0se+72o9fp2xmK+1MFDYsqlf j8iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=/X+lTfcHpEczvq66m2LzkiO6dBe4auTHF+2tbOA1IlM=; b=hiuGmdQ5tC4yoidLR+25JzleKrLLOcKvQ0Pnm0mmg3xZ/t8VStEf6HuKrz/jFOr+k0 Qy62ikgzTppSetDwiue8kFxypZ8CygzJ3r6Im16fWIQkJtmMIaYDx707NY+Wllb2sqqS UuACFStrDNqSlfpgGpMVoNzJlqH6Wp69IVzwpBnUrytLJ1xISV1aO1Tmk8Nkl6vfdLhu wfuITsffWvrQ5Solk2+w8mTKEjy9cExbzx6WHkVKWpxHV47zBvJ3GM5SlWLiW60QRQYu twSk/B+EZAIFeA57QvPGr0RyD7DJbsrpTqYNE3nSJPigHBeLFUJNhdkxNW0GJ+VLVP13 IsuQ== X-Gm-Message-State: APjAAAW9n7+9/ML29CX8g3Lsd3vLippRB2P4p+9OCIZZTxqLUZR83pL1 rwklgALQxi0BmBzpP+JdAVPOwl2UxoG/q+7R2acd9A== X-Google-Smtp-Source: APXvYqwA97LOi4/0fc698u9zlW9bhkl2GepLLTb/18p8XA8IUdr/1+v/Wu6jcJ8/PHFOXYiFr5XWlaVFBFpC/PbMGB0= X-Received: by 2002:a0c:acab:: with SMTP id m40mr7504717qvc.52.1562946809324; Fri, 12 Jul 2019 08:53:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Christopher Morrow Date: Fri, 12 Jul 2019 11:53:18 -0400 Message-ID: To: SIDR Operations WG , SIDROps Chairs , sidrops-ads@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Sidrops] IETF 105 - Montreal - Call for Agenda Items X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 15:53:32 -0000 Howdy folks! 1.5-ish weeks remain until meeting-time!! There was a little burble in the RPKI-force this morning, perhaps the lacnic folk have data they want to present at the meeting too? :) On Wed, Jun 26, 2019 at 10:19 AM Christopher Morrow wrote: > > howdy IETF Folks! > Today is the day to imagine what your best IETF SIDROPS meeting could > consist of!! > We have a meeting slot in Montreal, let's utilize it like your lowest > priced internet link! > > Please send Agenda Items forth with! > > -chris > Chair Personage From nobody Tue Jul 16 22:49:16 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51BE612015A; Tue, 16 Jul 2019 22:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 GwBOGSqNFnmf; Tue, 16 Jul 2019 22:49:12 -0700 (PDT) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 AAA00120140; Tue, 16 Jul 2019 22:49:09 -0700 (PDT) Received: by mail-qt1-x82b.google.com with SMTP id k10so22191333qtq.1; Tue, 16 Jul 2019 22:49:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=p2z2/1IzJpOufyonMfx7C++LNjMNjEEM+0yxy4lKV+4=; b=R3p45+DXtRRuvAbfvXEwpbb3R1JX1t8EveZ7JKedJx7c4FLctTDWUbSuOmP/GOhegG ff/ss9dzj+lW/5qPP9cX2ILvmhu2zdosatimwqO+y9hzPpq5cdkwM9QfHe4KwagTXBlF FrNL5lxt9MF1ApuIn5d4Sjmvbsts8GhNjpGQdl5MGsF2SmDZYFek+YFugKIo5DfCwnqy B/LkIAow9iEVEPTgO4eMdPvGsKo/1Qnhmd7jzlZzlhF6rtWssEONI2VuSb66Kv6VwVy2 te9OgsWKeVy/Q/YYKKjJV1Pkd5tW36wALv9XUDzrhO8Jy2/xvcQk4CgayOIjXmzaZsXJ 4aQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=p2z2/1IzJpOufyonMfx7C++LNjMNjEEM+0yxy4lKV+4=; b=Zol6ejpVQWKO6tOPcHDxVIkywC/KJq6MWox38xS5bZnxwK6wIZbjXgzO+A9u0zEaVa hfoR2CDjrZvRwCuLwcIZ0xk3wuMW9vk1RkmIsIKn5W1CEkhGi0JzfTJM+jGocLAFue4n zJLqKp9rubY14Qfv0VVqJqpkYDOKDn09WKf3gmO0UeRJ8G89SUXxxhuhcP8MisGIN4IZ NaiZVSMfY5rFiKw1oIv0qf5raL+6JtQZKA2+zK0ZYxRsGSKO/2A4hnxZeAPAI6TBNM7a zRq62OvFXr5KQrnZidI6DVVn5zklNlh/HG7AyGH8BwXF6iZwvc/Gy616Yfi+zIljO33d 2fqw== X-Gm-Message-State: APjAAAXF37bGeIhyBojyipt43hbSlQzScRAy+4EbfwYm4jbd88SbxYCa HWCzloe3RKdSFwN+vqyJePBKaLlr5W9lZRwln5Kd7M96MSQ= X-Google-Smtp-Source: APXvYqxCQOqPY6xfuUOGsknfrb0h9gunno8vVvju9OZsKqoLx1tJc8kBvy4UqqqMJnB4ZkKVCvMtcAci6Pu5zydzhs0= X-Received: by 2002:a0c:f952:: with SMTP id i18mr13123352qvo.205.1563342548235; Tue, 16 Jul 2019 22:49:08 -0700 (PDT) MIME-Version: 1.0 From: Christopher Morrow Date: Wed, 17 Jul 2019 01:48:57 -0400 Message-ID: To: sidr-ops-chairs@ietf.org, sidr-ads@ietf.org, SIDR Operations WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Sidrops] [WG-ADOPTION] draft-michaelson-rpki-rta - Ends 08/07/2019 (Aug 7) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2019 05:49:14 -0000 Howdy WG Folks! Please have a read through the subject document: https://datatracker.ietf.org/doc/draft-michaelson-rpki-rta/ Abstract: "This document defines a Cryptographic Message Syntax (CMS) profile for a general purpose Resource Tagged Attestation (RTA), for use with the Resource Public Key Infrastructure (RPKI). The objective is to allow an attestation, in the form of an arbitrary digital object, to be signed "with resources", and for validation to provide an outcome of "valid with resources". The profile is intended to provide for the signing of an attestation with an arbitrary set of resources." We heard about this at the previous F2F meetring, let's hear your thoughts on the prospect of adopting this document as a WG document. thanks! -chris co-charitable From nobody Tue Jul 16 22:52:28 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2073120140; Tue, 16 Jul 2019 22:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 6W3NULBNIk14; Tue, 16 Jul 2019 22:52:25 -0700 (PDT) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 C9E3E120158; Tue, 16 Jul 2019 22:52:24 -0700 (PDT) Received: by mail-qk1-x731.google.com with SMTP id g18so16554822qkl.3; Tue, 16 Jul 2019 22:52:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=e2gIcDzY1tKJLzPl/0X+0DmOkogipgVbEHgCT/YDARM=; b=o54ctKTrpLyHBu9v/976uXP5Pn4THvCm/IA7zgYQNdmPGUQf7lmJAwgHGuGgQRqxQB /g72NwKBpnTMflxnsia7jGKAzoBrL4o+YdPaoi4vTTkKwXLxlQFITAc07XU7u1DMxkob /4KYsqE3emPdcWR0y6z/HIuaBtpbbIbKq4vV0yxDgocycazL+PzamIcRXBP4RNASk/Mj Gljg2Z2U0rnB7zBMleMZEpIj6CEdm0XLjrdUTUnqacFXYOE4Bg+ZvIxXn/k5TV4rZk5I gaEbAv3QD6Wo56Sc/vlP2eIGbfXw6DRi0YmHEcdhgpEYBzZdYZ0TphUpbGpesrX/FFbD Hu4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=e2gIcDzY1tKJLzPl/0X+0DmOkogipgVbEHgCT/YDARM=; b=tcQdmNUbO5vKcgK/VOaujOZ8qjyxw0pI3fy+KGC2n1DI01j90ilJhAK3BcHYpYXMwY yeH912SIhNWVbgVGIBogxH1fp9d3epZfzpWuyY+SFPhdE5HsR5SjeuLKsPOVnHj86Yz8 g+OaHmOcP3/wbV+5D/F94rsm1mm1M9Cj3oMUJ673M3osuEcx6uHa0vSscovCePWJCC1A n8MeU9XKmg6DJRxNUEmtV7RE+JCOSShYd8Uanpk+bTrPs+Cv/rsv1tVM/MD+v97nuFXy nVmKVEE1wXZEXR7LATQeTOwJJ1jOfiQjWMXzSVBXdKnakRxjLwNkPuNbP3SxJ6HrHtzn B+Rg== X-Gm-Message-State: APjAAAWSa/FDK5qd55j0ymILakBqjKgOnrY9FcTfHSQbIndTCeD3grj2 VNSPygwaBOhpEd6GbDhvUl+n3/uNdGFv/9+Iu7fl41vM X-Google-Smtp-Source: APXvYqyXi4DI3zzr8BodKUc8V5/ldd+UHuzjje8ejaTzjYHUCbcLvr7rBaMPJi0h9Z2kCi1VjuC4Lh0KSi4nOqnypUE= X-Received: by 2002:a37:4e0d:: with SMTP id c13mr24092517qkb.116.1563342743513; Tue, 16 Jul 2019 22:52:23 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Christopher Morrow Date: Wed, 17 Jul 2019 01:52:12 -0400 Message-ID: To: SIDROps Chairs , sidr-ads@ietf.org, SIDR Operations WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Sidrops] [WG-ADOPTION] draft-michaelson-rpki-rta - Ends 08/07/2019 (Aug 7) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2019 05:52:27 -0000 -bad-chairs-alias +goodalias On Wed, Jul 17, 2019 at 1:48 AM Christopher Morrow wrote: > > Howdy WG Folks! > Please have a read through the subject document: > https://datatracker.ietf.org/doc/draft-michaelson-rpki-rta/ > > Abstract: > "This document defines a Cryptographic Message Syntax (CMS) profile > for a general purpose Resource Tagged Attestation (RTA), for use with > the Resource Public Key Infrastructure (RPKI). The objective is to > allow an attestation, in the form of an arbitrary digital object, to > be signed "with resources", and for validation to provide an outcome > of "valid with resources". The profile is intended to provide for > the signing of an attestation with an arbitrary set of resources." > > We heard about this at the previous F2F meetring, let's hear your > thoughts on the prospect of adopting this document as a WG document. > > thanks! > -chris > co-charitable From nobody Wed Jul 17 00:51:38 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43ACB120140; Wed, 17 Jul 2019 00:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl 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 UOqS6U1QiSzn; Wed, 17 Jul 2019 00:51:34 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3A5412009C; Wed, 17 Jul 2019 00:51:33 -0700 (PDT) Received: from [IPv6:2001:981:4b52:1:7c32:a466:78de:3880] (unknown [IPv6:2001:981:4b52:1:7c32:a466:78de:3880]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 2A36E1F636; Wed, 17 Jul 2019 09:51:31 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1563349891; bh=4ar3rO/TWnEMTRPaJXufjlq76HUHIte5Tx7r82cn6nw=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=N01UQL0z/Et1tK6Sj+Bfq9ONj8DP12OCOji3n9mbLBO9h6dbmHD5vdyqPqhaOq4ww CUhMktgnqDv5qc6Xb1cNJYOVjR7Ywq2Un08axGDcREBk82p7HVcyU/t/2j9C9HNnRY UCBfVjHAhkMx6NEKCe0dQ94GLp7gvBb7l6Z409Kk= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Tim Bruijnzeels In-Reply-To: Date: Wed, 17 Jul 2019 09:51:29 +0200 Cc: SIDR Operations WG , SIDROps Chairs , sidrops-ads@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <97C702CD-3300-4222-9FD0-B1EA3C02E8BE@nlnetlabs.nl> References: To: Christopher Morrow X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Sidrops] IETF 105 - Montreal - Call for Agenda Items X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2019 07:51:37 -0000 Hi Chris, all, Time permitting I want to give an update on the Signed-TAL work. In = particular regarding the idea to use dedicated publication points of = certificates in different phases during a roll, so that monitoring = access to the uris can help to make an informed decision on when it's = safe (enough) to 'revoke' the old key. This idea came about after a = comment by Wes in Singapore that one of the lessons learned from RFC5011 = should be to know when it's safe to roll (if I remember correctly). 15 = minutes should be plenty I think. I prefer not to go through the whole = draft again, because it was discussed a number of times already - but if = folks want me to take it from the top.. then shout, or talk to me in the = hallways.. Also, not for this WG but of interest. My colleague Roland will present = "The RPKI Wayback Machine" (repository data analysis) in maprg on = Friday. Tim > On 12 Jul 2019, at 17:53, Christopher Morrow = wrote: >=20 > Howdy folks! 1.5-ish weeks remain until meeting-time!! >=20 > There was a little burble in the RPKI-force this morning, perhaps the > lacnic folk have data they want to present at the meeting too? :) >=20 > On Wed, Jun 26, 2019 at 10:19 AM Christopher Morrow > wrote: >>=20 >> howdy IETF Folks! >> Today is the day to imagine what your best IETF SIDROPS meeting could >> consist of!! >> We have a meeting slot in Montreal, let's utilize it like your lowest >> priced internet link! >>=20 >> Please send Agenda Items forth with! >>=20 >> -chris >> Chair Personage >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Sat Jul 20 05:34:02 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0BCC120AAC for ; Sat, 20 Jul 2019 05:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.898 X-Spam-Level: X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 wdFzmvTRD0Iu for ; Sat, 20 Jul 2019 05:33:59 -0700 (PDT) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76EE7120AAA for ; Sat, 20 Jul 2019 05:33:59 -0700 (PDT) Received: from allealle.ripe.net ([193.0.23.12]) by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hooYo-0002qN-7L for sidrops@ietf.org; Sat, 20 Jul 2019 14:33:58 +0200 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::3c4]) by allealle.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hooYo-0000Q9-1C for sidrops@ietf.org; Sat, 20 Jul 2019 14:33:58 +0200 From: Thiago da Cruz Content-Type: multipart/alternative; boundary="Apple-Mail=_A6FCDE32-60C8-456B-B8F1-64F255A4E69A" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Sat, 20 Jul 2019 08:32:45 -0400 To: sidrops@ietf.org X-Mailer: Apple Mail (2.3445.104.11) X-ACL-Warn: Delaying message X-RIPE-Signature: bc54d195b0c1bc98e39bfcde448d5b41fa9b7e1b7e9fc10fd45c184da73b7147 Archived-At: Subject: [Sidrops] RPKI Planned Downtime X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2019 12:34:02 -0000 --Apple-Mail=_A6FCDE32-60C8-456B-B8F1-64F255A4E69A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear colleagues, We=E2=80=99ll be running an upgrade on our infrastructure on Monday 22nd = July from 12:00 (Amsterdam local time UTC+2). The RSYNC and RRDP repositories will be accessible, but the up down = protocol, the RPKI UI on my.ripe.net and REST API = will be unavailable during the upgrade. We expect the upgrade to take no longer than 90 minutes.=20 We apologise in advance for any inconvenience that might be caused by = this. = https://www.ripe.net/support/service-announcements/rpki-planned-maintenanc= e = Kind regards, Thiago da Cruz RIPE NCC --Apple-Mail=_A6FCDE32-60C8-456B-B8F1-64F255A4E69A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Dear colleagues,

We=E2=80=99ll be running an upgrade on = our infrastructure on Monday 22nd July from 12:00 (Amsterdam local time = UTC+2).

The = RSYNC and RRDP repositories will be accessible, but the up down = protocol, the RPKI UI on my.ripe.net and REST API will be unavailable during = the upgrade.
We expect the upgrade to take no = longer than 90 minutes. 

We apologise in advance for any = inconvenience that might be caused by this.

https://www.ripe.net/support/service-announcements/rpki-planned= -maintenance

Kind regards,
Thiago da Cruz
RIPE NCC




= --Apple-Mail=_A6FCDE32-60C8-456B-B8F1-64F255A4E69A-- From nobody Sat Jul 20 06:02:10 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACD11120ABB for ; Sat, 20 Jul 2019 06:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 uRghHvLNzbcv for ; Sat, 20 Jul 2019 06:02:07 -0700 (PDT) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 86C7A120AB9 for ; Sat, 20 Jul 2019 06:02:07 -0700 (PDT) Received: by mail-qk1-x72d.google.com with SMTP id g18so25335172qkl.3 for ; Sat, 20 Jul 2019 06:02:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=wDvvmUgKSK/GWvlPHYY9s6IoDCePArHa3sNZTyiGIAE=; b=R84LI3syFQ5tptVQL4BYtT2aPuo3vQO2Dqo2NB3NZxGqaAxykfEeZqvUdFtgjW291u +z3Jaz+BKkasPiITs8AN+xFNPu/78LdrkYHL3iI3bfIF4iRk63zo5zYAfA/wlT7TEiPB I5su08ymkaNpAiCzqv53MQUxAg7IDjpV1iGWeqFKb4UtjtVGNoTiG0xTcX1wfJUc48Gq z62lbZ4b48G/UaoprXRkxryvjdo1PzIkNed0STTxzrFhqnj0V5vRUDvKIVCHtswzfJWn JDq0eAkYnAcyRh4tEYrZKdfUPHexEO6f0sO+WqrK0+yb/r1rxdwaSB94cWKQTOnRF8tq 9RkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=wDvvmUgKSK/GWvlPHYY9s6IoDCePArHa3sNZTyiGIAE=; b=RaJ3e27EEfw7loM/EMhb5zmYhfpfm64GeJ9Cs9a46K+lyQLC+RN0L4Rwlw242UqFXg 0pr69ErnLNZAOz/4NnZB2MzwHqciv8vNtz05OIkPKYs7FSAi4udCbDawlmOQWhdF0QMn oixoFUfpCqYAKGr0i3bF14/BGqD/bzyUdpd/bG6WtPibP1ARL5gUycrZPWaN7yUoWckj UWZJ9TeeVoQZAzGljdmlE9VXJMakIDetUFQrle/KAYJIoTTr4XrfYT4nH6ewC5UEY8F/ F0VkjQhyK/Y0ChdJcWZEtSmFJSLylN/mCpGExJX3da/lHW3Qyonf6nm0q+ZmnX5Mr7FZ n6yA== X-Gm-Message-State: APjAAAW6XTMG+VeXHTh2MVORAC480u0yMriGdilN7eQybSxhXHRJjhCU j0QAuFs0KFvSTXyqDHgsaW3fwJYlVTPdtk2arhJLpHLI8UQ= X-Google-Smtp-Source: APXvYqyhexXlihe63R6DGoUQKKC6amVn6WCCzWO8tYRvrU11tU+xw+1vV9kMXkAOtAlqWOa4dGheoMktnD8qFOjcCB0= X-Received: by 2002:a05:620a:102d:: with SMTP id a13mr38764474qkk.268.1563627726268; Sat, 20 Jul 2019 06:02:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Christopher Morrow Date: Sat, 20 Jul 2019 09:01:54 -0400 Message-ID: To: Thiago da Cruz Cc: SIDR Operations WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] RPKI Planned Downtime X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2019 13:02:10 -0000 Hey! thanks for the note/info! :) This should go some distance in making other RPKI top level operators comfortable with making maintenances like this :) On Sat, Jul 20, 2019 at 8:34 AM Thiago da Cruz wrote: > > Dear colleagues, > > We=E2=80=99ll be running an upgrade on our infrastructure on Monday 22nd = July from 12:00 (Amsterdam local time UTC+2). > > The RSYNC and RRDP repositories will be accessible, but the up down proto= col, the RPKI UI on my.ripe.net and REST API will be unavailable during the= upgrade. > We expect the upgrade to take no longer than 90 minutes. > > We apologise in advance for any inconvenience that might be caused by thi= s. > > https://www.ripe.net/support/service-announcements/rpki-planned-maintenan= ce > > Kind regards, > Thiago da Cruz > RIPE NCC > > > > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Sun Jul 21 14:19:57 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1C3120098; Sun, 21 Jul 2019 14:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 bgjJvXUMV4NW; Sun, 21 Jul 2019 14:19:54 -0700 (PDT) Received: from relay.kvm02.ops-netman.net (relay.ops-netman.net [192.110.255.59]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C39312014F; Sun, 21 Jul 2019 14:19:52 -0700 (PDT) Received: from mail.ops-netman.net (mailserver.ops-netman.net [199.168.90.119]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by relay.kvm02.ops-netman.net (Postfix) with ESMTPS id 19FB83FCF4; Sun, 21 Jul 2019 21:19:49 +0000 (UTC) Received: from morrowc-glaptop2.ops-netman.net (unknown [IPv6:2001:67c:370:0:2087:753d:e1fe:6c9a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.ops-netman.net (Postfix) with ESMTPSA id E51F8461; Sun, 21 Jul 2019 21:19:48 +0000 (UTC) Date: Sun, 21 Jul 2019 17:19:48 -0400 Message-ID: From: Chris Morrow To: sidrops@ietf.org, sidrops-chairs@ietf.org, sidrops-ads@ietf.org User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.2 Mule/6.0 (HANACHIRUSATO) Organization: Operations Network Management, Ltd. MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: [Sidrops] [WG ADOPTION] draft-va-sidrops-deploy-reconsidered-01 - ENDS 08/11/2019 (Aug 11) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2019 21:19:55 -0000 SIDROps folks! Please consider this an adoption call for the subject draft, abstract of which is: "This document defines a deployment model for reconsidered validation [RFC8360] in the Resource Public Key Infrastructure (RPKI). It stipulates that Relying Parties in the RPKI MUST support reconsidered validation by 1 July TBD-Year, and that Certificate Authorities MAY use the reconsidered validation OIDs in CA certificates that they issue from this date. Furthermore Certificate Authorities should monitor whether the set of resources in CA certificate they receive has shrunk, and make adjustments in the CA certificates and/or other RPKI objects when appropriate." Please have a read, discuss, and comment over the next ~3 weeks period. Thanks for your prompt attention to this matter. -chris co-boffin From nobody Tue Jul 23 08:41:56 2019 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BC1B4120059; Tue, 23 Jul 2019 08:41:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <156389650971.27822.217223608979292331@ietfa.amsl.com> Date: Tue, 23 Jul 2019 08:41:49 -0700 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-validating-bgp-speaker-03.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 15:41:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIDR Operations WG of the IETF. Title : Signaling Prefix Origin Validation Results from an RPKI Origin Validating BGP Speaker to BGP Peers Authors : Thomas King Christoph Dietzel Daniel Kopp Aristidis Lambrianidis Filename : draft-ietf-sidrops-validating-bgp-speaker-03.txt Pages : 8 Date : 2019-07-23 Abstract: This document describes the use of BGP large communities, as well as its usage, to signal prefix origin validation results from an RPKI Origin validating BGP speaker to other BGP peers. Upon reception of prefix origin validation results, peers can use this information in their local routing decision process. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-validating-bgp-speaker/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-validating-bgp-speaker-03 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-validating-bgp-speaker-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-validating-bgp-speaker-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 23 13:11:14 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32DFE120986; Tue, 23 Jul 2019 13:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net 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 RnE-z7UcaC_M; Tue, 23 Jul 2019 13:11:01 -0700 (PDT) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25E841209B5; Tue, 23 Jul 2019 13:10:58 -0700 (PDT) Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x6NK952g031218; Tue, 23 Jul 2019 13:10:56 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=BhBHngJ9IcOHbUXtGe2RGjnOp0N7AwDZc51FJ3uJKLU=; b=EP8u+g7yXEWjWDB8QrnDW7DLxXDMjmbRGnUull0ksPj2BvhGI4mBM3qLi84fzBU12IMc QzbFEzQACDYfvxaNT3qi6F8bHxwTGu95+YbC4ONHmRxUUxoSBq2+vul3+guxdGYbHZKj PZNl+5nrxNhgZgju9l2aPv177QySnBXeSZJN79Pp8niB4uRej7i/UgvhbGfuNJ/63RP0 5Uw0Cr3xIKDArkRaEaS9UYVri66czLfp9llrA+lb4fj2bItHVr60Rcjnu+TaKmzMOauk 6vWoUPSZiKb7XLqp/X58NiIsk2Mb0kiTrwCwLK9qlpk40fZFe7qXgmoU1quRu5tcQqzY 1g== Received: from nam05-by2-obe.outbound.protection.outlook.com (mail-by2nam05lp2056.outbound.protection.outlook.com [104.47.50.56]) by mx0a-00273201.pphosted.com with ESMTP id 2tx82y83eu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Jul 2019 13:10:55 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lzRVxODhdOjx4mgMn27zJGGwMWFqqpkLxe9MxRbiWIhuRbGqJFP4sajqKxkKmxpeJFq3ehpRXNcAR9B2myRFqjTD6hN1fKSgUHWhHPrCKL5lh0uQAeN2aJtoSXHepklswunsN5ibNr020Mvs7KOKYdZqsCMwgZbkO1ZoIkZoakbfNjhWrswHxPs4nZo9mgZZMP4jzNhFv+NYNIT0/pHGAhiu6vZrE6K8PcUS9oEdqJSYw4nfnCr71UdxweikO+YgcB5ILXFc8lb5nUn82nVp4a2V279L4LfQAl55iWJaYtefWRXWdySYic+y3mRVrLbnzftbhS8M0N50cuO5DOqvDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BhBHngJ9IcOHbUXtGe2RGjnOp0N7AwDZc51FJ3uJKLU=; b=P72EtutSyoxsvtloFyyfaHKApeysJ9XH/FsqVLIFvWT5d/8iZAnA9UcaqbOOm0Rm86+4nAbaJ2SF2Xh/De5qVu0/I6mmb7vgjoj5Ohf86mslQ7pk84aH8pWEKE0VSwHH/2+UENET0f75u7huwGwGY0vBH6iEVBGLeA+p2YDzpzIwrzXcTjC3PsUuOvgP53KgtUEpYVT9FY9GOF3T3OJArutn6fz1PcTOOGiEgy60QTWijnPd1TH5R20G810pE1HfV4RmHzc0mQ2SaTVWQby9w18R/fMFBukR10sgSYaqsa66ALkm72utdLy5/xd9mrvhV+HObk9U4+pMERdrqVZFyw== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=juniper.net;dmarc=pass action=none header.from=juniper.net;dkim=pass header.d=juniper.net;arc=none Received: from DM6PR05MB4714.namprd05.prod.outlook.com (20.176.110.82) by DM6PR05MB5498.namprd05.prod.outlook.com (20.176.122.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2115.8; Tue, 23 Jul 2019 20:10:53 +0000 Received: from DM6PR05MB4714.namprd05.prod.outlook.com ([fe80::64b6:144d:5560:9148]) by DM6PR05MB4714.namprd05.prod.outlook.com ([fe80::64b6:144d:5560:9148%5]) with mapi id 15.20.2115.005; Tue, 23 Jul 2019 20:10:53 +0000 From: John Scudder To: "draft-ietf-sidrops-validating-bgp-speaker@ietf.org" CC: "sidrops@ietf.org" Thread-Topic: Multiple origin validation states in draft-ietf-sidrops-validating-bgp-speaker Thread-Index: AQHVQZK7YXV6PGo8cUeBqH/9As28xw== Date: Tue, 23 Jul 2019 20:10:53 +0000 Message-ID: <0B8E9A81-31FE-45BC-A01C-0D05E307EE0E@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.10] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b4355c84-2b0e-4dd2-fee4-08d70fa9dda7 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:DM6PR05MB5498; x-ms-traffictypediagnostic: DM6PR05MB5498: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0107098B6C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(346002)(136003)(39860400002)(396003)(376002)(366004)(199004)(189003)(66946007)(76116006)(91956017)(66066001)(6916009)(6116002)(33656002)(476003)(186003)(68736007)(3846002)(2616005)(6436002)(8936002)(6486002)(66446008)(64756008)(66556008)(66476007)(14454004)(5660300002)(450100002)(86362001)(8676002)(25786009)(71190400001)(71200400001)(2906002)(53936002)(102836004)(6506007)(2351001)(486006)(7736002)(4326008)(316002)(99286004)(305945005)(478600001)(4744005)(81156014)(81166006)(6512007)(26005)(2501003)(5640700003)(36756003)(256004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB5498; H:DM6PR05MB4714.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 1+nSUyyrw4eT1WlenD3gxT/FotVoVWP0qG+AYdU4isTTcFewlo/jhdwiN1TQxpR7KbUt8BNIMxOmRdqmZomarhmD9G8M62vfMDGNWlYFteFqKs2zCIqLYPAeBzRfoFghR+8AsZP+Mb1kuLEoi++jUYqymU07v+vE8IkufSVMN/RefInuy/w/pitJKv+gVb61z1zcUA38j05eR+pT1pHMJlQOiVsubpNtSWtau2l5yMRP3jUvPAmChW0HXGGCEhDF41SbDYB882Eu7D2d3J7G8WZgBCzsytQ6Mc6TtIbLR3hn7a4vG9+BZZELRcgl2DevA7ni0J/3wZBhwCtJIB8amaIdcUeDLdNZmZHE+8xJFIvInXCpiO4BL/ZbFENjqiGLkRDgV9MfhhLHSB7Ht3Zqrek6G1aOBZw4TIaWmZhpERU= Content-Type: text/plain; charset="utf-8" Content-ID: <13BA29D670A12542B5AC28676D6376FF@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: b4355c84-2b0e-4dd2-fee4-08d70fa9dda7 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jul 2019 20:10:53.7379 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jgs@juniper.net X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB5498 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-23_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1907230206 Archived-At: Subject: [Sidrops] Multiple origin validation states in draft-ietf-sidrops-validating-bgp-speaker X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 20:11:13 -0000 TXkgY29tbWVudCBhdCB0aGUgbWljIHdhcyBiYXNlZCBvbiB0aGUgdmVyYmFsIGRlc2NyaXB0aW9u IG9mIHRoZSBzbGlkZS4gV2hhdCBJIHNlZSBpbiB0aGUgZHJhZnQgdGV4dCBpcyBkaWZmZXJlbnQ6 DQoNCjUuNC4gIEVycm9yIEhhbmRsaW5nIGF0IFBlZXJzDQoNCiAgIEEgcm91dGUgc2VudCBieSBh IHZhbGlkYXRpbmcgQkdQIHNwZWFrZXIgU0hPVUxEIG9ubHkgY29udGFpbiBub25lIG9yDQogICBv bmUgRUJHUCBQcmVmaXggT3JpZ2luIFZhbGlkYXRpb24gU3RhdGUgTGFyZ2UgQ29tbXVuaXR5Lg0K DQogICBBIHBlZXIgcmVjZWl2aW5nIGEgcm91dGUgZnJvbSBhIHZhbGlkYXRpbmcgQkdQIHNwZWFr ZXIgY29udGFpbmluZw0KICAgbW9yZSB0aGFuIG9uZSBFQkdQIFByZWZpeCBPcmlnaW4gVmFsaWRh dGlvbiBTdGF0ZSBMYXJnZSBDb21tdW5pdHkNCiAgIFNIT1VMRCBvbmx5IGNvbnNpZGVyIHRoZSBs YXJnZXN0IHZhbHVlIChhcyBkZXNjcmliZWQgaW4gVGFibGUgMSkgaW4NCiAgIHRoZSB2YWxpZGF0 aW9uIHJlc3VsdCBmaWVsZCBhbmQgZGlzcmVnYXJkIHRoZSBvdGhlciB2YWx1ZXMuICBWYWx1ZXMN CiAgIGxhcmdlciB0aGFuIHR3byBpbiB0aGUgdmFsaWRhdGlvbiByZXN1bHQgZmllbGQgTVVTVCBi ZSBkaXNyZWdhcmRlZC4NCg0KVGhpcyBpcyBkaWZmZXJlbnQgZnJvbSB3aGF0IHdhcyBkZXNjcmli ZWQgdmVyYmFsbHkuIFRoZSB3cml0dGVuIHZlcnNpb24gc2VlbXMgZmluZSB0byBtZS4gU28sIEkg d291bGQgbGlrZSB0byB3aXRoZHJhdyBteSBjb21tZW50Lg0KDQpJIGRvIHN1Z2dlc3QgY2hhbmdp bmcgYm90aCBTSE9VTEQgdG8gTVVTVCB1bmxlc3MgeW91IGNhbiB0aGluayBvZiBhIHVzZSBjYXNl IGZvciBkb2luZyBkaWZmZXJlbnRseTsgaWYgeW91IGNhbiBJIHN1Z2dlc3QgYWRkaW5nIGEgTUFZ IGNsYXVzZSB0byBkZXNjcmliZSB0aGUgZXhjZXB0aW9uIGNhc2UuDQoNClRoYW5rcywNCg0K4oCU Sm9obg== From nobody Tue Jul 23 13:16:33 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 194DD120910; Tue, 23 Jul 2019 13:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov 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 Sy18CWIHdngS; Tue, 23 Jul 2019 13:16:25 -0700 (PDT) Received: from GCC01-CY1-obe.outbound.protection.outlook.com (mail-eopbgr830091.outbound.protection.outlook.com [40.107.83.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D11912097B; Tue, 23 Jul 2019 13:16:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=s6Eg3ike46M9D+XWvgY/wDJGNRCpc36q7FWtxytdZ9In0pcs9/Lyvmbuf/ZrCntslbLDLrMlRpnhWtcXw3HY5y8JL8JKXYHjfkDdlhCSu/u3B+5J1JXA9pKpqNj6Uyy0G1lkeBGRHMJErQ3koDJMJkPhPdyNDXbt9XgmbnYtSkc= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=a421CNux6xpmCQcFhFzMSc+aRuQeyrModus0Isj7OIc=; b=kB/N72aer1JvAB7iPuSY8uXhn9XXW63hh1wcJDYqNBDVs+5mX3SqSW5LgTS3MNmmQZ7CbjR6UezPKZ+QW9xenPi7fxnp/IIQCs1dLYgjsaoBZ7VsRvZXrH/nZR74A+0SatOiJXsPosw2p73z5ihJrTOJeX1od5jajfxSKkrXsuM= ARC-Authentication-Results: i=1; test.office365.com 1;spf=none;dmarc=none;dkim=none;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=a421CNux6xpmCQcFhFzMSc+aRuQeyrModus0Isj7OIc=; b=jWAqMxRmWWCtObqOvIEl5ulEFJn5sLjB/02Gr/ovQ880BZUoqDoKEDiDWQBuHHq54NpifySOYmc0xjFBTGLCPwTC08ue1U13SmtpaqffdSUwb0I4zYiZxqrBF19Vigi2ncJeDyxx0bZWljmHxVjbdYKBed+hUueCPEwZcVR1ORM= Received: from BN7PR09MB2596.namprd09.prod.outlook.com (52.135.255.12) by BN7PR09MB2596.namprd09.prod.outlook.com (52.135.255.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.16; Tue, 23 Jul 2019 20:16:23 +0000 Received: from BN7PR09MB2596.namprd09.prod.outlook.com ([fe80::a073:b2d8:358d:ab15]) by BN7PR09MB2596.namprd09.prod.outlook.com ([fe80::a073:b2d8:358d:ab15%7]) with mapi id 15.20.2008.014; Tue, 23 Jul 2019 20:16:23 +0000 From: "Montgomery, Douglas (Fed)" To: John Scudder , "draft-ietf-sidrops-validating-bgp-speaker@ietf.org" CC: "sidrops@ietf.org" Thread-Topic: [Sidrops] Multiple origin validation states in draft-ietf-sidrops-validating-bgp-speaker Thread-Index: AQHVQZN/uAi/HjY/skm0X8KG3/dHkQ== Date: Tue, 23 Jul 2019 20:16:23 +0000 Message-ID: <381E492B-BE40-4AAE-B581-FC3CB90C7A38@nist.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.c.190715 authentication-results: spf=none (sender IP is ) smtp.mailfrom=dougm@nist.gov; x-originating-ip: [31.133.158.224] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 90e8f470-ee51-445a-c3e9-08d70faaa225 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:BN7PR09MB2596; x-ms-traffictypediagnostic: BN7PR09MB2596: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0107098B6C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(366004)(346002)(39860400002)(136003)(376002)(189003)(199004)(6512007)(110136005)(6306002)(6116002)(186003)(316002)(102836004)(58126008)(66066001)(3846002)(8936002)(2501003)(36756003)(81156014)(99286004)(6246003)(14444005)(256004)(81166006)(86362001)(71190400001)(76116006)(91956017)(71200400001)(2906002)(25786009)(66476007)(476003)(66946007)(6486002)(45080400002)(229853002)(66446008)(66556008)(64756008)(14454004)(26005)(4326008)(6436002)(33656002)(5660300002)(478600001)(2616005)(6506007)(68736007)(486006)(966005)(305945005)(8676002)(53936002)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN7PR09MB2596; H:BN7PR09MB2596.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: mRortVP2SEMQNZ9Yr2RRHkGXjXZBKVt5NHxoCBDUNPI+4+dMa+rmTHanAoBziHRbpgSSQ0Q+IFudKKNBG91OiE9nD43W+utwVMZCSWA8SjGVBfilGlkpGUGIjTjXzcf+WPPbhsngDLndyyN1xaUURYE01cmi+GS0X9rLUoh/kxJfBEXzGNPsqS1iM7FymNFPX7Fj/GTkvsPSqdjHHRg2aTN2S/AvrXRmKab2AK32Co+URS286pzawT9HXczF/RkOETygR6Qvu23Gj35sPZhHKcMzTb5y53y1r43q0TuIcCOdjQbv3ZdppZ3iqy/WljPVbe6quuKAjJ6Dziwatkg2PeHMxb5gteNOXE00P7O09NdXcvZ+gR1WouYajTw059tU9WUkfVQgFWJ+ZOW2pefo6D0D3igP0DBXODwdjqmWSJw= Content-Type: text/plain; charset="utf-8" Content-ID: <32B1707E76F34C46954FBB259913E3DC@namprd09.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 90e8f470-ee51-445a-c3e9-08d70faaa225 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jul 2019 20:16:23.3006 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: dougm@nist.gov X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR09MB2596 Archived-At: Subject: Re: [Sidrops] Multiple origin validation states in draft-ietf-sidrops-validating-bgp-speaker X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 20:16:28 -0000 U28gd2UgYXJlIHRhbGtpbmcgYWJvdXQgYSBzaW5nbGUgdXBkYXRlIGNvbnRhaW5pbmcgdHdvIGlu c3RhbmNlcyBvZiB0aGUgdmFsaWRhdGlvbiByZXN1bHQgY29tbXVuaXR5PyAgIA0KDQpOb3csIEkg cmVhbGx5IHdvbmRlciBob3cgdGhpcyBjYW4gaGFwcGVuPyAgIA0KDQpJc24ndCB0aGlzIGEgc2ln biB0aGF0IHRoZSBSUyBpcyBlaXRoZXIgKGEpIGJyb2tlbiBhbmQgaW5zZXJ0aW5nIHR3byByZXN1 bHRzIGl0c2VsZiwgb3IgKGIpIHRoZSBSUyBpcyBpZ25vcmluZyB0aGUgcmVxdWlyZW1lbnQgdG8g c3RyaXAgdGhlIGNvbW11bml0eSB1cG9uIHJlY2VpcHQ/DQoNCmRvdWdtDQotLS0gDQpEb3VnIE1v bnRnb21lcnkgQCBOSVNUIC8gSVRMIC8gQU5URCAgDQoNCu+7v09uIDcvMjMvMTksIDQ6MTEgUE0s ICJTaWRyb3BzIG9uIGJlaGFsZiBvZiBKb2huIFNjdWRkZXIiIDxzaWRyb3BzLWJvdW5jZXNAaWV0 Zi5vcmcgb24gYmVoYWxmIG9mIGpncz00MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnPiB3cm90 ZToNCg0KICAgIE15IGNvbW1lbnQgYXQgdGhlIG1pYyB3YXMgYmFzZWQgb24gdGhlIHZlcmJhbCBk ZXNjcmlwdGlvbiBvZiB0aGUgc2xpZGUuIFdoYXQgSSBzZWUgaW4gdGhlIGRyYWZ0IHRleHQgaXMg ZGlmZmVyZW50Og0KICAgIA0KICAgIDUuNC4gIEVycm9yIEhhbmRsaW5nIGF0IFBlZXJzDQogICAg DQogICAgICAgQSByb3V0ZSBzZW50IGJ5IGEgdmFsaWRhdGluZyBCR1Agc3BlYWtlciBTSE9VTEQg b25seSBjb250YWluIG5vbmUgb3INCiAgICAgICBvbmUgRUJHUCBQcmVmaXggT3JpZ2luIFZhbGlk YXRpb24gU3RhdGUgTGFyZ2UgQ29tbXVuaXR5Lg0KICAgIA0KICAgICAgIEEgcGVlciByZWNlaXZp bmcgYSByb3V0ZSBmcm9tIGEgdmFsaWRhdGluZyBCR1Agc3BlYWtlciBjb250YWluaW5nDQogICAg ICAgbW9yZSB0aGFuIG9uZSBFQkdQIFByZWZpeCBPcmlnaW4gVmFsaWRhdGlvbiBTdGF0ZSBMYXJn ZSBDb21tdW5pdHkNCiAgICAgICBTSE9VTEQgb25seSBjb25zaWRlciB0aGUgbGFyZ2VzdCB2YWx1 ZSAoYXMgZGVzY3JpYmVkIGluIFRhYmxlIDEpIGluDQogICAgICAgdGhlIHZhbGlkYXRpb24gcmVz dWx0IGZpZWxkIGFuZCBkaXNyZWdhcmQgdGhlIG90aGVyIHZhbHVlcy4gIFZhbHVlcw0KICAgICAg IGxhcmdlciB0aGFuIHR3byBpbiB0aGUgdmFsaWRhdGlvbiByZXN1bHQgZmllbGQgTVVTVCBiZSBk aXNyZWdhcmRlZC4NCiAgICANCiAgICBUaGlzIGlzIGRpZmZlcmVudCBmcm9tIHdoYXQgd2FzIGRl c2NyaWJlZCB2ZXJiYWxseS4gVGhlIHdyaXR0ZW4gdmVyc2lvbiBzZWVtcyBmaW5lIHRvIG1lLiBT bywgSSB3b3VsZCBsaWtlIHRvIHdpdGhkcmF3IG15IGNvbW1lbnQuDQogICAgDQogICAgSSBkbyBz dWdnZXN0IGNoYW5naW5nIGJvdGggU0hPVUxEIHRvIE1VU1QgdW5sZXNzIHlvdSBjYW4gdGhpbmsg b2YgYSB1c2UgY2FzZSBmb3IgZG9pbmcgZGlmZmVyZW50bHk7IGlmIHlvdSBjYW4gSSBzdWdnZXN0 IGFkZGluZyBhIE1BWSBjbGF1c2UgdG8gZGVzY3JpYmUgdGhlIGV4Y2VwdGlvbiBjYXNlLg0KICAg IA0KICAgIFRoYW5rcywNCiAgICANCiAgICDigJRKb2huDQogICAgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBTaWRyb3BzIG1haWxpbmcgbGlzdA0K ICAgIFNpZHJvcHNAaWV0Zi5vcmcNCiAgICBodHRwczovL2djYzAxLnNhZmVsaW5rcy5wcm90ZWN0 aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFu JTJGbGlzdGluZm8lMkZzaWRyb3BzJmFtcDtkYXRhPTAyJTdDMDElN0Nkb3VnbSU0MG5pc3QuZ292 JTdDMDVkNzkzMzBiZDA0NGIwMWUzOGQwOGQ3MGZhOWY0MGUlN0MyYWI1ZDgyZmQ4ZmE0Nzk3YTkz ZTA1NDY1NWM2MWRlYyU3QzElN0MxJTdDNjM2OTk1MDk0OTM4OTg3MDA0JmFtcDtzZGF0YT1mMkdi R05KS3BIUjRhNlJibFROWWZDZFRXWVZ5WGlFWVZaT2RWWGFkcVAwJTNEJmFtcDtyZXNlcnZlZD0w DQogICAgDQoNCg== From nobody Tue Jul 23 13:18:32 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03CCE120943 for ; Tue, 23 Jul 2019 13:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.com 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 JXJCd6Gn9Y6J for ; Tue, 23 Jul 2019 13:18:28 -0700 (PDT) Received: from mail-ot1-x343.google.com (mail-ot1-x343.google.com [IPv6:2607:f8b0:4864:20::343]) (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 677F012039B for ; Tue, 23 Jul 2019 13:18:28 -0700 (PDT) Received: by mail-ot1-x343.google.com with SMTP id 60so5861266otr.7 for ; Tue, 23 Jul 2019 13:18:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=q2FH9ygTYP4bGmmAWbZOVsau0whOeuWdBdGudhH9PGU=; b=fYAqudv6O3BF4ol1jQkkD1H8Ab+VSp6aWhJyu83ZWt1DaPGiaNcZZmzzStciQiOcg4 Gd83XvNUA6CzbYMNZIvu1Ip4rF351aqhvSBYXskR5TblvPAt6NtYsKKXR5eAjSfY8NB9 4XR4gNXpBGLue7U4+gA121fAUhAEEHDC7Ge2pwXoQK/jGGKwEbTgB/gaGzg9+sFT+xSG O+QsrCxVttZbGSN8s24K6sA2YvbjeVVIPjYn/WJqLb+CESyiWTcSRjzfTBUdwEL8/IXW 6LWyzYE2hDTwSJycfSGkpOetxq4ApKPRag9l5IvEWQcE9BySxNrhLFNqpqc/5IlFupbb TWIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=q2FH9ygTYP4bGmmAWbZOVsau0whOeuWdBdGudhH9PGU=; b=N1/ow8OazdsPYmwng8bZiixcx/jIVw00Z7YrrXYgPCaiEHPq/lceuwA/gg85rIqhcm D0tMZ74vyvhE68hgOC5oOzVqKIigCIPq++trouS56eZkxctG3MSamMLygArq/DPrVu0G Dkrdusky803VpQ8d42kChL3siPv/LH0N2QG7bDMK8nHCPmnrirYEp0Wma5g0w5J0kEgi G0rzvjHlWEVR0HLm+CKEHYY6rJBBUxb4s/QUBJOIlea1ynMIfwbO/I1Jx5EcJHeAk7dZ jtCDxE9c36x+A5mAMxNilwFCfn/CkF/k2yBZ+4UL34mNFlm/vTjSCX4KgO/rcwbqz3EL yWWA== X-Gm-Message-State: APjAAAWk6flHo6eLW1dYo53einetgEPQ7Naeyy1j7qfs70LEOEfziG3o mCsblSVxKemPyYfq+ratUD2roVDlfa/L6fXY39I= X-Google-Smtp-Source: APXvYqzXzYGOypodT3wFTw8he8q3m2lZI5p1vQch5685pC9AJyYBPo4AfqbhlPIpHg4Xz9/Rw/dLcZPdXi68HtBUUcY= X-Received: by 2002:a05:6830:1249:: with SMTP id s9mr59204334otp.33.1563913107534; Tue, 23 Jul 2019 13:18:27 -0700 (PDT) MIME-Version: 1.0 References: <381E492B-BE40-4AAE-B581-FC3CB90C7A38@nist.gov> In-Reply-To: <381E492B-BE40-4AAE-B581-FC3CB90C7A38@nist.gov> From: Job Snijders Date: Tue, 23 Jul 2019 20:18:15 +0000 Message-ID: To: "Montgomery, Douglas (Fed)" Cc: John Scudder , "draft-ietf-sidrops-validating-bgp-speaker@ietf.org" , "sidrops@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Sidrops] Multiple origin validation states in draft-ietf-sidrops-validating-bgp-speaker X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 20:18:30 -0000 On Tue, Jul 23, 2019 at 8:16 PM Montgomery, Douglas (Fed) wrote: > > So we are talking about a single update containing two instances of the validation result community? > > Now, I really wonder how this can happen? > > Isn't this a sign that the RS is either (a) broken and inserting two results itself, or (b) the RS is ignoring the requirement to strip the community upon receipt? Or it didn't come from the route server, or the route server just passed it on. We can't know from the BGP session itself whether the route server does validation, and we can't know where the route server got its routing information from. We can't really trust it. Kind regards, Job From nobody Tue Jul 23 13:37:11 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236C312096F for ; Tue, 23 Jul 2019 13:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 dFPeWdLI-YqC for ; Tue, 23 Jul 2019 13:37:07 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACB77120950 for ; Tue, 23 Jul 2019 13:37:07 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1hq1Wz-0001Ah-BE for sidrops@ietf.org; Tue, 23 Jul 2019 20:37:05 +0000 Date: Tue, 23 Jul 2019 16:37:05 -0400 Message-ID: From: Randy Bush To: SIDR Operations WG User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.2 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: [Sidrops] draft-ymbk-sidrops-ov-egress X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 20:37:10 -0000 request wg adoption of draft-ymbk-sidrops-ov-egress randy From nobody Tue Jul 23 13:38:00 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D76C6120967 for ; Tue, 23 Jul 2019 13:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 K88uwEhops6g for ; Tue, 23 Jul 2019 13:37:56 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 061E2120950 for ; Tue, 23 Jul 2019 13:37:56 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1hq1Xn-0001Aw-2M for sidrops@ietf.org; Tue, 23 Jul 2019 20:37:55 +0000 Date: Tue, 23 Jul 2019 16:37:54 -0400 Message-ID: From: Randy Bush To: SIDR Operations WG User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.2 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: [Sidrops] draft-ymbk-sidrops-ov-signal X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 20:37:58 -0000 request wg adoption of draft-ymbk-sidrops-ov-signal randy From nobody Tue Jul 23 13:48:17 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 480C212098D for ; Tue, 23 Jul 2019 13:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net 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 URuHAYjkWyCz for ; Tue, 23 Jul 2019 13:48:04 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DD42120986 for ; Tue, 23 Jul 2019 13:48:04 -0700 (PDT) Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x6NKipV3006042 for ; Tue, 23 Jul 2019 13:48:03 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=hqF7pulenUuBqpXAuTrwOB2X4Srb+Ap46Zj6RS8EiiU=; b=JSvvuhoNL/tAytPd3z952UitThtvllu0Ud97cxZpeNzKIhty4iuOYxkWk4oUHo4Lgh7U XdQWZAPndbJE4nEEzrxG7E+nL6qSJCcT4GVLWwrWqsn6VFKZoa52gfi3In6Tw0Wq0638 3Fiehr3O0GmL/0EoIfLPAmkUZxsHIngIGdBIIX+wkQEQy8zFSDi/jVjSYO0lf5LBBHR0 NBLS2OQu6NRTeisKA/DTEasMxwmEOqXFX9ofwb8qH0MOVfIvtBUakih5gdUT4alqLXra n/v8hDpZ9xVR7O60pQROYsGEGLf2WeShywZpuuiKrt5Qjz246VH0FQE3Bh6BycdToKda LQ== Received: from nam03-dm3-obe.outbound.protection.outlook.com (mail-dm3nam03lp2055.outbound.protection.outlook.com [104.47.41.55]) by mx0b-00273201.pphosted.com with ESMTP id 2tx61k0dc3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 23 Jul 2019 13:48:03 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fSd+Xj19UH4o25DcVepWKU8JhtUF+e9fnS136MFMyNQQBPS3VOWK5BcviG6U0UrxpT4i37QMzfXaEgDG/LTiwzIavyRtoChlH2f285vMpAk6XQ9+2YKgrnn6EYIWnSYA9HGoaEwPgrUOO4oYHLoZXH4YuAMqkkzxtlz2JsdA8/lTp3cXeSF69XKNGo97+s69Z4beBcKiInguztRmSZg0iRv5anvBlmQDLnqrYs1goNpslrHzQiDMj4lPYMCFkfjZg5eMVVMxooGQV4x+vdignHR6co3466p3k1cj0SGY2+t2EZiaff9WX1rJ7S7edVEcs1bVGopJx8tlpR/sN+O5dA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hqF7pulenUuBqpXAuTrwOB2X4Srb+Ap46Zj6RS8EiiU=; b=k0Z4qcomngCq1AC8qbIJWiHH+xQfu2JclBFtUxneLVk4UBLsevzGAffMI0wek3YhGf0nlv8np/vYeZUHxD0nuEcqT4Fnh9OOOW3H7ED4rCd66JnhuAH6+AJvrob2ttUIJ5FRz4ESiN5QIx32f+Sh6moHpHCFjMyEldK3Q98QG30f4N1ujF5Kz/J9MQkHuXuNBYG88s8AjxLFdi7sA88Quc3dh21w6q5G9dMr/anZrWEOsJHYZHnE5Hs8fnQ1zd2hFtL5F0PYKGJwmaLcH9TKJSMFy6CHeIfwrZ+K2vhnAe6kY+d+SxPtS/xXUIoM0O9wom0eubZs/9b0WvgI4eZhPw== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=juniper.net;dmarc=pass action=none header.from=juniper.net;dkim=pass header.d=juniper.net;arc=none Received: from DM6PR05MB4714.namprd05.prod.outlook.com (20.176.110.82) by DM6PR05MB5737.namprd05.prod.outlook.com (20.178.24.210) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2115.10; Tue, 23 Jul 2019 20:48:01 +0000 Received: from DM6PR05MB4714.namprd05.prod.outlook.com ([fe80::64b6:144d:5560:9148]) by DM6PR05MB4714.namprd05.prod.outlook.com ([fe80::64b6:144d:5560:9148%5]) with mapi id 15.20.2115.005; Tue, 23 Jul 2019 20:48:01 +0000 From: John Scudder To: "sidrops@ietf.org" Thread-Topic: draft-ymbk-sidrops-ov-signal-02 Thread-Index: AQHVQZfqdZEC8Ka1Vk6EHyhMX0ZkLw== Date: Tue, 23 Jul 2019 20:48:01 +0000 Message-ID: <77600356-557E-43F6-82AB-5AFFB830B984@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.10] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f4fe7e6d-0b18-4989-9529-08d70faf0d46 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:DM6PR05MB5737; x-ms-traffictypediagnostic: DM6PR05MB5737: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0107098B6C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(4636009)(346002)(136003)(396003)(366004)(39860400002)(376002)(199004)(189003)(33656002)(76116006)(64756008)(14444005)(91956017)(256004)(66556008)(99286004)(71190400001)(561944003)(66476007)(6116002)(316002)(1730700003)(2351001)(486006)(2906002)(66946007)(66446008)(3846002)(71200400001)(6486002)(81166006)(81156014)(8936002)(6506007)(186003)(478600001)(7736002)(6512007)(26005)(5660300002)(36756003)(2616005)(305945005)(25786009)(66066001)(8676002)(2501003)(476003)(53936002)(68736007)(6916009)(6436002)(86362001)(102836004)(5640700003)(14454004)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB5737; H:DM6PR05MB4714.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: dEdMrhetwQzKKf/4pYLmUMS5NAcLp6E00QhAx2SJVCZaIPKH97ivPxq0zQth0ekSxnlu6rLLpyPoXImiIWHdvv5Anm6uyl6quiPcBscB8yjgw1bABY1PrdzeTqYZ1ypauDQfalSsS/wuBtCpebpnhn8cjaTQraGD9g5ieX0y0cFgouiBFA3zMkhx5awZ3qA+OOAkKHrxjxUnxVLfHUYAn+ESKCfiT6Bw+Vc656nIBf2ICiGb9dinvsHQJ9oSFT3yUx2+fMVtp4EHN8PkSQWA91QAHe4zyz5HNlmKh/1s1vjS/hEXUqWCF6AcQGNGXOVZKOuAZIRYj4vmyXsdrMVQ9KYCA+/ZVnoXSLFui86KRKsi1bK4apGhb8asiqpd6rgOn5ZlL9DhfoqiDgCZx0oxg0Ecbhd9nbplK3liv4NoeC4= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: f4fe7e6d-0b18-4989-9529-08d70faf0d46 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jul 2019 20:48:01.1358 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jgs@juniper.net X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB5737 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-23_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=2 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=2 clxscore=1015 lowpriorityscore=0 mlxscore=2 impostorscore=0 mlxlogscore=164 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1907230209 Archived-At: Subject: [Sidrops] draft-ymbk-sidrops-ov-signal-02 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 20:48:16 -0000 VGhpbmdzIEkgd291bGQgaGF2ZSBzYWlkIGF0IHRoZSBtaWMgaGFkIHRpbWUgYWxsb3dlZDoNCg0K MS4gRm9yIHdoYXQgaXTigJlzIHdvcnRoLCBSRkMgNDI3MSBzZWN0aW9uIDkuMSBzYXlzIHlvdSBh cmVu4oCZdCBhbGxvd2VkIHRvIGhhdmUgdGhpcyBmZWF0dXJlOg0KDQogICBUaGUgZnVuY3Rpb24g dGhhdCBjYWxjdWxhdGVzIHRoZSBkZWdyZWUgb2YgcHJlZmVyZW5jZSBmb3IgYSBnaXZlbg0KICAg cm91dGUgU0hBTEwgTk9UIHVzZSBhbnkgb2YgdGhlIGZvbGxvd2luZyBhcyBpdHMgaW5wdXRzOiB0 aGUgZXhpc3RlbmNlDQogICBvZiBvdGhlciByb3V0ZXMsIHRoZSBub24tZXhpc3RlbmNlIG9mIG90 aGVyIHJvdXRlcywgb3IgdGhlIHBhdGgNCiAgIGF0dHJpYnV0ZXMgb2Ygb3RoZXIgcm91dGVzLiAg Um91dGUgc2VsZWN0aW9uIHRoZW4gY29uc2lzdHMgb2YgdGhlDQogICBpbmRpdmlkdWFsIGFwcGxp Y2F0aW9uIG9mIHRoZSBkZWdyZWUgb2YgcHJlZmVyZW5jZSBmdW5jdGlvbiB0byBlYWNoDQogICBm ZWFzaWJsZSByb3V0ZSwgZm9sbG93ZWQgYnkgdGhlIGNob2ljZSBvZiB0aGUgb25lIHdpdGggdGhl IGhpZ2hlc3QNCiAgIGRlZ3JlZSBvZiBwcmVmZXJlbmNlLg0KDQpBcyBJIHVuZGVyc3RhbmQgc2Vj dGlvbiA1IG9mIHRoZSBkcmFmdCAoYXMgaW5mb3JtZWQgYnkgUmFuZHnigJlzIGRlc2NyaXB0aW9u KSwgaXQgaXMgZXhhY3RseSBtYW5kYXRpbmcgdGhhdCB3ZSB1c2UgdGhlIHBhdGggYXR0cmlidXRl cyBvZiBvdGhlciByb3V0ZXMgZm9yIHRoZSBjb21wdXRhdGlvbiBvZiB0aGUgZGVncmVlIG9mIHBy ZWZlcmVuY2UuDQoNCjIuIEFzc3VtaW5nIHdlIG92ZXJjb21lIHRoYXQgcHJvYmxlbSwgdGhlcmUg YXBwZWFycyB0byBiZSBhIHN0YWJpbGl0eSBhbmQvb3IgZnJlc2huZXNzIGlzc3VlOg0KDQotIFJS IGNsaWVudCBDIGFkdmVydGlzZXMgcm91dGUgQSB0byBSUg0KLSBSUiBjaGVja3MgQSwgZGVjaWRl cyBpdCBpcyBpbnZhbGlkIA0KLSBSUiBhZHZlcnRpc2VzIEEsIG1hcmtlZCBpbnZhbGlkLCBiYWNr IHRvIEMuIENhbGwgdGhpcyBB4oCZLiANCi0gQyBvYmV5cyBzZWN0aW9uIDUgYW5kIHdpdGhkcmF3 cyBBIGZyb20gZXZlcnlvbmUgKGluY2x1ZGluZyBSUikNCi0gRm9sbG93aW5nIHRoZSBub3JtYWwg b3BlcmF0aW9uIG9mIEJHUCwgUlIgd2l0aGRyYXdzIEEnIGZyb20gZXZlcnlvbmUgKGluY2x1ZGlu ZyBDKQ0KLSBOb3cgQeKAmSBpcyBub3QgaW4gQ+KAmXMgQWRqLVJJQi1JbiwgYnV0IEEgaXMuIEkg YmVsaWV2ZSB3aGF0IEtleXVyIHNhaWQgb24gdGhlIG1pYyB3YXMgdGhhdCBDIGlzIHN1cHBvc2Vk IHRvIGhhdmUgcGVyc2lzdGVudGx5IG1hcmtlZCBBIGFzIGludmFsaWQgaW4gdGhlIGVhcmxpZXIg c3RlcCwgcGF0Y2hpbmcgdGhlIG9idmlvdXMgc3RhYmlsaXR5IHByb2JsZW0uDQotIE5vdyBzdXBw b3NlIHRoZSBjb250ZW50IG9mIHRoZSBSUEtJIGNoYW5nZXMgc3VjaCB0aGF0IEEgaXMgbm93IHZh bGlkLg0K4oCmIGhvdyBkb2VzIEEgZXZlciBmaW5kIHRoaXMgb3V0IGFuZCB1bi1zdXBwcmVzcyBB PyBBcyBmYXIgYXMgSSBjYW4gdGVsbCwgdGhlIGFuc3dlciBpcywg4oCcaXQgZG9lc27igJl04oCd LiBSUiBuZXZlciBzZWVzIGEgcmUtYW5ub3VuY2VtZW50IG9mIEEsIHNvIGl0IGNhbuKAmXQgcmUt dmFsaWRhdGUgYW5kIGFubm91bmNlIGl0IHRvIGJlIHZhbGlkLiBTbyBpdOKAmXMganVzdCB3ZWRn ZWQuDQoNCjMuIEZpbmFsbHksIHNvbWVvbmUgY29tbWVudGVkIGF0IHRoZSBtaWMgdGhhdCB0aGUg d29yayB0byB0dXJuIHZhbGlkYXRpb24gb24gYXQgQyBpcyBsZXNzIHRoYW4gdGhlIHdvcmsgdG8g ZGVidWcsIGltcGxlbWVudCwgYW5kIGRlcGxveSB0aGlzIHByb3Bvc2FsLiBJIGFncmVlLg0KDQpH aXZlbiB0aGUgYWJvdmUsIEnigJltIG5vdCBpbiBmYXZvciBvZiBhZG9wdGlvbiAodGhvdWdoIEni gJltIGFsd2F5cyB3aWxsaW5nIHRvIGJlIGNvbnZpbmNlZCkuDQoNClRoYW5rcywNCg0K4oCUSm9o bg== From nobody Tue Jul 23 13:59:58 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F37112039B for ; Tue, 23 Jul 2019 13:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.com 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 Fg5kOtEJM6kE for ; Tue, 23 Jul 2019 13:59:55 -0700 (PDT) Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) (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 87DC7120159 for ; Tue, 23 Jul 2019 13:59:55 -0700 (PDT) Received: by mail-oi1-x22a.google.com with SMTP id a127so33373064oii.2 for ; Tue, 23 Jul 2019 13:59:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=pGCfyedOs6gHqH+lm5jjigG9UYvOEYO3dW+/XDYlUYI=; b=csYrgHn+k0D+D0kIEako9PsgkGCf55twyK2PfJHF/mGb2/bJVu9Shk5EbVTcx5hMkt n1XpXPYqXigkVWknXVrwUpQQFkqZTtZU1z+krjW5xspXaGWpGh8CXmdPFoywT1YeOP3U AkPszX2dpY2bN8hmKHiMgLuAKoAmnvQZi4TOj/xA7pRxaeG8XK8NkeCCcjXIwRbW9Qo8 cTtstoElc8MMpvpNZqyPn7SHHkKdyaESG7Vaj9mOb/dDeWxqKsyv1jS2ojNgkUkxy7UX UesMPWkYw6n+7Hd98Xb3JUnwWR2sUiMfKmAG6G6Z3oBuY0FE0lGGKozZAgihfwu/cCSU R8hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=pGCfyedOs6gHqH+lm5jjigG9UYvOEYO3dW+/XDYlUYI=; b=taalwg8XW2r1nT515IrqGO6ScdA7HtSmkA8e8DKS3qV7lnZ1162h25vKyARrCE5cxO ZNtL+bIaT7buw1QOR4/aKF/D/bY73pa0q028rOY757ysehGPFgoHgKVwyfrHWgoDHnM/ OjdX68JMh3dTu0cEX1dzEwBDdJZkcFvn+RV0jvH/SOv81UFt9hdbFwNa+Ved0y3ut+KA 2SOwFvy2atgijsbmcUQBVToOcU1UqRsdEG1VHahu2OvmCtVMphTezt3SgyjotykFCDBj kLtcm2vLVt6p9buW501n7c8svwFTkvUoUqmJIjay+kl+agcVNErLlfyDWUixGvJqGetS d/8w== X-Gm-Message-State: APjAAAXNd4gBEpD5bd3xWu/vZybmPpxDVMSotyTJGNwkZqdFPIfNyZ5z 88sW5bTZjAGEp7674q6JqSSgdcE9/M4wwrvQEes= X-Google-Smtp-Source: APXvYqzvmnEUpTxnaN49l3GhUCFommwIwd45ccrfUIJJzpP+aRXHvvDRjcJSUWlVomXWPn4yQV6T2Sm95fcbqE1bt7Y= X-Received: by 2002:aca:dc86:: with SMTP id t128mr39420097oig.130.1563915594553; Tue, 23 Jul 2019 13:59:54 -0700 (PDT) MIME-Version: 1.0 References: <77600356-557E-43F6-82AB-5AFFB830B984@juniper.net> In-Reply-To: <77600356-557E-43F6-82AB-5AFFB830B984@juniper.net> From: Job Snijders Date: Tue, 23 Jul 2019 20:59:41 +0000 Message-ID: To: John Scudder Cc: "sidrops@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] draft-ymbk-sidrops-ov-signal-02 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 20:59:57 -0000 I have questions about this draft as well: Why not tunnel VRPs inside BGP in a new AFI to populate the origin validation cache on the edges? I think the BGP protocol has sufficient hooks to model the RTR protocol fairly closely. Or perhaps I don't understand the appeal of this mechanism. Why not use RTR? Or if there is no room on the edge router for the memory a VRP cache? If there is no room, can it even do Internet BGP? Kind regards, Job On Tue, Jul 23, 2019 at 8:48 PM John Scudder wrote: > > Things I would have said at the mic had time allowed: > > 1. For what it=E2=80=99s worth, RFC 4271 section 9.1 says you aren=E2=80= =99t allowed to have this feature: > > The function that calculates the degree of preference for a given > route SHALL NOT use any of the following as its inputs: the existence > of other routes, the non-existence of other routes, or the path > attributes of other routes. Route selection then consists of the > individual application of the degree of preference function to each > feasible route, followed by the choice of the one with the highest > degree of preference. > > As I understand section 5 of the draft (as informed by Randy=E2=80=99s de= scription), it is exactly mandating that we use the path attributes of othe= r routes for the computation of the degree of preference. > > 2. Assuming we overcome that problem, there appears to be a stability and= /or freshness issue: > > - RR client C advertises route A to RR > - RR checks A, decides it is invalid > - RR advertises A, marked invalid, back to C. Call this A=E2=80=99. > - C obeys section 5 and withdraws A from everyone (including RR) > - Following the normal operation of BGP, RR withdraws A' from everyone (i= ncluding C) > - Now A=E2=80=99 is not in C=E2=80=99s Adj-RIB-In, but A is. I believe wh= at Keyur said on the mic was that C is supposed to have persistently marked= A as invalid in the earlier step, patching the obvious stability problem. > - Now suppose the content of the RPKI changes such that A is now valid. > =E2=80=A6 how does A ever find this out and un-suppress A? As far as I ca= n tell, the answer is, =E2=80=9Cit doesn=E2=80=99t=E2=80=9D. RR never sees = a re-announcement of A, so it can=E2=80=99t re-validate and announce it to = be valid. So it=E2=80=99s just wedged. > > 3. Finally, someone commented at the mic that the work to turn validation= on at C is less than the work to debug, implement, and deploy this proposa= l. I agree. > > Given the above, I=E2=80=99m not in favor of adoption (though I=E2=80=99m= always willing to be convinced). > > Thanks, > > =E2=80=94John > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Tue Jul 23 14:15:46 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA3831209D4; Tue, 23 Jul 2019 14:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 iIaC7gmP_t3y; Tue, 23 Jul 2019 14:15:34 -0700 (PDT) Received: from de-cix.net (relay4.de-cix.net [46.31.121.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A1221209BD; Tue, 23 Jul 2019 14:15:34 -0700 (PDT) IronPort-SDR: wuRoO7bP1TnWB3c5G5cYGWkbyCLwWP0VXRrDCxro+0IKZm/Tso4PS4nXOJWrYJqGn9x1r3+HBI QBf8/MYQoR2uBMqhnvXEp0ijqdVDjD2KsXQkvHP4tqZvusgRDreXBrPOnQ3uAB0HCTZVjwSMmW Ccs2NuSeXnMOP2h/1osSdIt3JZOJ5b+MDXH2hF9EcFQBr6xdRpJ9nOj15MBhSAaVoECfyC1rAq DpszsK3GkZbHqWKDfAnCdRqASdyhJ84dco+1zCFEhRz8CCKVaFw3p+Fybl5VdvlhqMEt177aT/ Tko= X-IronPort-AV: E=Sophos;i="5.64,300,1559512800"; d="scan'208";a="8830502" Received: from unknown (HELO smtp.de-cix.net) ([192.168.65.10]) by mailgw014.de-cix.net with ESMTP; 23 Jul 2019 23:13:13 +0200 Received: from EX02.for-the-inter.net (ex02.for-the-inter.net [192.168.49.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.de-cix.net (Postfix) with ESMTPS id 7AE4DB00B8; Tue, 23 Jul 2019 23:15:32 +0200 (CEST) Received: from EX02.for-the-inter.net (192.168.49.20) by EX02.for-the-inter.net (192.168.49.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1779.2; Tue, 23 Jul 2019 23:15:32 +0200 Received: from EX02.for-the-inter.net ([fe80::1cb2:801e:f870:7df9]) by EX02.for-the-inter.net ([fe80::1cb2:801e:f870:7df9%4]) with mapi id 15.01.1779.004; Tue, 23 Jul 2019 23:15:32 +0200 From: Daniel Kopp To: John Scudder CC: "draft-ietf-sidrops-validating-bgp-speaker@ietf.org" , "sidrops@ietf.org" Thread-Topic: [Sidrops] Multiple origin validation states in draft-ietf-sidrops-validating-bgp-speaker Thread-Index: AQHVQZK7YXV6PGo8cUeBqH/9As28x6bYkteA Date: Tue, 23 Jul 2019 21:15:32 +0000 Message-ID: <6D891976-1160-4329-8035-51DD954B835F@de-cix.net> References: <0B8E9A81-31FE-45BC-A01C-0D05E307EE0E@juniper.net> In-Reply-To: <0B8E9A81-31FE-45BC-A01C-0D05E307EE0E@juniper.net> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.6.18) x-originating-ip: [192.168.140.61] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Sidrops] Multiple origin validation states in draft-ietf-sidrops-validating-bgp-speaker X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 21:15:45 -0000 SGkgSm9obiwgDQoNCnRoYW5rcyBmb3IgcG9pbnRpbmcgdGhpcyBvdXQgYW5kIGNsYXJpZnlpbmcg eW91ciBjb21tZW50Lg0KDQpJ4oCZbSBzb3JyeSBmb3IgdGhlIGNvbmZ1c2lvbi4gSSB3YXMgdmVy YmFsbHkgaW50ZXJwcmV0aW5nIHRoZSBzZWN0aW9uIHRvIGV4dGVuc2l2ZSwgSSB0aGluayA6KQ0K QSB0YWxrZWQgdG8gdGhlIG90aGVyIGF1dGhvcnMgYW5kIGl0IHNlZW1zIHRoYXQgNS40IGlzIG1l YW50IHRvIGJlIGFuIGFkZGl0aW9uL3NpbWlsYXIgdG8gNS4yLg0KDQpTbyBldmVuIHRoYXQgdGhl IHJvdXRlIHNlcnZlciBtdXN0IHN0cmlwIGFueSBQcmVmaXggT3JpZ2luIFZhbGlkYXRpb24gU3Rh dGUgaXQgcmVjZWl2ZXMsDQo1LjQgc2VydmVzIGFzIGFuIGV4dHJhIHByb3RlY3Rpb24gaW4gY2Fz ZSB0aGluZ3MgZ28gd3JvbmcuDQoNCkxldCBtZSBrbm93IGlmIHlvdSB0aGluayB3ZSBzaG91bGQg cmVtb3ZlIDUuNC4NCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnQhDQpEYW5pZWwNCg0KPiBPbiAy My4gSnVsIDIwMTksIGF0IDIyOjEwLCBKb2huIFNjdWRkZXIgPGpncz00MGp1bmlwZXIubmV0QGRt YXJjLmlldGYub3JnPiB3cm90ZToNCj4gDQo+IE15IGNvbW1lbnQgYXQgdGhlIG1pYyB3YXMgYmFz ZWQgb24gdGhlIHZlcmJhbCBkZXNjcmlwdGlvbiBvZiB0aGUgc2xpZGUuIFdoYXQgSSBzZWUgaW4g dGhlIGRyYWZ0IHRleHQgaXMgZGlmZmVyZW50Og0KPiANCj4gNS40LiAgRXJyb3IgSGFuZGxpbmcg YXQgUGVlcnMNCj4gDQo+ICAgQSByb3V0ZSBzZW50IGJ5IGEgdmFsaWRhdGluZyBCR1Agc3BlYWtl ciBTSE9VTEQgb25seSBjb250YWluIG5vbmUgb3INCj4gICBvbmUgRUJHUCBQcmVmaXggT3JpZ2lu IFZhbGlkYXRpb24gU3RhdGUgTGFyZ2UgQ29tbXVuaXR5Lg0KPiANCj4gICBBIHBlZXIgcmVjZWl2 aW5nIGEgcm91dGUgZnJvbSBhIHZhbGlkYXRpbmcgQkdQIHNwZWFrZXIgY29udGFpbmluZw0KPiAg IG1vcmUgdGhhbiBvbmUgRUJHUCBQcmVmaXggT3JpZ2luIFZhbGlkYXRpb24gU3RhdGUgTGFyZ2Ug Q29tbXVuaXR5DQo+ICAgU0hPVUxEIG9ubHkgY29uc2lkZXIgdGhlIGxhcmdlc3QgdmFsdWUgKGFz IGRlc2NyaWJlZCBpbiBUYWJsZSAxKSBpbg0KPiAgIHRoZSB2YWxpZGF0aW9uIHJlc3VsdCBmaWVs ZCBhbmQgZGlzcmVnYXJkIHRoZSBvdGhlciB2YWx1ZXMuICBWYWx1ZXMNCj4gICBsYXJnZXIgdGhh biB0d28gaW4gdGhlIHZhbGlkYXRpb24gcmVzdWx0IGZpZWxkIE1VU1QgYmUgZGlzcmVnYXJkZWQu DQo+IA0KPiBUaGlzIGlzIGRpZmZlcmVudCBmcm9tIHdoYXQgd2FzIGRlc2NyaWJlZCB2ZXJiYWxs eS4gVGhlIHdyaXR0ZW4gdmVyc2lvbiBzZWVtcyBmaW5lIHRvIG1lLiBTbywgSSB3b3VsZCBsaWtl IHRvIHdpdGhkcmF3IG15IGNvbW1lbnQuDQo+IA0KPiBJIGRvIHN1Z2dlc3QgY2hhbmdpbmcgYm90 aCBTSE9VTEQgdG8gTVVTVCB1bmxlc3MgeW91IGNhbiB0aGluayBvZiBhIHVzZSBjYXNlIGZvciBk b2luZyBkaWZmZXJlbnRseTsgaWYgeW91IGNhbiBJIHN1Z2dlc3QgYWRkaW5nIGEgTUFZIGNsYXVz ZSB0byBkZXNjcmliZSB0aGUgZXhjZXB0aW9uIGNhc2UuDQo+IA0KPiBUaGFua3MsDQo+IA0KPiDi gJRKb2huDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IFNpZHJvcHMgbWFpbGluZyBsaXN0DQo+IFNpZHJvcHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaWRyb3BzDQoNCg== From nobody Tue Jul 23 14:38:11 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC201202E2; Tue, 23 Jul 2019 14:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 LEZop7uJsUdx; Tue, 23 Jul 2019 14:38:08 -0700 (PDT) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F14FF120949; Tue, 23 Jul 2019 14:38:07 -0700 (PDT) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1hq2U0-000f1i-Jk>; Tue, 23 Jul 2019 23:38:04 +0200 Received: from dhcp-9cc3.meeting.ietf.org ([31.133.156.195] helo=mw-x1.meeting.ietf.org) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1hq2Tz-003Xfb-Rl>; Tue, 23 Jul 2019 23:38:04 +0200 Date: Tue, 23 Jul 2019 17:38:01 -0400 (Eastern Sommerzeit) From: Matthias Waehlisch To: Daniel Kopp cc: John Scudder , "sidrops@ietf.org" , "draft-ietf-sidrops-validating-bgp-speaker@ietf.org" In-Reply-To: <6D891976-1160-4329-8035-51DD954B835F@de-cix.net> Message-ID: References: <0B8E9A81-31FE-45BC-A01C-0D05E307EE0E@juniper.net> <6D891976-1160-4329-8035-51DD954B835F@de-cix.net> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) X-X-Sender: waehl@mail.zedat.fu-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Originating-IP: 31.133.156.195 Archived-At: Subject: Re: [Sidrops] Multiple origin validation states in draft-ietf-sidrops-validating-bgp-speaker X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 21:38:10 -0000 On Tue, 23 Jul 2019, Daniel Kopp wrote: > Let me know if you think we should remove 5.4. > why? if you consider this a possible situation, you should discuss how to handle the error. personally, i tend to say ignore the validation outcome at all. it is an error. as Job wrote "We can't really trust it." Cheers matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl From nobody Tue Jul 23 15:33:16 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2BD1209F3; Tue, 23 Jul 2019 15:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net 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 gDC0171DA6YP; Tue, 23 Jul 2019 15:33:07 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BACF12098D; Tue, 23 Jul 2019 15:33:07 -0700 (PDT) Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x6NMU9tu008887; Tue, 23 Jul 2019 15:33:03 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=7nE1xRuA8y0HVVmz8zvp/wqkls5/D07DGZ+oNkf+0kc=; b=P26xurmo9lQ4VLQme8cp6S/JrB40KIPpfEtD32tNF1qcIhKwie3ZTlWRROgUOJGEy1RC gWmUccWcOgOLGe+hTbyHogie87A2YUkI2GW5MUwCoUHFtiF0t9pT2N/4iy4s8mMekCS8 rkHY38h1WhEm1A8HO8YrW9WIixFyL2SCqq/kJrO1Koz8ZV38cFVbsdOgVyMzqWVyKk8M BFgolX1DIM0f6jMBfBxRgDLTK25C+cLwoWiJSAwif4AeXKHBiF5Q5S7y2H6J6ak9/Wbr IGX1En1B7r+rosJULecw7vnlnhOWpTabDnAZ9hWyFQpWrtLMHBJ8vtO0wZFyyEsU+RUd 5A== Received: from nam04-co1-obe.outbound.protection.outlook.com (mail-co1nam04lp2054.outbound.protection.outlook.com [104.47.45.54]) by mx0a-00273201.pphosted.com with ESMTP id 2tx61mgksk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 23 Jul 2019 15:33:02 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HfuAbhjeTdHeJfmd0lOcW9k5/gV0wP8kbprylMleflKY6jkWElfnH4aeO/0057/rXN0u6O1u46rlzUi5cfvLjRXV1sFiBT08aGKsB7JYhNzSOGyCJB0QMjdvjLf1PwSgsCUpmmVejLqcPnvEvb4r+cd6xlOHYUyZtZiLGYsBHSJzAAXOuLQMfcTZ3SPofg5HKVyfsFa2qPwgIyX7jK9lJHwQbUAeAnuy3cdA4iYGhmM5dKFyGGCVIolW5XcIQVs8yE9BL4oFWpHfA69GJAWejBTqZq1siSILzhWuIjqTBKul3HogBCEui3cjW+ELzFKPhEWw9/8D/+QVR63hz7prrA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7nE1xRuA8y0HVVmz8zvp/wqkls5/D07DGZ+oNkf+0kc=; b=cqnTn3BUefBwwkRvkN6MuRTixTeias5OwI1mAmbiGlnJiUchuCzJdyUqGF9YXNNtGhd6mBolNcRsDGVISUqx1+uLolzMOMu12Hh+B1kCtJsT5F6ZsM/OLmbv9wEyQGiuWsJlNIWoBm0wHPCK0Oe4aAaWSUsh6TLtcghyB9aM9+NLPbTVdIiwzkl7s3qrGQg/vaIP8UEhfcK8kuWHIHrdyNIAcoQ4Qz+F81672P1A3k1mubFR0IVKrnO0xktB/aVOUvpdhozODpdX8gXBUVBU9J/jJ0utqC9A1l80Em0PXqF4ywb6HC+4vNgeledgSZozlQaBu9tBHJjzfI/0cLXUYw== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=juniper.net;dmarc=pass action=none header.from=juniper.net;dkim=pass header.d=juniper.net;arc=none Received: from DM6PR05MB4714.namprd05.prod.outlook.com (20.176.110.82) by DM6PR05MB4985.namprd05.prod.outlook.com (20.177.223.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.10; Tue, 23 Jul 2019 22:33:00 +0000 Received: from DM6PR05MB4714.namprd05.prod.outlook.com ([fe80::64b6:144d:5560:9148]) by DM6PR05MB4714.namprd05.prod.outlook.com ([fe80::64b6:144d:5560:9148%5]) with mapi id 15.20.2115.005; Tue, 23 Jul 2019 22:33:00 +0000 From: John Scudder To: Daniel Kopp CC: "draft-ietf-sidrops-validating-bgp-speaker@ietf.org" , "sidrops@ietf.org" Thread-Topic: [Sidrops] Multiple origin validation states in draft-ietf-sidrops-validating-bgp-speaker Thread-Index: AQHVQZK7RD5kGolig0mlW5J6ZmY7t6bYtF8AgAAVpQA= Date: Tue, 23 Jul 2019 22:33:00 +0000 Message-ID: <9787054D-6184-4F85-BB7C-B3FCA5A9B028@juniper.net> References: <0B8E9A81-31FE-45BC-A01C-0D05E307EE0E@juniper.net> <6D891976-1160-4329-8035-51DD954B835F@de-cix.net> In-Reply-To: <6D891976-1160-4329-8035-51DD954B835F@de-cix.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.10] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 67ea29dc-6cd5-49c0-2596-08d70fbdb7fd x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:DM6PR05MB4985; x-ms-traffictypediagnostic: DM6PR05MB4985: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0107098B6C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(376002)(396003)(39860400002)(346002)(366004)(136003)(199004)(189003)(478600001)(7736002)(8936002)(236005)(8676002)(5660300002)(81166006)(66946007)(66556008)(66476007)(66446008)(81156014)(53936002)(68736007)(76116006)(54896002)(64756008)(91956017)(6512007)(6486002)(36756003)(4326008)(71200400001)(6436002)(6916009)(71190400001)(33656002)(6116002)(6246003)(3846002)(4744005)(25786009)(11346002)(2616005)(476003)(486006)(86362001)(66066001)(229853002)(14454004)(76176011)(316002)(54906003)(26005)(102836004)(6506007)(53546011)(256004)(2906002)(99286004)(186003)(446003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB4985; H:DM6PR05MB4714.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: zx3CwFdddxZ1s440OgwjJG61PbPG7tzzqJHH4wyFV8zpKz/l4CmU02AeEvvpSo97gCEZoQ12GTCUp6E0/mm/Y2jeLR9e6mpK/ZE3vUifdLE2t/+yautPs5BDXsrQi4dAkpMwmZTTuR4mR1+pf6DFMehYpLbfS3ESh8F/0ZvrO6Byu998APnOzlJHYmVgEah13iJgyrmwfiop5NMMx9JUlads6JVLS+uhfFHFG8oUqRGWDdfIMjUHE8HQX+tEIHiMpVgUehbXdBJAlV8ig6rqAykp8C/UbIYqXgjfwvfjwv3CkkIcKEOmKV024tmI7cycdbBHOXmugz4znCW0uKTeaSQ0xWriQ4e3+wEBu0MmE9kWPOQrfd+s37hm+EqCTabYKXHwmd2nngupeAcXjVnlDH6IE0jz+YA1Iqui+jE3k/U= Content-Type: multipart/alternative; boundary="_000_9787054D61844F85BB7CB3FCA5A9B028junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 67ea29dc-6cd5-49c0-2596-08d70fbdb7fd X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jul 2019 22:33:00.4981 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jgs@juniper.net X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4985 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-23_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=895 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1907230229 Archived-At: Subject: Re: [Sidrops] Multiple origin validation states in draft-ietf-sidrops-validating-bgp-speaker X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 22:33:16 -0000 --_000_9787054D61844F85BB7CB3FCA5A9B028junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gSnVsIDIzLCAyMDE5LCBhdCA1OjE1IFBNLCBEYW5pZWwgS29wcCA8ZGFuaWVsLmtvcHBAZGUt Y2l4Lm5ldDxtYWlsdG86ZGFuaWVsLmtvcHBAZGUtY2l4Lm5ldD4+IHdyb3RlOg0KDQpMZXQgbWUg a25vdyBpZiB5b3UgdGhpbmsgd2Ugc2hvdWxkIHJlbW92ZSA1LjQuDQoNCk5vLCBJIHRoaW5rIGl0 4oCZcyBwcm9wZXIgdG8gcHJvdmlkZSBndWlkYW5jZSBmb3Igd2hhdCB0byBkbyBpbiB0aGlzIHNp dHVhdGlvbiBhbmQgSSBhcHByZWNpYXRlIHlvdXIgZG9pbmcgaXQuIEFzIHRvIHRoZSBvbmdvaW5n IGRpc2N1c3Npb24gb2Ygd2hldGhlciB0aGUgc3RyYXRlZ3kgeW91IGdpdmUgaW4gdGhhdCBzZWN0 aW9uIGlzIHRoZSByaWdodCBvbmUgb3IgaWYgYSBkaWZmZXJlbnQgb25lIHNob3VsZCBiZSB1c2Vk LCBJ4oCZbSBhZ25vc3RpYyDigJQgaXTigJlzIGVub3VnaCB0aGF0IHRoZXJlIGlzIGEgZGVmaW5l ZCBzdHJhdGVneSwgYXMgZmFyIGFzIEnigJltIGNvbmNlcm5lZC4NCg0K4oCUSm9obg0K --_000_9787054D61844F85BB7CB3FCA5A9B028junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <3805B7DCC0618743A4A87B6F0EF245CE@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCk9uIEp1bCAyMywgMjAxOSwgYXQgNToxNSBQTSwg RGFuaWVsIEtvcHAgJmx0OzxhIGhyZWY9Im1haWx0bzpkYW5pZWwua29wcEBkZS1jaXgubmV0IiBj bGFzcz0iIj5kYW5pZWwua29wcEBkZS1jaXgubmV0PC9hPiZndDsgd3JvdGU6PGJyIGNsYXNzPSIi Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPjxiciBjbGFzcz0iQXBw bGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJjYXJl dC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6 IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9u dC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3Rh cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTog bm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWlt cG9ydGFudDsiIGNsYXNzPSIiPkxldA0KIG1lIGtub3cgaWYgeW91IHRoaW5rIHdlIHNob3VsZCBy ZW1vdmUgNS40Ljwvc3Bhbj48YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv bnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFs OyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4 OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsi IGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiI+Tm8sIEkgdGhpbmsgaXTigJlzIHByb3BlciB0byBwcm92aWRlIGd1aWRh bmNlIGZvciB3aGF0IHRvIGRvIGluIHRoaXMgc2l0dWF0aW9uIGFuZCBJIGFwcHJlY2lhdGUgeW91 ciBkb2luZyBpdC4gQXMgdG8gdGhlIG9uZ29pbmcgZGlzY3Vzc2lvbiBvZiB3aGV0aGVyIHRoZSBz dHJhdGVneSB5b3UgZ2l2ZSBpbiB0aGF0IHNlY3Rpb24gaXMgdGhlIHJpZ2h0IG9uZSBvciBpZiBh IGRpZmZlcmVudCBvbmUgc2hvdWxkIGJlIHVzZWQsIEnigJltDQogYWdub3N0aWMg4oCUIGl04oCZ cyBlbm91Z2ggdGhhdCB0aGVyZSBpcyBhIGRlZmluZWQgc3RyYXRlZ3ksIGFzIGZhciBhcyBJ4oCZ bSBjb25jZXJuZWQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj7igJRKb2huPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_9787054D61844F85BB7CB3FCA5A9B028junipernet_-- From nobody Tue Jul 23 22:01:20 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 837CD12011D for ; Tue, 23 Jul 2019 22:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=DNxy1T1p; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=rMe3S23W 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 nB6yQQIx2hBK for ; Tue, 23 Jul 2019 22:01:16 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1771112003F for ; Tue, 23 Jul 2019 22:01:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4686; q=dns/txt; s=iport; t=1563944476; x=1565154076; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kFEpMHJxN7ENn+sZvHBRcOhk0G8wQf1yXBwu61jn8j4=; b=DNxy1T1pfH1jc/AqLa/v8pqxAHy7vjkIMOAebyMnezgKaHmzzLA/39cx 6ERjaitMKP9XZvAUuBJblI6wH37Lu4TVxKPtPzEJ2hpnj8htAhkKq4G0X nGjPIdL3ZkZQG9E0QWs0SDFX4T6YEa8J8RHu8x44TGFgci/F1xiZLVfOJ A=; IronPort-PHdr: =?us-ascii?q?9a23=3A7RLzGBWvUtHwukrL+B5pRLq2jU3V8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSANSJ8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dE7KdehAk8GIiAAEz/IuTtank4HMlDSE1N9HCgOk8TE8H7NBXf?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B9AACl5Tdd/5NdJa1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBZ4FEUANtVSAECyqDXUCDRwOOAIJbfpZSglIDVAkBAQE?= =?us-ascii?q?MAQEYCwoCAQGDekYCF4I3IzgTAQMBAQQBAQIBBm2FHgyFSgEBAQEDAQEKBhE?= =?us-ascii?q?RDAEBLAsBCwQCAQYCEQQBAQECAiYCAgIlCxUICAIEAQ0FCBqDAYFqAx0BAgy?= =?us-ascii?q?QQZBgAoE4iGBxgTKCeQEBBYUGGIITAwaBDCiLXxeBQD+BEUaCFzU+gmEBAQK?= =?us-ascii?q?BYYMJMoImjnibcQkCghmLd4gymAqNN5dRAgQCBAUCDgEBBYFnIYFYcBU7gmy?= =?us-ascii?q?CQgwXg06FFIU/cgGBKIo1K4IlAQE?= X-IronPort-AV: E=Sophos;i="5.64,300,1559520000"; d="scan'208";a="297396647" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Jul 2019 05:01:14 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id x6O51EWR003355 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 24 Jul 2019 05:01:14 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 24 Jul 2019 00:01:14 -0500 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 24 Jul 2019 01:01:13 -0400 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 24 Jul 2019 00:01:13 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=M25YNEvaWCATZVcgSmt4l2BVHRDp14Ro4HMJQ2704elnFI//fmOrx2S1JyJOYUpSQsw4/LWjY7E0P888DJK7HFXmjEfg1L1KJYjDZzMJESYwpanAjvM0YpZwpIPefbsmchihbIDLo+aLdAqyagMgBYG4EQ4lPl45y1jAy+pWuxlnogeaXhEtVSStictoU5g1a03urWwE8GHzdECm2Q0LY3MGL2e3zIyueC6c/6VIFJumTSFb/MG7POIEirEULgTMae0wxtx+u24yS67LBh2aedkAgBUmsHaEH43R0ysZ/6js4XHhp7BYD3L0nRH3amtaXeCk1ByQjNI6NpjdwCMoSA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kFEpMHJxN7ENn+sZvHBRcOhk0G8wQf1yXBwu61jn8j4=; b=Wms7aR52pikWxFkiK7RJPFsJEW/eoeRDuqGZ7p7hnLBl+KMIgLCZ4CN08O+UetWROUhwcljLoojVK6TzgdNN7vhi8FOnO4RdnTfPtQo4ydLtFfp2cKH1/tl4YvA3+NtaHt9tXODPzqXvogDYwNUPzUZT43aFXdDPgfHQvWe9t92bS1Lj7PLUw5EynKvPTybdeKW7MDnR8w1MtWFlPWWcQj03m8S+W6PJHH0GEwWgQhzR+QbcVRqtBultucL9gIs7cMMAwTKgK4vhB0T1Pz7qZgJZXD+H+Ti8KJdJEoEQY5Z9k21wPumVBLZv4JYooyZ3yBil+laF89Os9M0jbJY4Vg== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cisco.com;dmarc=pass action=none header.from=cisco.com;dkim=pass header.d=cisco.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kFEpMHJxN7ENn+sZvHBRcOhk0G8wQf1yXBwu61jn8j4=; b=rMe3S23WAh7oOl9uVkgiPRh829OQHopDIiZgy1mk1Y30eOswhTV6tnAakU+zzc7twiPF3yrYoQWU+qWLERVR+1b9Crkg/9nUAkbGP7Rybo6qPCvKC3Q0sxvOoSmj75FRiEFHpBWUeUNSI+FVKnJd5+K0g0kMJg2kG3p0uoNI1oY= Received: from BYAPR11MB3751.namprd11.prod.outlook.com (20.178.238.144) by BYAPR11MB3781.namprd11.prod.outlook.com (20.178.238.223) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.17; Wed, 24 Jul 2019 05:01:12 +0000 Received: from BYAPR11MB3751.namprd11.prod.outlook.com ([fe80::a894:a92:ad6e:ee2a]) by BYAPR11MB3751.namprd11.prod.outlook.com ([fe80::a894:a92:ad6e:ee2a%7]) with mapi id 15.20.2094.017; Wed, 24 Jul 2019 05:01:12 +0000 From: "Jakob Heitz (jheitz)" To: Job Snijders , John Scudder CC: "sidrops@ietf.org" Thread-Topic: [Sidrops] draft-ymbk-sidrops-ov-signal-02 Thread-Index: AQHVQZfqdZEC8Ka1Vk6EHyhMX0ZkL6bYr+eAgACELEA= Date: Wed, 24 Jul 2019 05:01:11 +0000 Message-ID: References: <77600356-557E-43F6-82AB-5AFFB830B984@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jheitz@cisco.com; x-originating-ip: [2001:420:c0c8:1001::216] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f7e856ff-4045-4b04-2e08-08d70ff3f2d1 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB3781; x-ms-traffictypediagnostic: BYAPR11MB3781: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0108A997B2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(136003)(39860400002)(366004)(346002)(396003)(13464003)(199004)(189003)(561944003)(6436002)(478600001)(74316002)(476003)(66574012)(9686003)(55016002)(6306002)(52536014)(53936002)(76116006)(14454004)(86362001)(66556008)(5660300002)(6246003)(25786009)(66446008)(64756008)(229853002)(66946007)(66476007)(8676002)(8936002)(81166006)(81156014)(33656002)(110136005)(316002)(7736002)(186003)(76176011)(4326008)(71190400001)(305945005)(71200400001)(46003)(6506007)(53546011)(256004)(102836004)(2906002)(68736007)(966005)(6116002)(7696005)(486006)(99286004)(11346002)(446003)(14444005); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3781; H:BYAPR11MB3751.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 7Pz/CPPqOnaWCfqjdAr7FgulstQ1+qS2dNGFmT7W29O2BIgoWcUe308t8l47jIs2uQ1bbalzAqBKQdyE9FeDc3Fqvi1Y1WW4CI0psbigijEoKL4QXWRSR/Z1BFCAYCrBrs5JOGjYGOZm09OwbEqTZlDtqp/H2hJZUQBY1xF9AUJuJy4zIKNt3hzrmvOOWiGpPmByuBPSbEWC9dxmEdZ5mVdLHDtfmusgzVuhGe4kAhCLZBS9vCawREkAidIwAqaJRQA1TPj6Rioep3ef4ndLMous3RvaCP7rX850K2DYDsKGtY7QTewEHBNlBGOb/fmOEPe6qJYJRL361Rf0Kwk/6Qrsphe7I3ecBxtzUHSwp+qKaotgyxc0HJ/K0zoCHeaRDTHJE1suw7lJO2i3cxDlogA6n6ELZe/j93GKUkRRbRw= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: f7e856ff-4045-4b04-2e08-08d70ff3f2d1 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2019 05:01:11.9860 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jheitz@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3781 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [Sidrops] draft-ymbk-sidrops-ov-signal-02 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 05:01:19 -0000 SWYgUk9WIHJlc3VsdHMgaW4gYW4gb2JqZWN0aW9uYWJsZSB2YWxpZGl0eSwgdGhlbiB0aGUgcm91 dGUgaXMgbmV2ZXIgaW5zdGFsbGVkLg0KSWYgYSAiU2VuZGVyIiBpcyB0byBvdXRzb3VyY2UgdGhl IFJPViBwcm9jZWR1cmUgdG8gYW4gIkV2YWx1YXRvciIsIHRoZW4gdGhlDQpTZW5kZXIgTVVTVCBO T1QgaW5zdGFsbCB0aGUgcm91dGUgdW50aWwgdGhlIEV2YWx1YXRvciByZXR1cm5zIGFuIGFjY2Vw dGFibGUNCnZhbGlkaXR5Lg0KDQpSZWdhcmRzLA0KSmFrb2IuDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBTaWRyb3BzIDxzaWRyb3BzLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJl aGFsZiBPZiBKb2IgU25pamRlcnMNClNlbnQ6IFR1ZXNkYXksIEp1bHkgMjMsIDIwMTkgMjowMCBQ TQ0KVG86IEpvaG4gU2N1ZGRlciA8amdzPTQwanVuaXBlci5uZXRAZG1hcmMuaWV0Zi5vcmc+DQpD Yzogc2lkcm9wc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtTaWRyb3BzXSBkcmFmdC15bWJrLXNp ZHJvcHMtb3Ytc2lnbmFsLTAyDQoNCkkgaGF2ZSBxdWVzdGlvbnMgYWJvdXQgdGhpcyBkcmFmdCBh cyB3ZWxsOg0KDQpXaHkgbm90IHR1bm5lbCBWUlBzIGluc2lkZSBCR1AgaW4gYSBuZXcgQUZJIHRv IHBvcHVsYXRlIHRoZSBvcmlnaW4NCnZhbGlkYXRpb24gY2FjaGUgb24gdGhlIGVkZ2VzPyBJIHRo aW5rIHRoZSBCR1AgcHJvdG9jb2wgaGFzIHN1ZmZpY2llbnQNCmhvb2tzIHRvIG1vZGVsIHRoZSBS VFIgcHJvdG9jb2wgZmFpcmx5IGNsb3NlbHkuDQoNCk9yIHBlcmhhcHMgSSBkb24ndCB1bmRlcnN0 YW5kIHRoZSBhcHBlYWwgb2YgdGhpcyBtZWNoYW5pc20uIFdoeSBub3QNCnVzZSBSVFI/IE9yIGlm IHRoZXJlIGlzIG5vIHJvb20gb24gdGhlIGVkZ2Ugcm91dGVyIGZvciB0aGUgbWVtb3J5IGENClZS UCBjYWNoZT8gSWYgdGhlcmUgaXMgbm8gcm9vbSwgY2FuIGl0IGV2ZW4gZG8gSW50ZXJuZXQgQkdQ Pw0KDQpLaW5kIHJlZ2FyZHMsDQoNCkpvYg0KDQpPbiBUdWUsIEp1bCAyMywgMjAxOSBhdCA4OjQ4 IFBNIEpvaG4gU2N1ZGRlcg0KPGpncz00MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnPiB3cm90 ZToNCj4NCj4gVGhpbmdzIEkgd291bGQgaGF2ZSBzYWlkIGF0IHRoZSBtaWMgaGFkIHRpbWUgYWxs b3dlZDoNCj4NCj4gMS4gRm9yIHdoYXQgaXTigJlzIHdvcnRoLCBSRkMgNDI3MSBzZWN0aW9uIDku MSBzYXlzIHlvdSBhcmVu4oCZdCBhbGxvd2VkIHRvIGhhdmUgdGhpcyBmZWF0dXJlOg0KPg0KPiAg ICBUaGUgZnVuY3Rpb24gdGhhdCBjYWxjdWxhdGVzIHRoZSBkZWdyZWUgb2YgcHJlZmVyZW5jZSBm b3IgYSBnaXZlbg0KPiAgICByb3V0ZSBTSEFMTCBOT1QgdXNlIGFueSBvZiB0aGUgZm9sbG93aW5n IGFzIGl0cyBpbnB1dHM6IHRoZSBleGlzdGVuY2UNCj4gICAgb2Ygb3RoZXIgcm91dGVzLCB0aGUg bm9uLWV4aXN0ZW5jZSBvZiBvdGhlciByb3V0ZXMsIG9yIHRoZSBwYXRoDQo+ICAgIGF0dHJpYnV0 ZXMgb2Ygb3RoZXIgcm91dGVzLiAgUm91dGUgc2VsZWN0aW9uIHRoZW4gY29uc2lzdHMgb2YgdGhl DQo+ICAgIGluZGl2aWR1YWwgYXBwbGljYXRpb24gb2YgdGhlIGRlZ3JlZSBvZiBwcmVmZXJlbmNl IGZ1bmN0aW9uIHRvIGVhY2gNCj4gICAgZmVhc2libGUgcm91dGUsIGZvbGxvd2VkIGJ5IHRoZSBj aG9pY2Ugb2YgdGhlIG9uZSB3aXRoIHRoZSBoaWdoZXN0DQo+ICAgIGRlZ3JlZSBvZiBwcmVmZXJl bmNlLg0KPg0KPiBBcyBJIHVuZGVyc3RhbmQgc2VjdGlvbiA1IG9mIHRoZSBkcmFmdCAoYXMgaW5m b3JtZWQgYnkgUmFuZHnigJlzIGRlc2NyaXB0aW9uKSwgaXQgaXMgZXhhY3RseSBtYW5kYXRpbmcg dGhhdCB3ZSB1c2UgdGhlIHBhdGggYXR0cmlidXRlcyBvZiBvdGhlciByb3V0ZXMgZm9yIHRoZSBj b21wdXRhdGlvbiBvZiB0aGUgZGVncmVlIG9mIHByZWZlcmVuY2UuDQo+DQo+IDIuIEFzc3VtaW5n IHdlIG92ZXJjb21lIHRoYXQgcHJvYmxlbSwgdGhlcmUgYXBwZWFycyB0byBiZSBhIHN0YWJpbGl0 eSBhbmQvb3IgZnJlc2huZXNzIGlzc3VlOg0KPg0KPiAtIFJSIGNsaWVudCBDIGFkdmVydGlzZXMg cm91dGUgQSB0byBSUg0KPiAtIFJSIGNoZWNrcyBBLCBkZWNpZGVzIGl0IGlzIGludmFsaWQNCj4g LSBSUiBhZHZlcnRpc2VzIEEsIG1hcmtlZCBpbnZhbGlkLCBiYWNrIHRvIEMuIENhbGwgdGhpcyBB 4oCZLg0KPiAtIEMgb2JleXMgc2VjdGlvbiA1IGFuZCB3aXRoZHJhd3MgQSBmcm9tIGV2ZXJ5b25l IChpbmNsdWRpbmcgUlIpDQo+IC0gRm9sbG93aW5nIHRoZSBub3JtYWwgb3BlcmF0aW9uIG9mIEJH UCwgUlIgd2l0aGRyYXdzIEEnIGZyb20gZXZlcnlvbmUgKGluY2x1ZGluZyBDKQ0KPiAtIE5vdyBB 4oCZIGlzIG5vdCBpbiBD4oCZcyBBZGotUklCLUluLCBidXQgQSBpcy4gSSBiZWxpZXZlIHdoYXQg S2V5dXIgc2FpZCBvbiB0aGUgbWljIHdhcyB0aGF0IEMgaXMgc3VwcG9zZWQgdG8gaGF2ZSBwZXJz aXN0ZW50bHkgbWFya2VkIEEgYXMgaW52YWxpZCBpbiB0aGUgZWFybGllciBzdGVwLCBwYXRjaGlu ZyB0aGUgb2J2aW91cyBzdGFiaWxpdHkgcHJvYmxlbS4NCj4gLSBOb3cgc3VwcG9zZSB0aGUgY29u dGVudCBvZiB0aGUgUlBLSSBjaGFuZ2VzIHN1Y2ggdGhhdCBBIGlzIG5vdyB2YWxpZC4NCj4g4oCm IGhvdyBkb2VzIEEgZXZlciBmaW5kIHRoaXMgb3V0IGFuZCB1bi1zdXBwcmVzcyBBPyBBcyBmYXIg YXMgSSBjYW4gdGVsbCwgdGhlIGFuc3dlciBpcywg4oCcaXQgZG9lc27igJl04oCdLiBSUiBuZXZl ciBzZWVzIGEgcmUtYW5ub3VuY2VtZW50IG9mIEEsIHNvIGl0IGNhbuKAmXQgcmUtdmFsaWRhdGUg YW5kIGFubm91bmNlIGl0IHRvIGJlIHZhbGlkLiBTbyBpdOKAmXMganVzdCB3ZWRnZWQuDQo+DQo+ IDMuIEZpbmFsbHksIHNvbWVvbmUgY29tbWVudGVkIGF0IHRoZSBtaWMgdGhhdCB0aGUgd29yayB0 byB0dXJuIHZhbGlkYXRpb24gb24gYXQgQyBpcyBsZXNzIHRoYW4gdGhlIHdvcmsgdG8gZGVidWcs IGltcGxlbWVudCwgYW5kIGRlcGxveSB0aGlzIHByb3Bvc2FsLiBJIGFncmVlLg0KPg0KPiBHaXZl biB0aGUgYWJvdmUsIEnigJltIG5vdCBpbiBmYXZvciBvZiBhZG9wdGlvbiAodGhvdWdoIEnigJlt IGFsd2F5cyB3aWxsaW5nIHRvIGJlIGNvbnZpbmNlZCkuDQo+DQo+IFRoYW5rcywNCj4NCj4g4oCU Sm9obg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBTaWRyb3BzIG1haWxpbmcgbGlzdA0KPiBTaWRyb3BzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lkcm9wcw0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KU2lkcm9wcyBtYWlsaW5nIGxpc3QNClNpZHJv cHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lkcm9w cw0K From nobody Wed Jul 24 08:26:44 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55BB31201AF for ; Wed, 24 Jul 2019 08:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 3ujePkwAWW0f for ; Wed, 24 Jul 2019 08:26:37 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id A97FB12034C for ; Wed, 24 Jul 2019 08:26:37 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id C836E1E2F4; Wed, 24 Jul 2019 11:28:25 -0400 (EDT) Date: Wed, 24 Jul 2019 11:28:25 -0400 From: Jeffrey Haas To: John Scudder Cc: "sidrops@ietf.org" Message-ID: <20190724152825.GJ28302@pfrc.org> References: <77600356-557E-43F6-82AB-5AFFB830B984@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <77600356-557E-43F6-82AB-5AFFB830B984@juniper.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Sidrops] draft-ymbk-sidrops-ov-signal-02 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 15:26:39 -0000 On Tue, Jul 23, 2019 at 08:48:01PM +0000, John Scudder wrote: > Things I would have said at the mic had time allowed: > > 1. For what it’s worth, RFC 4271 section 9.1 says you aren’t allowed to have this feature: > > The function that calculates the degree of preference for a given > route SHALL NOT use any of the following as its inputs: the existence > of other routes, the non-existence of other routes, or the path > attributes of other routes. Route selection then consists of the > individual application of the degree of preference function to each > feasible route, followed by the choice of the one with the highest > degree of preference. > > As I understand section 5 of the draft (as informed by Randy’s description), it is exactly mandating that we use the path attributes of other routes for the computation of the degree of preference. > > 2. Assuming we overcome that problem, there appears to be a stability and/or freshness issue: [Example elided] FWIW, I'd observe that the given use case in the draft is a route reflector or other BGP speaker. Since a BGP speaker normally would only send a route to a given BGP speaker based on having performed route selection, the sender of the route to be proxy validated should expect to not receive the route in many cases since it's not the selected best path. John's example shows a case where we might end up in some undesirable cases. The desire in this draft is to leverage existing BGP plumbing. It's an awkward fit as currently discussed. Thus I'm with John in not being in favor of adoption at this time. -- Jeff From nobody Wed Jul 24 08:27:56 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98DFD120366 for ; Wed, 24 Jul 2019 08:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 ZfkHY8pgD-iJ for ; Wed, 24 Jul 2019 08:27:53 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 45B93120361 for ; Wed, 24 Jul 2019 08:27:53 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 6DCE91E2F4; Wed, 24 Jul 2019 11:29:41 -0400 (EDT) Date: Wed, 24 Jul 2019 11:29:41 -0400 From: Jeffrey Haas To: sidrops@ietf.org Message-ID: <20190724152940.GK28302@pfrc.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Sidrops] draft-ymbk-sidrops-ov-egress X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 15:27:55 -0000 On Tue, Jul 23, 2019 at 04:37:05PM -0400, Randy Bush wrote: > request wg adoption of draft-ymbk-sidrops-ov-egress I support adoption of this draft. -- Jeff From nobody Wed Jul 24 08:31:48 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4D712038A for ; Wed, 24 Jul 2019 08:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 KRpMAdvYqfF1 for ; Wed, 24 Jul 2019 08:31:45 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8661112037A for ; Wed, 24 Jul 2019 08:31:45 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 263D4A99BA7C96713DCE for ; Wed, 24 Jul 2019 16:31:44 +0100 (IST) Received: from DGGEML404-HUB.china.huawei.com (10.3.17.39) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 24 Jul 2019 16:31:43 +0100 Received: from DGGEML512-MBX.china.huawei.com ([169.254.2.174]) by DGGEML404-HUB.china.huawei.com ([fe80::b177:a243:7a69:5ab8%31]) with mapi id 14.03.0439.000; Wed, 24 Jul 2019 23:30:37 +0800 From: "Guyunan (Yunan Gu, IP Technology Research Dept. NW)" To: Randy Bush , SIDR Operations WG Thread-Topic: [Sidrops] draft-ymbk-sidrops-ov-egress Thread-Index: AQHVQZZto0VcPbjLMUe2ZbkKogSV96bZ5i7v Date: Wed, 24 Jul 2019 15:30:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.124.94.165] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Sidrops] draft-ymbk-sidrops-ov-egress X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 15:31:47 -0000 Support the adoption of egress OV.=0A= =0A= Yunan=0A= ________________________________________=0A= From: Sidrops [sidrops-bounces@ietf.org] on behalf of Randy Bush [randy@psg= .com]=0A= Sent: Tuesday, July 23, 2019 15:37=0A= To: SIDR Operations WG=0A= Subject: [Sidrops] draft-ymbk-sidrops-ov-egress=0A= =0A= request wg adoption of draft-ymbk-sidrops-ov-egress=0A= =0A= randy=0A= =0A= _______________________________________________=0A= Sidrops mailing list=0A= Sidrops@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidrops=0A= From nobody Wed Jul 24 09:09:47 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EEC21200B3 for ; Wed, 24 Jul 2019 09:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 KPHn0Di4i0wN for ; Wed, 24 Jul 2019 09:09:41 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B55F1203F6 for ; Wed, 24 Jul 2019 09:09:41 -0700 (PDT) X-Envelope-To: sidrops@ietf.org Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id x6OG9bm0074387 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Jul 2019 17:09:39 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local To: Randy Bush Cc: SIDR Operations WG References: From: Nick Hilliard Message-ID: <97afeb1c-6fd1-07e6-415e-e1a553536979@foobar.org> Date: Wed, 24 Jul 2019 17:09:36 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 PostboxApp/6.1.18 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Sidrops] draft-ymbk-sidrops-ov-egress X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 16:09:45 -0000 Randy Bush wrote on 23/07/2019 21:37: > request wg adoption of draft-ymbk-sidrops-ov-egress looks sensible => adopt. Nick From nobody Wed Jul 24 09:17:21 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAA9E120112 for ; Wed, 24 Jul 2019 09:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aelmans-eu.20150623.gappssmtp.com 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 J5_mUw__Ledg for ; Wed, 24 Jul 2019 09:17:18 -0700 (PDT) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 5F449120043 for ; Wed, 24 Jul 2019 09:17:18 -0700 (PDT) Received: by mail-wm1-x332.google.com with SMTP id g67so38054823wme.1 for ; Wed, 24 Jul 2019 09:17:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aelmans-eu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=M4tuWqU8ycurC3ksh8GOSXxmigyajGwVWwDXs4DA8KY=; b=RpCu/QL0656453HCu+D9rd6WtxAmeq+wshLu9iMtaf6JSDYkifVrhadpEQi+cVUgVX ZrIeMAjamTLKOMNLHKpr2RlCAbQoRDKovSS/Tvhd6TflPlClici2SJL9fSG7Ip+Z9B0p SCbQwQY6//JPiXQAtoi1BxV44jCIRPa4sjpfYRv6UIn4UQV8JqK/jEkgEtFVxMKsRe8z drYCZMlvEUSQxT4exOqJjusehsqgmRQyL9PADcl9pzS6w/kJmjaw1utMD+vjuppjtfoi TXij/TRhTuOaMQc8ySJ26N7qib+AMq3gn75byWwPVkAJyPoISNW0lqu60T+7bYXVnFCu 9Dmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=M4tuWqU8ycurC3ksh8GOSXxmigyajGwVWwDXs4DA8KY=; b=js3oKEs5jB5czPju05al00q0mruu9rn/ZbLW1Oqh4/IYSdhibM+v13ZFrwGSUXJ89n QvCWY5SL/UzsVciIMqoQsGZEvqlmSPuhO0/1jxt7loLwdy7VL9cJscwdexCq9XmEk14O 6c4RBnVPC5PHJyUJbpfjI0Wbh6A2ezARfJt+fzxji3mnQ2Z5HlASqWJb0dlLvhbjv7bE wigmPwsb3h1SXhRexvqfm1/CQz8mCTO8AEcSv3I7kyX8QbtR3YE1ur3BHIlVUtLY+UFQ N2mKcpMpxlovgYFK+DyeHqjlrDNRGJMMWtaIvrj3tDBBPO4JcTZuOG7XYH20b8huB+u1 IlUw== X-Gm-Message-State: APjAAAWSOQbL585r/jM40UPRVRYLy50JVWc805o+kyIl6zNOAZj1Gu0n 06NLrehPQnQXboJ9acjstBR3vJtPTQO9oCTRD4SuXbXCpIY= X-Google-Smtp-Source: APXvYqwqSmTpvptSTRikE+vSlSuwYBDKTLZ3Za3ENUe1dZNYEcQ27SWVHl9zvAg5ndKufbWOr0uNknULfb1rl+4fYdY= X-Received: by 2002:a1c:5f87:: with SMTP id t129mr79125145wmb.150.1563985036645; Wed, 24 Jul 2019 09:17:16 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Melchior Aelmans Date: Wed, 24 Jul 2019 12:17:05 -0400 Message-ID: To: Randy Bush Cc: SIDR Operations WG Content-Type: multipart/alternative; boundary="0000000000008b2aa8058e6fa4ce" Archived-At: Subject: Re: [Sidrops] draft-ymbk-sidrops-ov-egress X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 16:17:21 -0000 --0000000000008b2aa8058e6fa4ce Content-Type: text/plain; charset="UTF-8" I support adoption of this draft! On Tue, Jul 23, 2019 at 4:37 PM Randy Bush wrote: > request wg adoption of draft-ymbk-sidrops-ov-egress > > randy > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > --0000000000008b2aa8058e6fa4ce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support adoption of this draft!

On Tue, Jul 23, 2019 at 4= :37 PM Randy Bush <randy@psg.com>= ; wrote:
request= wg adoption of draft-ymbk-sidrops-ov-egress

randy

_______________________________________________
Sidrops mailing list
Sidrops@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sidrops
--0000000000008b2aa8058e6fa4ce-- From nobody Wed Jul 24 10:37:09 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2EE3120112 for ; Wed, 24 Jul 2019 10:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 lGRrsxULqGFJ for ; Wed, 24 Jul 2019 10:37:07 -0700 (PDT) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85026120059 for ; Wed, 24 Jul 2019 10:37:07 -0700 (PDT) Received: from allealle.ripe.net ([193.0.23.12]) by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hqLCL-0000ua-Vg; Wed, 24 Jul 2019 19:37:05 +0200 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::96a]) by allealle.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hqLCL-0008E1-Pu; Wed, 24 Jul 2019 19:37:05 +0200 From: Nathalie Trenaman Message-Id: <8E85216B-6520-48E4-A597-2A53D2C80A6E@ripe.net> Content-Type: multipart/signed; boundary="Apple-Mail=_292107F3-5EA6-47D4-B76B-67AD5DAECEC6"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 24 Jul 2019 13:34:56 -0400 In-Reply-To: Cc: SIDR Operations WG To: Randy Bush References: X-Mailer: Apple Mail (2.3445.104.11) X-ACL-Warn: Delaying message X-RIPE-Signature: b23882c8c47abee4cf35af21618ca92a83f9c5d4d78818b6b7e3fad9828d4043 Archived-At: Subject: Re: [Sidrops] draft-ymbk-sidrops-ov-egress X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 17:37:09 -0000 --Apple-Mail=_292107F3-5EA6-47D4-B76B-67AD5DAECEC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I support WG adoption Nathalie > Op 23 jul. 2019, om 16:37 heeft Randy Bush het = volgende geschreven: >=20 > request wg adoption of draft-ymbk-sidrops-ov-egress >=20 > randy >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops --Apple-Mail=_292107F3-5EA6-47D4-B76B-67AD5DAECEC6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEErOQRhE+jh6+GVH8pAwRJ2YYkN2oFAl04lsAACgkQAwRJ2YYk N2oRdBAAoXP4M/9RHOJUkkyZUkmTj4Ya3vjzQqkV9ywK/Jqnxbf5ErBYPv2pxVOQ SOSSlWRryJglCwGexrEzaXODYs2wOqo+hluALWXkENYblfwYKbOx8Jqz278ioEjb 0xVxbE1IzyPowrXHXhE4ZJAytyaMOcjYzwzZ7MGNUNcHEx6BhJTQ1F6WKPKfegQW uV5lwTGSoDvzPKm1UxDhZEicoZJFcXcAfVSM3IrJn27C+ZIiyPixCBS5AJK2fU1f lWM0hNAO5pf/n8vzmAz/IBFqf/UEMbFEz5WzwYck/QfENY9WiTITjlgsd4wyquKV juJbdKY8knAH3aFg0/sV1GrzMcqjRTbHXJ7XRl2S8CU4ghD2lG6+iP0kOQPP241s YTUtGzQw5KCzYhd6//NrmN2UnP5hNToAx5cSYSOxTVTqdSQJvkZFEJiJ2Lw75wGK Hrh245io8nW9QeKXWDiJse+3EOisCn/fSNyX0MU6ClUCNaLP1t3K/OSfSgpjRX3m ydPhG9oo4Ar2jfmcR9H2i4dX7DvhG9pLAygzz5fQHT1eHsxbEVw2+anTRbyfwLsN oDcHSO5SUnW3DBU1o4fG7j8eZHSrtmN7YItQ3MV5futwHBV+A4A11s+hTVKfXuFO OydZO7zXGC/AJjNbzabDqMVs6iBWvYvVBldKTHZM5JEmMOUyLTg= =Wgir -----END PGP SIGNATURE----- --Apple-Mail=_292107F3-5EA6-47D4-B76B-67AD5DAECEC6-- From nobody Wed Jul 24 10:37:54 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C36981205F7 for ; Wed, 24 Jul 2019 10:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 hCFPP_qHxtld for ; Wed, 24 Jul 2019 10:37:46 -0700 (PDT) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EE771204AB for ; Wed, 24 Jul 2019 10:37:46 -0700 (PDT) Received: from allealle.ripe.net ([193.0.23.12]) by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hqLCy-0000yE-NA; Wed, 24 Jul 2019 19:37:44 +0200 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::96a]) by allealle.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hqLCy-0008E1-HI; Wed, 24 Jul 2019 19:37:44 +0200 From: Nathalie Trenaman Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_C35631C0-9526-4F6D-9718-DB9AB86A2FE1"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 24 Jul 2019 13:37:43 -0400 In-Reply-To: Cc: SIDR Operations WG To: Randy Bush References: X-Mailer: Apple Mail (2.3445.104.11) X-ACL-Warn: Delaying message X-RIPE-Signature: b23882c8c47abee4cf35af21618ca92a75080bbf7ca1afafc448df7db7e5b6a7 Archived-At: Subject: Re: [Sidrops] draft-ymbk-sidrops-ov-egress X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 17:37:53 -0000 --Apple-Mail=_C35631C0-9526-4F6D-9718-DB9AB86A2FE1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I support WG adoption Nathalie > Op 23 jul. 2019, om 16:37 heeft Randy Bush het = volgende geschreven: >=20 > request wg adoption of draft-ymbk-sidrops-ov-egress >=20 > randy >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops --Apple-Mail=_C35631C0-9526-4F6D-9718-DB9AB86A2FE1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEErOQRhE+jh6+GVH8pAwRJ2YYkN2oFAl04l2cACgkQAwRJ2YYk N2qT5g/+OSw+QZ5lnUHA15BDEix5o853lZpESBE7bNlNaEq64Ku06Qh5vdbQNkPy Shqv7yh7FZV+EFO/znN2OOrbdnx/Fd3rZCJcRwzMPCy461dz8M+3scMzEsuuKsbq 5f2+NhAMYcnPWZFZ/pt0RhZb7wiS12WlIu1n2YLbp8VSrdxYTIAxOSeBlUE+9xYH ewkaUblKOoBMEAbZRzH0dnj2yXQia3g7WkQr0XkpT7Bb/wi7zP65l8QDV0FCc4ue qvtTp9TrmsoINvXajWFjfjVi9Gqxm9ZdzkvWfORPcrpWs1KigvORmiRbnFvmJcBV NKkoBvRRD4I9r/AucAsIcmYazey7dtd95B5taW7B03EIG+dUrxv0yhxMu2jJ6B/U Op9NAyDmNKEnkL1CwqFG+y8hRMfKiMEPBBL3wM/iKqnEp0GFsNCu6P8XtDmD63M7 vUwr6SXIiEF/EuXQ5inqF2b/ExxiNsGh+f1Hy7dKo8U2xOkMGHp/44UEQ+s+Oa8u qWgREJEerSKyocGPFwc8aUX1dzxu64uyC8SoO9jHGC/rgiiUqHoos825/5NuQ4Cd DJVw13XOwuvTdl2yeTFwop/7stm4YVNJKYykpAeuEQUed0dWylfoTAVcqkX4i54G hAhdGnXZKnrdlEK3xI4N7L6h98YiK9AEDPBBAV7gZLMN5Tq8ByM= =NFkb -----END PGP SIGNATURE----- --Apple-Mail=_C35631C0-9526-4F6D-9718-DB9AB86A2FE1-- From nobody Wed Jul 24 10:55:46 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65AD6120112 for ; Wed, 24 Jul 2019 10:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 3sRzHZi87hjC for ; Wed, 24 Jul 2019 10:55:43 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66F05120059 for ; Wed, 24 Jul 2019 10:55:43 -0700 (PDT) Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 88794A9C7502509AAAF3 for ; Wed, 24 Jul 2019 18:55:41 +0100 (IST) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 24 Jul 2019 18:55:41 +0100 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.142]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0439.000; Thu, 25 Jul 2019 01:55:26 +0800 From: Zhuangshunwan To: Randy Bush , SIDR Operations WG Thread-Topic: [Sidrops] draft-ymbk-sidrops-ov-egress Thread-Index: AQHVQZZuWA3POL8odEqMOmMP0RXjHKbaDn4w Date: Wed, 24 Jul 2019 17:55:25 +0000 Message-ID: <19AB2A007F56DB4E8257F949A2FB9858E5C45F0E@NKGEML515-MBS.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.124.182.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Sidrops] draft-ymbk-sidrops-ov-egress X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 17:55:45 -0000 Support the adoption of this draft. Shunwan -----Original Message----- From: Sidrops [mailto:sidrops-bounces@ietf.org] On Behalf Of Randy Bush Sent: Wednesday, July 24, 2019 4:37 AM To: SIDR Operations WG Subject: [Sidrops] draft-ymbk-sidrops-ov-egress request wg adoption of draft-ymbk-sidrops-ov-egress randy _______________________________________________ Sidrops mailing list Sidrops@ietf.org https://www.ietf.org/mailman/listinfo/sidrops From nobody Wed Jul 24 11:04:27 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26B961202A5 for ; Wed, 24 Jul 2019 11:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.com 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 gqvsaJ7kW_Rf for ; Wed, 24 Jul 2019 11:04:24 -0700 (PDT) Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) (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 176DA12015B for ; Wed, 24 Jul 2019 11:04:24 -0700 (PDT) Received: by mail-oi1-x22d.google.com with SMTP id a127so35652069oii.2 for ; Wed, 24 Jul 2019 11:04:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rWcWCpdADEC6T0cPlYirkcG+Mu6o5LMKNCh0ZxeN6/E=; b=DSgxm5gaSXhG+UraTHBSX2O5gYrkAV6Rsm99KMy71pNhpzk3nmK14pEcVbl/KDOslg rFcinfDC70EXh3701PIhOBlXSufYSxgL5KNXiW10Ux1uXXofu0r5rT+f4M7MfUJgnVMe CrkrG5lr/vo0+wuG4+SaxXJct7DCsWqGYU+uNvvmZgcc8xu/4RiokWN+CuhrVp0eV8qM kYy9ta4cJma1MkiTlAwZhb3+9lHJ+MObMN4W1ZKhi1E7cGPK+VGShardga1NW5r/BBBv L7/51ozw2OEErBDm23Cp6Glv9vDnzTUcuTs4MY+NFdKtjsPQN5jSFZG9xkw04XGNOJ9T akBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rWcWCpdADEC6T0cPlYirkcG+Mu6o5LMKNCh0ZxeN6/E=; b=Jzy7fQHpQPT4tPi+g/B6lHCL4dlqofTrXI/CTd9h/pCcp/JhJu6aHDDGfGpHJZR7UF sWeY8UkxnnT4+YYeJN8Ryw6bAfBF9G6TWHEsb/NgLsXlFPNuUjnj/UNRbyMQvk9g2+H1 5I3+NnT/ZDYT05nVBVwlTZ07etRgmpHg/KhjBb67QqETGk0zvGWlmhKsa+sJrdWxOVOD ur6T18ZOLLfy+OmlSVziry+4dMgCJSB4UJMARd1Qum1CQRghIgaenjTL77pDAGh9Ddt6 WNKlzw5CEev9tPGaY3O6oRXeCHN3CXy6rCSjOKSyjJq39GEsylxv14rWzaGihFoVcVHi sdXQ== X-Gm-Message-State: APjAAAWDWoiOy/HIi7rmCL8SlPa9f+u00wat7SEFJtjE7iuhTEuBYXPc ipf0T90YE53+6nb86+6k9gWHpo6aQbK3ESW4I/4= X-Google-Smtp-Source: APXvYqwNNiXfhjirGSJf0Fj7l+QGDHQn6yi8ssPXZ+nD0xLy+sDfhyIibKqRHJ15i8FCjBKnbrQf1/u+FicdxVgLWZ4= X-Received: by 2002:aca:dc86:: with SMTP id t128mr42155692oig.130.1563991463080; Wed, 24 Jul 2019 11:04:23 -0700 (PDT) MIME-Version: 1.0 References: <19AB2A007F56DB4E8257F949A2FB9858E5C45F0E@NKGEML515-MBS.china.huawei.com> In-Reply-To: <19AB2A007F56DB4E8257F949A2FB9858E5C45F0E@NKGEML515-MBS.china.huawei.com> From: Job Snijders Date: Wed, 24 Jul 2019 18:03:58 +0000 Message-ID: To: Zhuangshunwan Cc: Randy Bush , SIDR Operations WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Sidrops] draft-ymbk-sidrops-ov-egress X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 18:04:26 -0000 support from me as well On Wed, Jul 24, 2019 at 5:55 PM Zhuangshunwan wrote: > > > Support the adoption of this draft. > > Shunwan > > -----Original Message----- > From: Sidrops [mailto:sidrops-bounces@ietf.org] On Behalf Of Randy Bush > Sent: Wednesday, July 24, 2019 4:37 AM > To: SIDR Operations WG > Subject: [Sidrops] draft-ymbk-sidrops-ov-egress > > request wg adoption of draft-ymbk-sidrops-ov-egress > > randy > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Wed Jul 24 11:04:37 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7405A1202A5 for ; Wed, 24 Jul 2019 11:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net 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 5JYjevj-inD0 for ; Wed, 24 Jul 2019 11:04:34 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D891112015B for ; Wed, 24 Jul 2019 11:04:34 -0700 (PDT) Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x6OI4TSw018617; Wed, 24 Jul 2019 11:04:33 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=xkZqG5412IA0R6zWhygEYTC4oLgn5AfJpW/JXMfhZ3o=; b=n1AMjGbwSNW34AmogYmjjh/qunZMsTIwsN/Try8Wo7bBIOtPbNNWR/jrwcUX8c1Bs15X OrGPXk3ZGc4Ai/dbSLXr5Dx4IPzokPsAstOSNiUnqhL4CYXVHpefR5jgnxz4kyyPHnzm 3mW5BuhN+8O1Yf8tvUobiMwDuA8Ef01d1teqahDKX7rdTfV3bIJWF5lqG2I+t5ObwDpU Kvpj7e3fIk2buy2ltdYVCbjGmeGe4AMlU3U24WzUGlMgRXg6FZvZ8bqSXTa+E2Z9/LQs RtrPc/AZGL79teibeREkBKbV4S6gB6ksOkrOokMyKibcdytZvCPHAzliiX0BLxIWjW/W YQ== Received: from nam01-by2-obe.outbound.protection.outlook.com (mail-by2nam01lp2058.outbound.protection.outlook.com [104.47.34.58]) by mx0a-00273201.pphosted.com with ESMTP id 2txt3y09be-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 24 Jul 2019 11:04:33 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ViX3SSiKqUMNYLzF2PUAL2bHbrDfVqXGQtjC9OItaUVTHXQ+cUDMEMM7SvVAs17hNNeFc+X2hpX5scAjiA1rZmbJ4r13Ft5CW1WayQyNqvp2j0YwPPfvlT4mfb4qSm4WZ41p22xTRF9JLKOZW5hV+/TgPW05ToKMa1G40GQ2w2IwYPgf+dV9zfBYdvyrhp2ba3ZxMgVfcEKzzNc7LMjqMnVNY26u2aRoOjvgv/Ra65mNeC6NFTwDSJutlSaog73YWuxaLBJsd02CQFaqikL4HRvsOhcSzzihRi2BKBOa4DlvHNwCm9sCDCPOvyCEkv7/uGEwbK81hkTRTZaAuy9TgA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xkZqG5412IA0R6zWhygEYTC4oLgn5AfJpW/JXMfhZ3o=; b=iORVpj2+KM1CAXvFbhjEUakrVYqya9G/lS3Upbi4Um3W91EXN9nlZKar8oZ7o2ymkf4ZEGW4SOgx+P2CcrccApTNP3krVWe3aW+8EVrwgI8S1F9HKZ2nzXs3ig4vZhqshaXyS8cGj6Cu/bmXvwuXlOajq744Sp5KDWEKTPTSbBKjJGJlLDWQk4cacGGFOy6mXX1b1ILvvtKqT5zoUjDU/hRiYyDmOlJv/GjFmDiHNo9bGfi8DeXXf1IgfcUJD5fbAMGJckQDZ99N84I5vQ10tbBUofh1NAQnBbXUWCp5jufAgXc0R/GEGQBpK/hOPquTs18jeCTfUz3RtiPXkKtSoA== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=juniper.net;dmarc=pass action=none header.from=juniper.net;dkim=pass header.d=juniper.net;arc=none Received: from DM6PR05MB4714.namprd05.prod.outlook.com (20.176.110.82) by DM6PR05MB3945.namprd05.prod.outlook.com (20.176.64.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2115.9; Wed, 24 Jul 2019 18:04:31 +0000 Received: from DM6PR05MB4714.namprd05.prod.outlook.com ([fe80::64b6:144d:5560:9148]) by DM6PR05MB4714.namprd05.prod.outlook.com ([fe80::64b6:144d:5560:9148%5]) with mapi id 15.20.2115.005; Wed, 24 Jul 2019 18:04:31 +0000 From: John Scudder To: EXT - randy CC: SIDR Operations WG Thread-Topic: [Sidrops] draft-ymbk-sidrops-ov-egress Thread-Index: AQHVQZZsBDMm7jFqEUq5R4Z05wPHYKbaEU6A Date: Wed, 24 Jul 2019 18:04:31 +0000 Message-ID: <7078AA2E-2298-450B-BE74-A58770FC33A9@juniper.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.11] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 07911604-2cf1-49ec-39bc-08d7106160bc x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:DM6PR05MB3945; x-ms-traffictypediagnostic: DM6PR05MB3945: x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3826; x-forefront-prvs: 0108A997B2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(4636009)(136003)(366004)(396003)(39860400002)(346002)(376002)(199004)(189003)(66476007)(7736002)(14454004)(486006)(305945005)(81166006)(14444005)(8936002)(102836004)(81156014)(36756003)(71190400001)(229853002)(478600001)(5660300002)(558084003)(8676002)(256004)(316002)(71200400001)(66066001)(99286004)(3846002)(446003)(2616005)(6916009)(6116002)(86362001)(53936002)(6506007)(68736007)(6486002)(66946007)(91956017)(66446008)(25786009)(26005)(64756008)(4326008)(6512007)(76116006)(66556008)(6436002)(6246003)(76176011)(11346002)(53546011)(2906002)(33656002)(476003)(186003)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB3945; H:DM6PR05MB4714.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: PIzHnrwvT6kR/217viDsoi9uQrUcDs2Z0g6PhZ4z/3U8K5aEL3jP6joZwmXuLz3JCbldVlW/kZz2rJBs7wv0Ww5onira5jnKmonHAWjAMvwLSunwsSMLd9QtWjU/T0Keof32VmKV+RVgxCxPa4yUBsxcKKR5VxWnRiiTqa3afSvKq5sQfxfB9fgywLTdkkG+hHnr1OTWLtV36DEBgDtt/xJNCUq1wsFgflj+uB5Zmu8Q5M4KcYWeuS+8iohJHlP3CVAUFFLFkKCnRhEXZLUcYeMhmFqNOM0MsvKah8cCVGz6Ov5+aW14yWCXKwC/KXPzQW50Irpw9cXIWBr8WloOcEC63KpcM39sOdF8oS39P11gHoh7Dtil4wQLU/lF/CPZx2ud/4YjF6f+9Q9I4YVx838RyRGqH2v7fq0i20W44NU= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 07911604-2cf1-49ec-39bc-08d7106160bc X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2019 18:04:31.5835 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jgs@juniper.net X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB3945 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-24_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=605 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1907240194 Archived-At: Subject: Re: [Sidrops] draft-ymbk-sidrops-ov-egress X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 18:04:37 -0000 PiBPbiBKdWwgMjMsIDIwMTksIGF0IDQ6MzcgUE0sIFJhbmR5IEJ1c2ggPHJhbmR5QHBzZy5jb20+ IHdyb3RlOg0KPiANCj4gcmVxdWVzdCB3ZyBhZG9wdGlvbiBvZiBkcmFmdC15bWJrLXNpZHJvcHMt b3YtZWdyZXNzDQoNClllcyBwbGVhc2UuDQoNCuKAlEpvaG4= From nobody Wed Jul 24 11:49:29 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C6C120346 for ; Wed, 24 Jul 2019 11:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.com 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 lQvZ7O7g6q-U for ; Wed, 24 Jul 2019 11:49:25 -0700 (PDT) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 59CAB120338 for ; Wed, 24 Jul 2019 11:49:25 -0700 (PDT) Received: by mail-qk1-x736.google.com with SMTP id m14so8862244qka.10 for ; Wed, 24 Jul 2019 11:49:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:mime-version:content-disposition :user-agent; bh=dn1aZlmoyACalEUbiyM/zkDQPJQhPc6ZnoEurKYTiXw=; b=BpeqVzSl1fxnJtlJHOl9KsGjRPvRaqliPpJf6LXm6qSphneashxq46BofDmjwg7aOb Ga/op6SAEOL+aeM4/L59HdNAPRE1AR3MzWzkSkw6OvFk3I0D4bU+zsD/TkDazDENepSR k4bCmuvG+pqMZtrIgYBx0wbBBgF65sw0pPkSSEARLoNfNW/X60a8Tv7X7Um2gZ8oz3Vj blFhdLfePt+CHCzsKC63KXWL+r8D0DgPmrt+lC6HjbUH5Jhw+CWBao2+dKq8WGpqjduN 4R2OQ1xMdTAnxaBeBM/dSV3ko2RRItyAFMEVGZEe4ZArl8fUg62s7sJUgJqTBW4DCpbh zMjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition:user-agent; bh=dn1aZlmoyACalEUbiyM/zkDQPJQhPc6ZnoEurKYTiXw=; b=Npsio+UN8FVo6bkgyqxv+30fu9gIeOwipGfs7ZMnwsUAAV+Sixoz+n2Ke4vf+rtB47 7RZwozrJb+ZB/gYNtg1GeBGjs7uUWGbWSxAWVSO6nhJM3el0QkaRh6I4Xf6lKLMy3WvK 85tunsz0McTN3shxdFEufSoXGcn9rAKROjg8xrZCReJqyyMuMZ+keVDzsXKoPLgOFIyq gDV54wzwYihzr+zGcyPeM4hvgM+HyV0jR6F+N1I8bIyzdGDvV78ujrdv63ZH+cIeVZOf Pav8cR/Kb9nSJ89sdFf1mNtMArrE8UwznBGg5PcmClK1TO/L9BMVFRN8NYIEkyLcvs22 JMWQ== X-Gm-Message-State: APjAAAVQqnCsf63Q2BNtR2TY9wBviN0oj2ZUCGQn1hchDtivribsC/WZ xrlFkQEJFDaklwYnKMWDGZer+4a6zyY= X-Google-Smtp-Source: APXvYqyRj8FVgyqdmkFeg3yJfn2G/C9xSNehWyESoSN5Eh5yO1uAYEDpoEwJi2hjZ3IrlEry1MYIhg== X-Received: by 2002:a05:620a:16c6:: with SMTP id a6mr19826464qkn.413.1563994164060; Wed, 24 Jul 2019 11:49:24 -0700 (PDT) Received: from vurt.meerval.net (dhcp-9df9.meeting.ietf.org. [31.133.157.249]) by smtp.gmail.com with ESMTPSA id r4sm17864758qtt.51.2019.07.24.11.49.13 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 24 Jul 2019 11:49:23 -0700 (PDT) Received: from localhost (vurt.meerval.net [local]) by vurt.meerval.net (OpenSMTPD) with ESMTPA id 987d43a8; Wed, 24 Jul 2019 18:48:29 +0000 (UTC) Date: Wed, 24 Jul 2019 18:48:28 +0000 From: Job Snijders To: sidrops@ietf.org Message-ID: <20190724184828.GD81521@vurt.meerval.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: [Sidrops] 'tagging' in draft-ietf-sidrops-validating-bgp-speaker X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 18:49:28 -0000 Hi all, Today there was yet another incident related to a BGP hijack of an IXP Peering LAN Prefix: an ASN originated 80.249.208.0/24, which is part of 80.249.208.0/21. This /24 route was an RPKI invalid announcement. This misconfiguration negatively affected the AMS-IX platform, and some of the authors are associated with this organisation. It is my hope that a real world example of what I at the IETF 104 SIDROPS meeting predicted, will help the authors better understand the negative security implications of the current draft. To better understand the severity of an event like this, one can consider the publicly published statistics, here is a screenshot: http://instituut.net/~job/amsix-rpki-disruption.png You can see an arrow pointing to a low point in the graph, the graph should've been a smoother sine-like shape. The issue is that some BGP implementations will send the BGP packets destined for 80.249.208.0/24 via the hijacked route rather than via the directly connected interface with the less-specific route. For a period of time a few hunderd gigabit/sec was dropped on the floor; this is of course problematic. Now, imagine this 80.249.208.0/24 route announcement passed through a BGP speaker that adheres to the 'tagging' option in draft-ietf-sidrops-validating-bgp-speaker, and instead of rejecting the route announcement only a BGP Large Community is added to this RPKI invalid announcement. I can assure everyone that the presence or absense of that BGP Large Community will do *nothing* to reduce the negative consequences of the existence of such a invalid more-specific /24. It is my hope that the authors now recognize that knowingly propagating RPKI Invalid announcements, even with a specific BGP community attached; makes no sense from a routing security perspective. I propose the "tagging" option is removed from the draft document entirely, or that the "invalid" community is removed and only the 'valid' and 'not-found' communities are specified. A BGP validating speaker should not propagate RPKI invalid announcements, instead such invalid announcements should be rejected; this document can state that. Kind regards, Job From nobody Wed Jul 24 12:09:19 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2B1120112 for ; Wed, 24 Jul 2019 11:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=workonline.africa 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 hcA1s2jozjaO for ; Wed, 24 Jul 2019 11:17:22 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04on060f.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0e::60f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C12ED12017F for ; Wed, 24 Jul 2019 11:17:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kbb2G8Ho+F0cjUufMccdeXdbPMPOOAP0lrQkeB0QUgIeA3yjfHp66lC3rtVUWSLjboH0FSm+GZTttK075owSdWT7m3ovYY1tqIIRlcorsIPeGZfDopoAhvrikP26KfAu+HXY1gh8d/yqC4y0qPTZ8O4Y/yyBy1xWcjfTjERjm3HZDI5Y7ItKBDQbUEHnJwiu9S7ifmsLUEbCuyEzF+C2imLONNo6EtGRhZ74zmyDeDyNeyLehF3BC1rDlVccL8/j3HzL+Iht6MgF07ZrOtWxD/VMHK/MEClc3WLiBc/mvXynDmuHtw7dayUOYFXa6nFQj23sk8LN7HxJDtw/IQudSg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8HOOYoLeHg/JvKudPQzMST8ifUvWxQGK6vzkR33hF0o=; b=WXUIgN6paMuJj75D2vmjrAUz9FxJHRAviHwjmXz45ugIkoeEwr1QXFLL++g4v01tritA8yxBgQ+4fHFs0TeDjhQWW607caMpKTSbGTYnKm8nY3UEqln9HHd9xT32Ly2vPyh/AjWff1KIeZhIy2BnBkLL+EautsJx0qpvVA1k/CNM3VAUo/KEeIgPD0zOo2J4Y0ZmrgzlKghsUzkyou7wyLbq1vb148iaZFBg2XJl/y8g786RDlpXTMAXOv73++9O6o4gIlyKKTGtQIJKk3L1vR9q3sIS/6hYRzgjyhy7MIZ3LtWOCHEWOWuurNwPbUd4DSQLXTFOGW1J4PTwwJkVJA== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=workonline.africa;dmarc=pass action=none header.from=workonline.africa;dkim=pass header.d=workonline.africa;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=workonline.africa; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8HOOYoLeHg/JvKudPQzMST8ifUvWxQGK6vzkR33hF0o=; b=AlZGhE8Z7OTR42LyHC/SOFiR+uz2rS6rMNfrZ2F+HHDRRsN9GkBXPK1pHhemJv2koKHfrj4zbgCv3CZV6VZOSR8XBJPRO5sDsRCuxL8VeOy7Yyywo2k3656BApyPZ6qXxnQraUmcZ2wOJJIil4G+WFNFM1oKkhXPVyvF1b3gDE8= Received: from VI1P190MB0206.EURP190.PROD.OUTLOOK.COM (10.172.80.140) by VI1P190MB0528.EURP190.PROD.OUTLOOK.COM (10.165.191.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2115.10; Wed, 24 Jul 2019 18:17:19 +0000 Received: from VI1P190MB0206.EURP190.PROD.OUTLOOK.COM ([fe80::f94c:3eb1:f33:cf11]) by VI1P190MB0206.EURP190.PROD.OUTLOOK.COM ([fe80::f94c:3eb1:f33:cf11%6]) with mapi id 15.20.2115.005; Wed, 24 Jul 2019 18:17:19 +0000 From: Ben Maddison To: "sidrops@ietf.org" Thread-Topic: [Sidrops] draft-ymbk-sidrops-ov-egress Thread-Index: AQHVQZZyzezg+Zfl0UyFpYnzIpKLPqbaFNuA Date: Wed, 24 Jul 2019 18:17:18 +0000 Message-ID: <3cc4d6a80264d7097a23e7e25bb7da0962f90ea3.camel@workonline.africa> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=benm@workonline.africa; x-originating-ip: [2001:67c:1232:144:8056:33d1:7ae5:75da] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fa7b1136-3925-490d-df3c-08d710632a2a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:VI1P190MB0528; x-ms-traffictypediagnostic: VI1P190MB0528: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3044; x-forefront-prvs: 0108A997B2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(376002)(396003)(136003)(39840400004)(189003)(199004)(305945005)(14454004)(7736002)(486006)(6436002)(6916009)(5640700003)(118296001)(71200400001)(71190400001)(6116002)(25786009)(6512007)(6506007)(53936002)(6246003)(2906002)(2351001)(446003)(11346002)(476003)(46003)(2616005)(256004)(14444005)(102836004)(186003)(508600001)(316002)(66446008)(86362001)(229853002)(6486002)(68736007)(66556008)(64756008)(558084003)(76116006)(91956017)(66946007)(66476007)(81166006)(81156014)(1730700003)(2501003)(8936002)(76176011)(5660300002)(99286004)(8676002)(46492003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1P190MB0528; H:VI1P190MB0206.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: workonline.africa does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 8wQ2t47OCcWPcy6wffDZONjiQG0oxRWL9seDSllT8zwx6xaOB1/Lzkh1CfBkGkvgd5EgiDOOFe+BNqENuCOjxhjxxvT1Y18CClu2mzzWXZ5kSt8NTjCuYTpIib2jVPMmHTfVE9wHZw5V6W8QALmW618rN6ROIIeh1j5uTvP/oEiCplUj8N5oyjTRp7zMEtMPS5HsB5rtCvfu0Ldy8Feya/uY/exHPoLFdHOUixrRcB59VO/WfVK34elGiNXDogKW8sORbnb4D99+ISSjuA7dyzw0fX55EVJPgElpkmCzqpypdBylgwz+jrg7FHbaKFYq4cx8qZP48RhDD9OQGpNkLmqwYWSSiv07lQG8S2uAkP1W94WvH9MqEcMXskChPPQeYQcmdlhpydDFNcsH5WwZ+1IZQSiKY9OKLpF+RGOuTMI= Content-Type: text/plain; charset="utf-8" Content-ID: <2190490845FE1A41A0BAABA7A8984527@EURP190.PROD.OUTLOOK.COM> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: workonline.africa X-MS-Exchange-CrossTenant-Network-Message-Id: fa7b1136-3925-490d-df3c-08d710632a2a X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2019 18:17:18.9222 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b4e811d5-95e8-453a-b640-0fba8d3b9ef7 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: benm@workonline.africa X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P190MB0528 Archived-At: X-Mailman-Approved-At: Wed, 24 Jul 2019 12:09:17 -0700 Subject: Re: [Sidrops] draft-ymbk-sidrops-ov-egress X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 18:17:24 -0000 T24gVHVlLCAyMDE5LTA3LTIzIGF0IDE2OjM3IC0wNDAwLCBSYW5keSBCdXNoIHdyb3RlOg0KPiBy ZXF1ZXN0IHdnIGFkb3B0aW9uIG9mIGRyYWZ0LXltYmstc2lkcm9wcy1vdi1lZ3Jlc3MNCj4gDQpz dXBwb3J0DQoNCkNoZWVycywNCg0KQmVuDQoNCg== From nobody Wed Jul 24 12:36:53 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD8F1204B2 for ; Wed, 24 Jul 2019 12:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov 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 Ep5NfCT1Bmyl for ; Wed, 24 Jul 2019 12:36:47 -0700 (PDT) Received: from GCC01-DM2-obe.outbound.protection.outlook.com (mail-eopbgr840118.outbound.protection.outlook.com [40.107.84.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6195C1204EB for ; Wed, 24 Jul 2019 12:36:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KpcLvDoR6nIQvwPQjP0dhtHVXBu/88zR83i7RCBRecrbUA1tHRQRswxuZ/+z2l4rX220Wb8lc/8pVUDRPiVvRhD3Oprn3lE7Szc4DTFteMgND25OYx93CulXWzG5OO5DOsjYDYbbxpc+bmGbdIX/Wqfth89Xo5T7Qx0Xc39iP4+bJr7hP/V1gSyPQH/VZcLr4ITmCBl0Jx72jd39mDNrCrp7wFFhsMfyYHGO13DrUuEkZHiMEo0d8Uw1S6CzHsIlSSHsUSAZZETdYSLiWO42XSLgnAsR88/ml8A4V6iUttgZqCEgPOQsRDC10Er+EFKdj1VpqLr60sB82kpMLqnmkw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RgRGrrVaArC1euqwvJl2/shur5S5dqXFGCCU9kWbX3Y=; b=kYwaNz22JNnDtAp+C8hJcsKxxLjSvjDR8fpzccuAyCjM+lyMLuMOR3Ije0L7v1+b58qFfXTiGqkdT6BlqxCQcNmzcJUYwajun6Nk91v4oL7q/dvaLD+kCXU2/2z9vV2NsK7xKZYSLn2d3qeSZ1Xu6SXTY5rqL2xoPmdXsAxyHthpzJ0qbdwmO93Uq4b1I+ruc4XHSP2BGq+j4/xShCMFKjCWstN5Xi7yPaxF7pGm176uhl3lScvdIl79+BCTo9pW293fBwA7Op4fk20/c6h4TN6ifrULMSskXXqFLfxpWukOwU86wo//xhybohJu32roYp//C4PCSFRLH7DhIl1uvA== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=nist.gov;dmarc=pass action=none header.from=nist.gov;dkim=pass header.d=nist.gov;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RgRGrrVaArC1euqwvJl2/shur5S5dqXFGCCU9kWbX3Y=; b=2B0rwkiAzD1h+1j3Na8S6KcCVGrnwWfi/3Vh0kxgX9Gu5ZBPcQsOSur1cwXdHDB+BJ9QN6od4Xu0X8GNGm3kbQBeKvM9cAX208KPuhxjniuJF/nluXvEqzYf+GKig9PHnFEwqvMOSxWYzoxr4kQmGkAH1wkQX4YPNmRzRI4IOYI= Received: from CH2PR09MB4203.namprd09.prod.outlook.com (10.186.136.71) by CH2PR09MB3959.namprd09.prod.outlook.com (52.132.229.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2115.10; Wed, 24 Jul 2019 19:36:45 +0000 Received: from CH2PR09MB4203.namprd09.prod.outlook.com ([fe80::9c7c:9748:90f1:5c70]) by CH2PR09MB4203.namprd09.prod.outlook.com ([fe80::9c7c:9748:90f1:5c70%4]) with mapi id 15.20.2094.017; Wed, 24 Jul 2019 19:36:45 +0000 From: "Borchert, Oliver (Fed)" To: "Jakob Heitz (jheitz)" , Job Snijders , John Scudder CC: "sidrops@ietf.org" Thread-Topic: [Sidrops] draft-ymbk-sidrops-ov-signal-02 Thread-Index: AQHVQZfqdZEC8Ka1Vk6EHyhMX0ZkL6bYr+eAgACELECAALPtgA== Date: Wed, 24 Jul 2019 19:36:45 +0000 Message-ID: <4F31DC47-D4B9-4201-8C84-47A471EED065@nist.gov> References: <77600356-557E-43F6-82AB-5AFFB830B984@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.1.190220 authentication-results: spf=none (sender IP is ) smtp.mailfrom=oliver.borchert@nist.gov; x-originating-ip: [2001:67c:1232:144:c9fd:484d:bfee:c1f0] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3378fa71-b260-4ac1-ac2e-08d7106e4353 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:CH2PR09MB3959; x-ms-traffictypediagnostic: CH2PR09MB3959: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0108A997B2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(376002)(39850400004)(136003)(396003)(13464003)(199004)(189003)(6506007)(76176011)(53546011)(6512007)(66946007)(66574012)(36756003)(58126008)(76116006)(316002)(14454004)(102836004)(305945005)(7736002)(6116002)(46003)(6486002)(86362001)(81156014)(25786009)(99286004)(53936002)(66446008)(486006)(8676002)(6436002)(66556008)(66476007)(6246003)(5660300002)(81166006)(91956017)(8936002)(68736007)(966005)(2906002)(6306002)(229853002)(446003)(64756008)(4326008)(33656002)(11346002)(561944003)(110136005)(476003)(478600001)(71190400001)(71200400001)(45080400002)(186003)(14444005)(256004)(2616005); DIR:OUT; SFP:1102; SCL:1; SRVR:CH2PR09MB3959; H:CH2PR09MB4203.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: PvqGMzFZfQddqHVEiKOP9YvuX7/TNX/pzDe8K/LX+AYz0QNsr51Ib79liEoBR2QIAAjrbnt8omheMLaUxYQaWuBmEMF84UU+SftLbOnzUVWc8HiM7hfyZUM+lLxbKLwW2d6YCJ9FfaiP4Ro87eFq7/J7/37sEOfIssrlez0uUNemV/AfiJTK9gnqORDvzFmD2q3mTw2PiADcw1X2SzjjrpOleuA3r7yQ3WdtIetACxGk0AeE4lgfoF0S8J8mfdVKBcxeNb6GXjuBIvDqiHGdFbsnbPeNDy19muDzUSpbMJUbl29T2bB/hf+PAFT4D9+7ZZWdvilggyV97DqO6GP2Qw02RD5tUfyL0wjuBiLzlrs9dEmqO16olNiPOAC6DdRAH7aJ3hhj58uoQZwA2VZTlKi9kxzJlpcHKT0RCWHfo3E= Content-Type: text/plain; charset="utf-8" Content-ID: <1B136681EBE97644AC41E16225AD21C4@namprd09.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 3378fa71-b260-4ac1-ac2e-08d7106e4353 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2019 19:36:45.6857 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: borchert@nist.gov X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR09MB3959 Archived-At: Subject: Re: [Sidrops] draft-ymbk-sidrops-ov-signal-02 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 19:36:51 -0000 VGhlIE5JU1Qgc3J4LXNlcnZlciAoZXh0ZXJuYWwgZXZhbHVhdG9yKSBhY3R1YWxseSBkb2VzIHBy b3ZpZGUgc3VjaCBvdXRzb3VyY2VkIFJQS0kgb3JpZ2luIHZhbGlkYXRpb24gLSBhcyB3ZWxsIGFz IEJHUHNlYyB2YWxpZGF0aW9uLiANCkZvciB0aGF0IHdlIGRldmVsb3BlZCBhIHByb3RvY29sIChz cngtc2VydmVyLXByb3RvY29sIC0gaHR0cHM6Ly9iZ3BzcnguYW50ZC5uaXN0Lmdvdi9iZ3Bzcngv ZG9jdW1lbnRzL3NyeC1zZXJ2ZXItcHJvdG9jb2wtMS0wLnR4dC5wZGYpIHdoZXJlIHRoZSByb3V0 ZXIgcmVxdWVzdHMgUlBLSSBvcmlnaW4gdmFsaWRhdGlvbiAoYW5kL29yIEJHUHNlYyBwYXRoIHZh bGlkYXRpb24pIGZyb20gdGhlIHNyeC1zZXJ2ZXIsIHdoaWNoIG5vdCBvbmx5IHJldHVybnMgdGhl IHZhbGlkYXRpb24gc3RhdGUgYnV0IGluIHJldHVybiBzdGFydHMgbW9uaXRvcmluZyB0aGUgcGFy dGljdWxhciByb3V0ZSBhbmQgcG9zc2libGUgY2hhbmdlcyBpbiB2YWxpZGF0aW9uIGR1ZSB0byBj aGFuZ2VzIGluIHRoZSBSUEtJLiBUaGlzICJleHRlcm5hbCB2YWxpZGF0b3IiIGNhbiBiZSBzaGFy ZWQgd2l0aGluIGFuIG9yZ2FuaXphdGlvbiBhbmQgYWxsb3dzIGNlbnRyYWxpemVkIFJQS0kgb3Jp Z2luIHZhbGlkYXRpb24gd2hpY2ggYXNzdXJlcyB0aGUgc2FtZSB2YWxpZGF0aW9uIHN0YXRlIHdp dGhpbiBhbGwgY29ubmVjdGVkIHJvdXRlcnMuIA0KDQpPbGl2ZXINCg0K77u/T24gNy8yNC8xOSwg MTowMSBBTSwgIlNpZHJvcHMgb24gYmVoYWxmIG9mIEpha29iIEhlaXR6IChqaGVpdHopIiA8c2lk cm9wcy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBqaGVpdHpAY2lzY28uY29tPiB3cm90 ZToNCg0KICAgIElmIFJPViByZXN1bHRzIGluIGFuIG9iamVjdGlvbmFibGUgdmFsaWRpdHksIHRo ZW4gdGhlIHJvdXRlIGlzIG5ldmVyIGluc3RhbGxlZC4NCiAgICBJZiBhICJTZW5kZXIiIGlzIHRv IG91dHNvdXJjZSB0aGUgUk9WIHByb2NlZHVyZSB0byBhbiAiRXZhbHVhdG9yIiwgdGhlbiB0aGUN CiAgICBTZW5kZXIgTVVTVCBOT1QgaW5zdGFsbCB0aGUgcm91dGUgdW50aWwgdGhlIEV2YWx1YXRv ciByZXR1cm5zIGFuIGFjY2VwdGFibGUNCiAgICB2YWxpZGl0eS4NCiAgICANCiAgICBSZWdhcmRz LA0KICAgIEpha29iLg0KICAgIA0KICAgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogICAg RnJvbTogU2lkcm9wcyA8c2lkcm9wcy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgSm9i IFNuaWpkZXJzDQogICAgU2VudDogVHVlc2RheSwgSnVseSAyMywgMjAxOSAyOjAwIFBNDQogICAg VG86IEpvaG4gU2N1ZGRlciA8amdzPTQwanVuaXBlci5uZXRAZG1hcmMuaWV0Zi5vcmc+DQogICAg Q2M6IHNpZHJvcHNAaWV0Zi5vcmcNCiAgICBTdWJqZWN0OiBSZTogW1NpZHJvcHNdIGRyYWZ0LXlt Ymstc2lkcm9wcy1vdi1zaWduYWwtMDINCiAgICANCiAgICBJIGhhdmUgcXVlc3Rpb25zIGFib3V0 IHRoaXMgZHJhZnQgYXMgd2VsbDoNCiAgICANCiAgICBXaHkgbm90IHR1bm5lbCBWUlBzIGluc2lk ZSBCR1AgaW4gYSBuZXcgQUZJIHRvIHBvcHVsYXRlIHRoZSBvcmlnaW4NCiAgICB2YWxpZGF0aW9u IGNhY2hlIG9uIHRoZSBlZGdlcz8gSSB0aGluayB0aGUgQkdQIHByb3RvY29sIGhhcyBzdWZmaWNp ZW50DQogICAgaG9va3MgdG8gbW9kZWwgdGhlIFJUUiBwcm90b2NvbCBmYWlybHkgY2xvc2VseS4N CiAgICANCiAgICBPciBwZXJoYXBzIEkgZG9uJ3QgdW5kZXJzdGFuZCB0aGUgYXBwZWFsIG9mIHRo aXMgbWVjaGFuaXNtLiBXaHkgbm90DQogICAgdXNlIFJUUj8gT3IgaWYgdGhlcmUgaXMgbm8gcm9v bSBvbiB0aGUgZWRnZSByb3V0ZXIgZm9yIHRoZSBtZW1vcnkgYQ0KICAgIFZSUCBjYWNoZT8gSWYg dGhlcmUgaXMgbm8gcm9vbSwgY2FuIGl0IGV2ZW4gZG8gSW50ZXJuZXQgQkdQPw0KICAgIA0KICAg IEtpbmQgcmVnYXJkcywNCiAgICANCiAgICBKb2INCiAgICANCiAgICBPbiBUdWUsIEp1bCAyMywg MjAxOSBhdCA4OjQ4IFBNIEpvaG4gU2N1ZGRlcg0KICAgIDxqZ3M9NDBqdW5pcGVyLm5ldEBkbWFy Yy5pZXRmLm9yZz4gd3JvdGU6DQogICAgPg0KICAgID4gVGhpbmdzIEkgd291bGQgaGF2ZSBzYWlk IGF0IHRoZSBtaWMgaGFkIHRpbWUgYWxsb3dlZDoNCiAgICA+DQogICAgPiAxLiBGb3Igd2hhdCBp dOKAmXMgd29ydGgsIFJGQyA0MjcxIHNlY3Rpb24gOS4xIHNheXMgeW91IGFyZW7igJl0IGFsbG93 ZWQgdG8gaGF2ZSB0aGlzIGZlYXR1cmU6DQogICAgPg0KICAgID4gICAgVGhlIGZ1bmN0aW9uIHRo YXQgY2FsY3VsYXRlcyB0aGUgZGVncmVlIG9mIHByZWZlcmVuY2UgZm9yIGEgZ2l2ZW4NCiAgICA+ ICAgIHJvdXRlIFNIQUxMIE5PVCB1c2UgYW55IG9mIHRoZSBmb2xsb3dpbmcgYXMgaXRzIGlucHV0 czogdGhlIGV4aXN0ZW5jZQ0KICAgID4gICAgb2Ygb3RoZXIgcm91dGVzLCB0aGUgbm9uLWV4aXN0 ZW5jZSBvZiBvdGhlciByb3V0ZXMsIG9yIHRoZSBwYXRoDQogICAgPiAgICBhdHRyaWJ1dGVzIG9m IG90aGVyIHJvdXRlcy4gIFJvdXRlIHNlbGVjdGlvbiB0aGVuIGNvbnNpc3RzIG9mIHRoZQ0KICAg ID4gICAgaW5kaXZpZHVhbCBhcHBsaWNhdGlvbiBvZiB0aGUgZGVncmVlIG9mIHByZWZlcmVuY2Ug ZnVuY3Rpb24gdG8gZWFjaA0KICAgID4gICAgZmVhc2libGUgcm91dGUsIGZvbGxvd2VkIGJ5IHRo ZSBjaG9pY2Ugb2YgdGhlIG9uZSB3aXRoIHRoZSBoaWdoZXN0DQogICAgPiAgICBkZWdyZWUgb2Yg cHJlZmVyZW5jZS4NCiAgICA+DQogICAgPiBBcyBJIHVuZGVyc3RhbmQgc2VjdGlvbiA1IG9mIHRo ZSBkcmFmdCAoYXMgaW5mb3JtZWQgYnkgUmFuZHnigJlzIGRlc2NyaXB0aW9uKSwgaXQgaXMgZXhh Y3RseSBtYW5kYXRpbmcgdGhhdCB3ZSB1c2UgdGhlIHBhdGggYXR0cmlidXRlcyBvZiBvdGhlciBy b3V0ZXMgZm9yIHRoZSBjb21wdXRhdGlvbiBvZiB0aGUgZGVncmVlIG9mIHByZWZlcmVuY2UuDQog ICAgPg0KICAgID4gMi4gQXNzdW1pbmcgd2Ugb3ZlcmNvbWUgdGhhdCBwcm9ibGVtLCB0aGVyZSBh cHBlYXJzIHRvIGJlIGEgc3RhYmlsaXR5IGFuZC9vciBmcmVzaG5lc3MgaXNzdWU6DQogICAgPg0K ICAgID4gLSBSUiBjbGllbnQgQyBhZHZlcnRpc2VzIHJvdXRlIEEgdG8gUlINCiAgICA+IC0gUlIg Y2hlY2tzIEEsIGRlY2lkZXMgaXQgaXMgaW52YWxpZA0KICAgID4gLSBSUiBhZHZlcnRpc2VzIEEs IG1hcmtlZCBpbnZhbGlkLCBiYWNrIHRvIEMuIENhbGwgdGhpcyBB4oCZLg0KICAgID4gLSBDIG9i ZXlzIHNlY3Rpb24gNSBhbmQgd2l0aGRyYXdzIEEgZnJvbSBldmVyeW9uZSAoaW5jbHVkaW5nIFJS KQ0KICAgID4gLSBGb2xsb3dpbmcgdGhlIG5vcm1hbCBvcGVyYXRpb24gb2YgQkdQLCBSUiB3aXRo ZHJhd3MgQScgZnJvbSBldmVyeW9uZSAoaW5jbHVkaW5nIEMpDQogICAgPiAtIE5vdyBB4oCZIGlz IG5vdCBpbiBD4oCZcyBBZGotUklCLUluLCBidXQgQSBpcy4gSSBiZWxpZXZlIHdoYXQgS2V5dXIg c2FpZCBvbiB0aGUgbWljIHdhcyB0aGF0IEMgaXMgc3VwcG9zZWQgdG8gaGF2ZSBwZXJzaXN0ZW50 bHkgbWFya2VkIEEgYXMgaW52YWxpZCBpbiB0aGUgZWFybGllciBzdGVwLCBwYXRjaGluZyB0aGUg b2J2aW91cyBzdGFiaWxpdHkgcHJvYmxlbS4NCiAgICA+IC0gTm93IHN1cHBvc2UgdGhlIGNvbnRl bnQgb2YgdGhlIFJQS0kgY2hhbmdlcyBzdWNoIHRoYXQgQSBpcyBub3cgdmFsaWQuDQogICAgPiDi gKYgaG93IGRvZXMgQSBldmVyIGZpbmQgdGhpcyBvdXQgYW5kIHVuLXN1cHByZXNzIEE/IEFzIGZh ciBhcyBJIGNhbiB0ZWxsLCB0aGUgYW5zd2VyIGlzLCDigJxpdCBkb2VzbuKAmXTigJ0uIFJSIG5l dmVyIHNlZXMgYSByZS1hbm5vdW5jZW1lbnQgb2YgQSwgc28gaXQgY2Fu4oCZdCByZS12YWxpZGF0 ZSBhbmQgYW5ub3VuY2UgaXQgdG8gYmUgdmFsaWQuIFNvIGl04oCZcyBqdXN0IHdlZGdlZC4NCiAg ICA+DQogICAgPiAzLiBGaW5hbGx5LCBzb21lb25lIGNvbW1lbnRlZCBhdCB0aGUgbWljIHRoYXQg dGhlIHdvcmsgdG8gdHVybiB2YWxpZGF0aW9uIG9uIGF0IEMgaXMgbGVzcyB0aGFuIHRoZSB3b3Jr IHRvIGRlYnVnLCBpbXBsZW1lbnQsIGFuZCBkZXBsb3kgdGhpcyBwcm9wb3NhbC4gSSBhZ3JlZS4N CiAgICA+DQogICAgPiBHaXZlbiB0aGUgYWJvdmUsIEnigJltIG5vdCBpbiBmYXZvciBvZiBhZG9w dGlvbiAodGhvdWdoIEnigJltIGFsd2F5cyB3aWxsaW5nIHRvIGJlIGNvbnZpbmNlZCkuDQogICAg Pg0KICAgID4gVGhhbmtzLA0KICAgID4NCiAgICA+IOKAlEpvaG4NCiAgICA+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPiBTaWRyb3BzIG1haWxp bmcgbGlzdA0KICAgID4gU2lkcm9wc0BpZXRmLm9yZw0KICAgID4gaHR0cHM6Ly9nY2MwMS5zYWZl bGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYu b3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc2lkcm9wcyZhbXA7ZGF0YT0wMiU3QzAxJTdDb2xp dmVyLmJvcmNoZXJ0JTQwbmlzdC5nb3YlN0M4M2QzN2NkMDZhMjA0NjBlNWNmMDA4ZDcwZmYzZmQ1 ZCU3QzJhYjVkODJmZDhmYTQ3OTdhOTNlMDU0NjU1YzYxZGVjJTdDMSU3QzElN0M2MzY5OTU0MTI5 MDg5Mjc4ODAmYW1wO3NkYXRhPTJ4RUh1RSUyRmk2Y1FWRjN4dGRRMWRpWWtCJTJCJTJCSnRNemkx UktDOFVKalJMajAlM0QmYW1wO3Jlc2VydmVkPTANCiAgICANCiAgICBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIFNpZHJvcHMgbWFpbGluZyBsaXN0 DQogICAgU2lkcm9wc0BpZXRmLm9yZw0KICAgIGh0dHBzOi8vZ2NjMDEuc2FmZWxpbmtzLnByb3Rl Y3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxt YW4lMkZsaXN0aW5mbyUyRnNpZHJvcHMmYW1wO2RhdGE9MDIlN0MwMSU3Q29saXZlci5ib3JjaGVy dCU0MG5pc3QuZ292JTdDODNkMzdjZDA2YTIwNDYwZTVjZjAwOGQ3MGZmM2ZkNWQlN0MyYWI1ZDgy ZmQ4ZmE0Nzk3YTkzZTA1NDY1NWM2MWRlYyU3QzElN0MxJTdDNjM2OTk1NDEyOTA4OTI3ODgwJmFt cDtzZGF0YT0yeEVIdUUlMkZpNmNRVkYzeHRkUTFkaVlrQiUyQiUyQkp0TXppMVJLQzhVSmpSTGow JTNEJmFtcDtyZXNlcnZlZD0wDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCiAgICBTaWRyb3BzIG1haWxpbmcgbGlzdA0KICAgIFNpZHJvcHNAaWV0 Zi5vcmcNCiAgICBodHRwczovL2djYzAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29t Lz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZz aWRyb3BzJmFtcDtkYXRhPTAyJTdDMDElN0NvbGl2ZXIuYm9yY2hlcnQlNDBuaXN0LmdvdiU3Qzgz ZDM3Y2QwNmEyMDQ2MGU1Y2YwMDhkNzBmZjNmZDVkJTdDMmFiNWQ4MmZkOGZhNDc5N2E5M2UwNTQ2 NTVjNjFkZWMlN0MxJTdDMSU3QzYzNjk5NTQxMjkwODkyNzg4MCZhbXA7c2RhdGE9MnhFSHVFJTJG aTZjUVZGM3h0ZFExZGlZa0IlMkIlMkJKdE16aTFSS0M4VUpqUkxqMCUzRCZhbXA7cmVzZXJ2ZWQ9 MA0KICAgIA0KDQo= From nobody Wed Jul 24 13:28:46 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE1C1205F8 for ; Wed, 24 Jul 2019 13:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov 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 UeSfXaHTpERj for ; Wed, 24 Jul 2019 13:28:42 -0700 (PDT) Received: from GCC01-CY1-obe.outbound.protection.outlook.com (mail-eopbgr830134.outbound.protection.outlook.com [40.107.83.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFBE9120494 for ; Wed, 24 Jul 2019 13:28:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=L4plfFpDvsoyRB1F8qCwGXm6oS/2tfmlJW/LomIcjp3LeSOJHU49RSESvYPIKWTGBPpNOtrevw8l97OELs6+sXNrbEdbvqzqM2KXzW0v0x/iELv6vHWfwrnHK9/4okkm07weCrO0FPdC5j5d3YJ0Shv20jJ2/dnP2jFRpmAUBRmG8ssM1HW9PztURtgiKBh2I6o6uQWx3NAbxwSWLq9GsNMEhP9zPoPztD5aH+6U8MIPtIALOWRr+/fDwUoqTx4bPzw89Zlr7gg/9BDRl5E3QRfRH2Hb8zuxXN0MkPUoPkV+unC1WpJcSU64X+uKEM548/dlK28gSiQLh1uM0Gk6aQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UkXJYnl211AnzIJSpOZYOw7nfrXGs9Fz+o1ieWOlIZI=; b=TQyMyy177pb5P0UysQdQwqOsYBsIqJlQBLDjvQKdCVYJMeOyYt5qJFvsZIXONTsjI1BBJDpkaN9OZfQwkRHglEAOomhCCLVJ6O/zLByIweMZROf5/ggi9nSy6vNBKawp8zquHFs6Fal3YNhxDtkDhrW7RzvTj+UBcbuE94MjgWTVQHFT1JseRAoldtb2H+l95N3I5aHGeWqg94uWT+EfZExekdtrQTwL8XjSKX08UCewEzw/2Q6Rw134E9oSp0qcPCwD7gUPMnaCRHhntsMcKxLSBUynhn/0XE5e9rGZKULn3gUG0ArmXgXMpHtvc1+Qu3xgwBWZrIryON+aca583w== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=nist.gov;dmarc=pass action=none header.from=nist.gov;dkim=pass header.d=nist.gov;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UkXJYnl211AnzIJSpOZYOw7nfrXGs9Fz+o1ieWOlIZI=; b=KWaopHSvDpxBd+TbnZ5y73LLbeEIOEAcFoSbWn3CAQ4Ei1jLSMHEeS2QVrzCZ+6yEIPme7X8ymzrFDxK/XkGAsZJ/DiRw5c03XQLJHV4xhd4471irl8fVDEbrbpcCC84R+DCcIsXymzv/T1g4nz6emIgMeOIZpivb6rDh8aO2tA= Received: from BN7PR09MB2596.namprd09.prod.outlook.com (52.135.255.12) by BN7PR09MB2883.namprd09.prod.outlook.com (52.135.243.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.16; Wed, 24 Jul 2019 20:28:38 +0000 Received: from BN7PR09MB2596.namprd09.prod.outlook.com ([fe80::a073:b2d8:358d:ab15]) by BN7PR09MB2596.namprd09.prod.outlook.com ([fe80::a073:b2d8:358d:ab15%7]) with mapi id 15.20.2008.014; Wed, 24 Jul 2019 20:28:38 +0000 From: "Montgomery, Douglas (Fed)" To: "Jakob Heitz (jheitz)" , Job Snijders , John Scudder CC: "sidrops@ietf.org" Thread-Topic: [Sidrops] draft-ymbk-sidrops-ov-signal-02 Thread-Index: AQHVQZfqdZEC8Ka1Vk6EHyhMX0ZkL6bYr+eAgACELECAAMJtgA== Date: Wed, 24 Jul 2019 20:28:38 +0000 Message-ID: <6390C259-74DA-40A5-A1C8-F8E477A83DE9@nist.gov> References: <77600356-557E-43F6-82AB-5AFFB830B984@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.c.190715 authentication-results: spf=none (sender IP is ) smtp.mailfrom=dougm@nist.gov; x-originating-ip: [31.133.137.153] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2052de0a-fcff-4e84-dc8a-08d7107582d4 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:BN7PR09MB2883; x-ms-traffictypediagnostic: BN7PR09MB2883: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0108A997B2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(39860400002)(396003)(376002)(136003)(13464003)(189003)(199004)(86362001)(14444005)(6436002)(5660300002)(53936002)(256004)(186003)(6486002)(110136005)(8676002)(66946007)(76116006)(91956017)(66574012)(6512007)(305945005)(81166006)(66446008)(36756003)(71190400001)(71200400001)(64756008)(66476007)(66556008)(81156014)(7736002)(316002)(58126008)(6306002)(966005)(6506007)(446003)(26005)(6116002)(25786009)(4326008)(2906002)(11346002)(561944003)(99286004)(3846002)(8936002)(68736007)(53546011)(14454004)(486006)(229853002)(76176011)(102836004)(33656002)(45080400002)(478600001)(6246003)(2616005)(476003)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN7PR09MB2883; H:BN7PR09MB2596.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: GnGmQ9DNR9+6HlLuoGN7/W1j9F9vwXweUnFm9XHQZChSEfV4V3+rfGI+OyDTV/wPl/HeMOhtjq3G2jkOt8Lv/jbdOL/8SoMDJjhii4ddBWdMRYuyvqxQoGc840OHnV3OuAUIiuQU4nD8Qa1V9Eyp9UlMwI4j9nK5JtiRtgD+28BdIAlY18f6ZdzE8dw7jwC7Z5gXxCdt61p4k1bY5q56oONxW1BEMVquy3TenSL3rdiy5WxYc49yUhDfhv4azQIK+vwP4JCGos2h+jRdXzIEyH5Rb68IUaOI6eXcF01heWYUlY5anxUzMwVy7mVAUZobT8j+eccnhyEY7Novpc1WZyhhAplg4LwjaPwzZt+0i+IdzR3PT52K7XrfXGNqD0M2OKZc7pl6PSJVUQcz6creq+Pxi9eiYkX8bsZKEAt8LUQ= Content-Type: text/plain; charset="utf-8" Content-ID: <1FB96F857754BD4582AB3CA9F8596228@namprd09.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 2052de0a-fcff-4e84-dc8a-08d7107582d4 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2019 20:28:38.6391 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: dougm@nist.gov X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR09MB2883 Archived-At: Subject: Re: [Sidrops] draft-ymbk-sidrops-ov-signal-02 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 20:28:44 -0000 U2V0IHRoZSB2YWxpZGF0aW9uIHN0YXRlIG9mIGEganVzdCByZWNlaXZlZCB1cGRhdGUgdG8gInVu ZGVmaW5lZCIuICANCg0KTGVhdmUgaXQgdG8gdGhlIG9wZXJhdG9yJ3MgbG9jYWwgcG9saWN5IHRv IGRlY2lkZSBpZiB0aGV5IHdpc2ggdG8gImlnbm9yZSB1bmRlZmluZWQiIChpLmUuLCB3YWl0IGZv ciB2YWxpZGF0aW9uIGJlZm9yZSBpbmNsdWRpbmcgaW4gZGVjaXNpb24gcHJvY2VzcyksIG9yIG5v dC4NCg0KZG91Z20NCi0tICANCkRvdWcgTW9udGdvbWVyeSwgTWFuYWdlciBJbnRlcm5ldCAmIFNj YWxhYmxlIFN5c3RlbXMgUmVzZWFyY2ggQCBOSVNUDQogDQoNCu+7v09uIDcvMjQvMTksIDE6MDEg QU0sICJTaWRyb3BzIG9uIGJlaGFsZiBvZiBKYWtvYiBIZWl0eiAoamhlaXR6KSIgPHNpZHJvcHMt Ym91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgamhlaXR6QGNpc2NvLmNvbT4gd3JvdGU6DQoN CiAgICBJZiBST1YgcmVzdWx0cyBpbiBhbiBvYmplY3Rpb25hYmxlIHZhbGlkaXR5LCB0aGVuIHRo ZSByb3V0ZSBpcyBuZXZlciBpbnN0YWxsZWQuDQogICAgSWYgYSAiU2VuZGVyIiBpcyB0byBvdXRz b3VyY2UgdGhlIFJPViBwcm9jZWR1cmUgdG8gYW4gIkV2YWx1YXRvciIsIHRoZW4gdGhlDQogICAg U2VuZGVyIE1VU1QgTk9UIGluc3RhbGwgdGhlIHJvdXRlIHVudGlsIHRoZSBFdmFsdWF0b3IgcmV0 dXJucyBhbiBhY2NlcHRhYmxlDQogICAgdmFsaWRpdHkuDQogICAgDQogICAgUmVnYXJkcywNCiAg ICBKYWtvYi4NCiAgICANCiAgICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAgIEZyb206 IFNpZHJvcHMgPHNpZHJvcHMtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEpvYiBTbmlq ZGVycw0KICAgIFNlbnQ6IFR1ZXNkYXksIEp1bHkgMjMsIDIwMTkgMjowMCBQTQ0KICAgIFRvOiBK b2huIFNjdWRkZXIgPGpncz00MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnPg0KICAgIENjOiBz aWRyb3BzQGlldGYub3JnDQogICAgU3ViamVjdDogUmU6IFtTaWRyb3BzXSBkcmFmdC15bWJrLXNp ZHJvcHMtb3Ytc2lnbmFsLTAyDQogICAgDQogICAgSSBoYXZlIHF1ZXN0aW9ucyBhYm91dCB0aGlz IGRyYWZ0IGFzIHdlbGw6DQogICAgDQogICAgV2h5IG5vdCB0dW5uZWwgVlJQcyBpbnNpZGUgQkdQ IGluIGEgbmV3IEFGSSB0byBwb3B1bGF0ZSB0aGUgb3JpZ2luDQogICAgdmFsaWRhdGlvbiBjYWNo ZSBvbiB0aGUgZWRnZXM/IEkgdGhpbmsgdGhlIEJHUCBwcm90b2NvbCBoYXMgc3VmZmljaWVudA0K ICAgIGhvb2tzIHRvIG1vZGVsIHRoZSBSVFIgcHJvdG9jb2wgZmFpcmx5IGNsb3NlbHkuDQogICAg DQogICAgT3IgcGVyaGFwcyBJIGRvbid0IHVuZGVyc3RhbmQgdGhlIGFwcGVhbCBvZiB0aGlzIG1l Y2hhbmlzbS4gV2h5IG5vdA0KICAgIHVzZSBSVFI/IE9yIGlmIHRoZXJlIGlzIG5vIHJvb20gb24g dGhlIGVkZ2Ugcm91dGVyIGZvciB0aGUgbWVtb3J5IGENCiAgICBWUlAgY2FjaGU/IElmIHRoZXJl IGlzIG5vIHJvb20sIGNhbiBpdCBldmVuIGRvIEludGVybmV0IEJHUD8NCiAgICANCiAgICBLaW5k IHJlZ2FyZHMsDQogICAgDQogICAgSm9iDQogICAgDQogICAgT24gVHVlLCBKdWwgMjMsIDIwMTkg YXQgODo0OCBQTSBKb2huIFNjdWRkZXINCiAgICA8amdzPTQwanVuaXBlci5uZXRAZG1hcmMuaWV0 Zi5vcmc+IHdyb3RlOg0KICAgID4NCiAgICA+IFRoaW5ncyBJIHdvdWxkIGhhdmUgc2FpZCBhdCB0 aGUgbWljIGhhZCB0aW1lIGFsbG93ZWQ6DQogICAgPg0KICAgID4gMS4gRm9yIHdoYXQgaXTigJlz IHdvcnRoLCBSRkMgNDI3MSBzZWN0aW9uIDkuMSBzYXlzIHlvdSBhcmVu4oCZdCBhbGxvd2VkIHRv IGhhdmUgdGhpcyBmZWF0dXJlOg0KICAgID4NCiAgICA+ICAgIFRoZSBmdW5jdGlvbiB0aGF0IGNh bGN1bGF0ZXMgdGhlIGRlZ3JlZSBvZiBwcmVmZXJlbmNlIGZvciBhIGdpdmVuDQogICAgPiAgICBy b3V0ZSBTSEFMTCBOT1QgdXNlIGFueSBvZiB0aGUgZm9sbG93aW5nIGFzIGl0cyBpbnB1dHM6IHRo ZSBleGlzdGVuY2UNCiAgICA+ICAgIG9mIG90aGVyIHJvdXRlcywgdGhlIG5vbi1leGlzdGVuY2Ug b2Ygb3RoZXIgcm91dGVzLCBvciB0aGUgcGF0aA0KICAgID4gICAgYXR0cmlidXRlcyBvZiBvdGhl ciByb3V0ZXMuICBSb3V0ZSBzZWxlY3Rpb24gdGhlbiBjb25zaXN0cyBvZiB0aGUNCiAgICA+ICAg IGluZGl2aWR1YWwgYXBwbGljYXRpb24gb2YgdGhlIGRlZ3JlZSBvZiBwcmVmZXJlbmNlIGZ1bmN0 aW9uIHRvIGVhY2gNCiAgICA+ICAgIGZlYXNpYmxlIHJvdXRlLCBmb2xsb3dlZCBieSB0aGUgY2hv aWNlIG9mIHRoZSBvbmUgd2l0aCB0aGUgaGlnaGVzdA0KICAgID4gICAgZGVncmVlIG9mIHByZWZl cmVuY2UuDQogICAgPg0KICAgID4gQXMgSSB1bmRlcnN0YW5kIHNlY3Rpb24gNSBvZiB0aGUgZHJh ZnQgKGFzIGluZm9ybWVkIGJ5IFJhbmR54oCZcyBkZXNjcmlwdGlvbiksIGl0IGlzIGV4YWN0bHkg bWFuZGF0aW5nIHRoYXQgd2UgdXNlIHRoZSBwYXRoIGF0dHJpYnV0ZXMgb2Ygb3RoZXIgcm91dGVz IGZvciB0aGUgY29tcHV0YXRpb24gb2YgdGhlIGRlZ3JlZSBvZiBwcmVmZXJlbmNlLg0KICAgID4N CiAgICA+IDIuIEFzc3VtaW5nIHdlIG92ZXJjb21lIHRoYXQgcHJvYmxlbSwgdGhlcmUgYXBwZWFy cyB0byBiZSBhIHN0YWJpbGl0eSBhbmQvb3IgZnJlc2huZXNzIGlzc3VlOg0KICAgID4NCiAgICA+ IC0gUlIgY2xpZW50IEMgYWR2ZXJ0aXNlcyByb3V0ZSBBIHRvIFJSDQogICAgPiAtIFJSIGNoZWNr cyBBLCBkZWNpZGVzIGl0IGlzIGludmFsaWQNCiAgICA+IC0gUlIgYWR2ZXJ0aXNlcyBBLCBtYXJr ZWQgaW52YWxpZCwgYmFjayB0byBDLiBDYWxsIHRoaXMgQeKAmS4NCiAgICA+IC0gQyBvYmV5cyBz ZWN0aW9uIDUgYW5kIHdpdGhkcmF3cyBBIGZyb20gZXZlcnlvbmUgKGluY2x1ZGluZyBSUikNCiAg ICA+IC0gRm9sbG93aW5nIHRoZSBub3JtYWwgb3BlcmF0aW9uIG9mIEJHUCwgUlIgd2l0aGRyYXdz IEEnIGZyb20gZXZlcnlvbmUgKGluY2x1ZGluZyBDKQ0KICAgID4gLSBOb3cgQeKAmSBpcyBub3Qg aW4gQ+KAmXMgQWRqLVJJQi1JbiwgYnV0IEEgaXMuIEkgYmVsaWV2ZSB3aGF0IEtleXVyIHNhaWQg b24gdGhlIG1pYyB3YXMgdGhhdCBDIGlzIHN1cHBvc2VkIHRvIGhhdmUgcGVyc2lzdGVudGx5IG1h cmtlZCBBIGFzIGludmFsaWQgaW4gdGhlIGVhcmxpZXIgc3RlcCwgcGF0Y2hpbmcgdGhlIG9idmlv dXMgc3RhYmlsaXR5IHByb2JsZW0uDQogICAgPiAtIE5vdyBzdXBwb3NlIHRoZSBjb250ZW50IG9m IHRoZSBSUEtJIGNoYW5nZXMgc3VjaCB0aGF0IEEgaXMgbm93IHZhbGlkLg0KICAgID4g4oCmIGhv dyBkb2VzIEEgZXZlciBmaW5kIHRoaXMgb3V0IGFuZCB1bi1zdXBwcmVzcyBBPyBBcyBmYXIgYXMg SSBjYW4gdGVsbCwgdGhlIGFuc3dlciBpcywg4oCcaXQgZG9lc27igJl04oCdLiBSUiBuZXZlciBz ZWVzIGEgcmUtYW5ub3VuY2VtZW50IG9mIEEsIHNvIGl0IGNhbuKAmXQgcmUtdmFsaWRhdGUgYW5k IGFubm91bmNlIGl0IHRvIGJlIHZhbGlkLiBTbyBpdOKAmXMganVzdCB3ZWRnZWQuDQogICAgPg0K ICAgID4gMy4gRmluYWxseSwgc29tZW9uZSBjb21tZW50ZWQgYXQgdGhlIG1pYyB0aGF0IHRoZSB3 b3JrIHRvIHR1cm4gdmFsaWRhdGlvbiBvbiBhdCBDIGlzIGxlc3MgdGhhbiB0aGUgd29yayB0byBk ZWJ1ZywgaW1wbGVtZW50LCBhbmQgZGVwbG95IHRoaXMgcHJvcG9zYWwuIEkgYWdyZWUuDQogICAg Pg0KICAgID4gR2l2ZW4gdGhlIGFib3ZlLCBJ4oCZbSBub3QgaW4gZmF2b3Igb2YgYWRvcHRpb24g KHRob3VnaCBJ4oCZbSBhbHdheXMgd2lsbGluZyB0byBiZSBjb252aW5jZWQpLg0KICAgID4NCiAg ICA+IFRoYW5rcywNCiAgICA+DQogICAgPiDigJRKb2huDQogICAgPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4gU2lkcm9wcyBtYWlsaW5nIGxp c3QNCiAgICA+IFNpZHJvcHNAaWV0Zi5vcmcNCiAgICA+IGh0dHBzOi8vZ2NjMDEuc2FmZWxpbmtz LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUy Rm1haWxtYW4lMkZsaXN0aW5mbyUyRnNpZHJvcHMmYW1wO2RhdGE9MDIlN0MwMSU3Q2RvdWdtJTQw bmlzdC5nb3YlN0M1MzU2NmEzOWE2YTA0YWQzMTU5ZTA4ZDcwZmYzZmQ4NyU3QzJhYjVkODJmZDhm YTQ3OTdhOTNlMDU0NjU1YzYxZGVjJTdDMSU3QzElN0M2MzY5OTU0MTI5MzA5MjAyNjMmYW1wO3Nk YXRhPTZuQ0EzWmd2dkYwU2tsZFFVUjFUVkNpRTFiWUxoUXdDTGh4c1QzQTlUem8lM0QmYW1wO3Jl c2VydmVkPTANCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KICAgIFNpZHJvcHMgbWFpbGluZyBsaXN0DQogICAgU2lkcm9wc0BpZXRmLm9y Zw0KICAgIGh0dHBzOi8vZ2NjMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3Vy bD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNpZHJv cHMmYW1wO2RhdGE9MDIlN0MwMSU3Q2RvdWdtJTQwbmlzdC5nb3YlN0M1MzU2NmEzOWE2YTA0YWQz MTU5ZTA4ZDcwZmYzZmQ4NyU3QzJhYjVkODJmZDhmYTQ3OTdhOTNlMDU0NjU1YzYxZGVjJTdDMSU3 QzElN0M2MzY5OTU0MTI5MzA5MjAyNjMmYW1wO3NkYXRhPTZuQ0EzWmd2dkYwU2tsZFFVUjFUVkNp RTFiWUxoUXdDTGh4c1QzQTlUem8lM0QmYW1wO3Jlc2VydmVkPTANCiAgICBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIFNpZHJvcHMgbWFpbGluZyBs aXN0DQogICAgU2lkcm9wc0BpZXRmLm9yZw0KICAgIGh0dHBzOi8vZ2NjMDEuc2FmZWxpbmtzLnBy b3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1h aWxtYW4lMkZsaXN0aW5mbyUyRnNpZHJvcHMmYW1wO2RhdGE9MDIlN0MwMSU3Q2RvdWdtJTQwbmlz dC5nb3YlN0M1MzU2NmEzOWE2YTA0YWQzMTU5ZTA4ZDcwZmYzZmQ4NyU3QzJhYjVkODJmZDhmYTQ3 OTdhOTNlMDU0NjU1YzYxZGVjJTdDMSU3QzElN0M2MzY5OTU0MTI5MzA5MjAyNjMmYW1wO3NkYXRh PTZuQ0EzWmd2dkYwU2tsZFFVUjFUVkNpRTFiWUxoUXdDTGh4c1QzQTlUem8lM0QmYW1wO3Jlc2Vy dmVkPTANCiAgICANCg0K From nobody Wed Jul 24 22:04:41 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7A712020A for ; Wed, 24 Jul 2019 22:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=JdnV5ygu; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=cFZA/C8b 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 GB8HsQi4JSNH for ; Wed, 24 Jul 2019 22:04:36 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A237B1201EE for ; Wed, 24 Jul 2019 22:04:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3665; q=dns/txt; s=iport; t=1564031076; x=1565240676; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=10KAF3OS4pL4FX3h+z2Hoz3G7B8jalTwymHZcjS0Ojg=; b=JdnV5ygusQ75jsCzcFHHw2eSFtMo9OSGiptoxClHgvdu7d42z4aqwF1w 4rXq7woMp5ix/KacArdvgGcqZRhOtOoheCOB7aRI7dTY/VLCb1ee4kVdA aE8SiinVwllhboQQoUsLCqX7xICu1EeOOMNS6fh8rKH62nzopqP5Lodqz 8=; IronPort-PHdr: =?us-ascii?q?9a23=3AHGHUYBW0dvCGUryGlEeZmtnDBlLV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSANSJ8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dE7KdehAk8GIiAAEz/IuTtank4HMlDSE1N9HCgOk8TE8H7NBXf?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BuAAB3Nzld/4kNJK1lHQEBBQEHBQG?= =?us-ascii?q?BUwgBCwGBQyQsA21VIAQLKodkA4RSiCpMgg+XUIEugSQDVAkBAQEMAQEYDQg?= =?us-ascii?q?CAQGDekYCglkjNAkOAQMBAQQBAQIBBm2FHgELhUoBAQEBBAEQKAYBASwMCwY?= =?us-ascii?q?BGQQBAR83Cx0JAQQTCBqDAYFqAx0BAgyhQwKBOIhggiOCeQEBBYE2Ag5Bgwc?= =?us-ascii?q?YghMJgTQBi18XgUA/gRFGgwqCYQEBAgEBFoFJgzuCJqoCbQkCghmGWY1Sgi1?= =?us-ascii?q?thjiOOIo6gn2HSpAKAgQCBAUCDgEBBYFQOIFYcBUaIYJsCYI5g3GFFIU/coE?= =?us-ascii?q?pjE0BAQ?= X-IronPort-AV: E=Sophos;i="5.64,305,1559520000"; d="scan'208";a="607080826" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Jul 2019 05:04:34 +0000 Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x6P54Xuw015986 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 25 Jul 2019 05:04:34 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 25 Jul 2019 00:04:33 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 25 Jul 2019 00:04:31 -0500 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 25 Jul 2019 00:04:31 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MS6nWaRUmJO9GNpTuUtz50W+Xp3xiNSzEyb1M5vRApOQxuxGvPD1A8+bdYbt9vPbGUZWNPOo5xVuXfuW4XHDmhYJQTI+i5v7serS172D/TYAuz8yJo54ESt86pjP1wks1yjFMYapEGNvlpGVu7+Ouvbz4TYvu+LGOZgfOsy7WTAhuMPn/dZM9EMbsNlDaVbcCx9yinMIRE8P5h74QcFE/hkRoo7/iuysrdc6zck165l5gq9J8Pe2m3bdSoLjEFbiFqmTd1p9bpUMjnHH+uWwp80GnGGIemBq75sSsk/5BUu8zleHdp1pgZ/V4re+Ug2nc6KdxfO/yf2WWPjdqSU1Dw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mxgM7BGpE43EQcSJSL9LPV/sov+8vMpgH7RXpEu9f58=; b=b+7UKGnzVLQAcOYdOkGl1L7WGHhv5oAQ7XFm1l0DX2YB9Y5C3h7f6L6xNQ0DQJClnqgxWAIkLrLRJ+ehCQpLlZNx9msFcnNaKziZqwvgr6JCXN6cPn5Gp0u+8G3h2bHWHdr0/xKx536VtduGAdO8+wyUoCl1NgBiRSjoP9189A5joyko3UAFReAkJIcFTAHftFbq5F4wgNN9l98NetRyf13PJIhKMzcwq/StBR+FrEiFR8sQ8COIeYmZsjiV1G0AwKgdLS3dARW/U6D8AcvKnTLZtaAQFelRJ13gXTXWbB0+gucoWRj/q4R1OSOFsTCZDSuJ8XEGvOYJ3b4hOUJkcw== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cisco.com;dmarc=pass action=none header.from=cisco.com;dkim=pass header.d=cisco.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mxgM7BGpE43EQcSJSL9LPV/sov+8vMpgH7RXpEu9f58=; b=cFZA/C8bTJ+HzQUVcyI6KxptLYIrhGgeqqtzVma7P2O4y/zDeWxMvjRjKTB7+jc+b2vbk48o5pgAor41lY59i01tc4kohyl/Dh2k+n87hJ1deYWHHoujEpT1J7JGoZ6xwUGf6qy73DoRggqWEpcLidvIpVQCp/QysYsJxwRunLk= Received: from BYAPR11MB3751.namprd11.prod.outlook.com (20.178.238.144) by BYAPR11MB2806.namprd11.prod.outlook.com (52.135.228.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.17; Thu, 25 Jul 2019 05:04:30 +0000 Received: from BYAPR11MB3751.namprd11.prod.outlook.com ([fe80::a894:a92:ad6e:ee2a]) by BYAPR11MB3751.namprd11.prod.outlook.com ([fe80::a894:a92:ad6e:ee2a%7]) with mapi id 15.20.2094.017; Thu, 25 Jul 2019 05:04:30 +0000 From: "Jakob Heitz (jheitz)" To: "sidrops@ietf.org" Thread-Topic: draft-ietf-sidrops-aspa-verification-01: Handling unknowns Thread-Index: AdVCo7iaisAZRDdHT/a/3q2UygwIOw== Date: Thu, 25 Jul 2019 05:04:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jheitz@cisco.com; x-originating-ip: [2001:420:c0c8:1001::216] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 34058dd3-912e-41cd-59ba-08d710bd9381 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB2806; x-ms-traffictypediagnostic: BYAPR11MB2806: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0109D382B0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(396003)(346002)(39860400002)(136003)(376002)(13464003)(199004)(189003)(33656002)(9686003)(6116002)(25786009)(6436002)(53936002)(476003)(74316002)(2906002)(5640700003)(7736002)(6506007)(6306002)(55016002)(14444005)(256004)(53546011)(305945005)(102836004)(7696005)(46003)(14454004)(186003)(66574012)(64756008)(66446008)(6916009)(66946007)(966005)(66556008)(66476007)(15650500001)(486006)(68736007)(76116006)(2351001)(99286004)(2501003)(52536014)(86362001)(8676002)(5660300002)(81156014)(81166006)(478600001)(1730700003)(316002)(71200400001)(8936002)(71190400001); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB2806; H:BYAPR11MB3751.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: VIi8OB0MvbuxOCyXQLjBCNC19ZjJB2zsxrPvpWHkWe/ZGqvOSS5yQcSe/VGu2UedSv8j537ELUgiqa3l2ht3jOWR9FmugIUbIfkbIGiZ1mI1ixFMMOreT9/XOufzuxze+isZKamDnMqaexTK56zUDQhoxmoCvzCI2UjihQ8wD1EFCbLjaKxdCcAvVrdPij/zRPjnURHbYjxXk3BUczIzscPnL4F30Z+e1f5+DPHZeyUOFSB2+/cAR815+WD8P0Lu6LPoa1/zruBPJ2vZDdk11/jAFMH/IN16kQstIhblgkuUiGMxGFIevN2OggoKsiiFYhkb84CpkACuY1L6tUXp245/lr4aIdppVefw5XJC3ZeHnvnMammkpeNC/lMMqz3+F9ds/L6Q6cVG2X1DKAbZeT2bjEGk15p4a+TFKSQUh7U= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 34058dd3-912e-41cd-59ba-08d710bd9381 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2019 05:04:30.4126 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jheitz@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2806 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.22, xch-aln-012.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: [Sidrops] draft-ietf-sidrops-aspa-verification-01: Handling unknowns X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 05:04:39 -0000 I believe the path verification algorithm works when all ASes in the as-pat= h make attestations. If some of the ASes make no attestations, then a more co= mplete algorithm is as follows: For every sequence (A, B, C) of consecutive ASes in an AS-path: If A attests that B is not a provider and C attests that B is not a provide= r, then B leaked the route: B is transiting for free. The segment is invalid. If either A or C attests that B is a provider, then the AS-path segment (A= , B, C) is valid. If neither A nor C make an attestation, then the leak state is unknown. Eve= n if B lists both A and C as providers, it is not necessarily a leak, becau= se either A or C could consider B as a provider for some of their routes, e= ven though they don't attest to it. If all the path segments are valid, then the whole path is valid. If any of the path segments is invalid, then the whole path is invalid. Else, at least one path segment is unknown and one more rule must be applie= d: for any sequence of ASes (A, B1, ..., Bn, C), if A attests that B1 is no= t a provider and C attests that Bn is not a provider, then the AS-path is i= nvalid. This is for any number of Bx greater than 1. This algorithm breaks the AS-PATH into triples instead of pairs. For example, the AS_PATH (A,B,C,D,E) is broken into the triples: (A,B,C), (B,C,D), (C,D,E). I find it easier to reason about it like that. It can probably be re-worded into pairs. An additional point: If AS-SETs exist then complete sequences between the AS-SETs can be checked= for invalidity. The best such an AS-PATH can get is unknown, but it can also be verified in= valid. Regards, Jakob. -----Original Message----- From: Sidrops On Behalf Of internet-drafts@ietf.= org Sent: Monday, July 8, 2019 1:24 PM To: i-d-announce@ietf.org Cc: sidrops@ietf.org Subject: [Sidrops] I-D Action: draft-ietf-sidrops-aspa-verification-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIDR Operations WG of the IETF. Title : Verification of AS_PATH Using the Resource Certif= icate Public Key Infrastructure and Autonomous System Provider Authorizatio= n Authors : Alexander Azimov Eugene Bogomazov Keyur Patel Job Snijders Filename : draft-ietf-sidrops-aspa-verification-01.txt Pages : 10 Date : 2019-07-08 Abstract: This document defines the semantics of an Autonomous System Provider Authorization object in the Resource Public Key Infrastructure to verify the AS_PATH attribute of routes advertised in the Border Gateway Protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-verification/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-aspa-verification-01 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-verification-= 01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidrops-aspa-verification-01 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Sidrops mailing list Sidrops@ietf.org https://www.ietf.org/mailman/listinfo/sidrops From nobody Thu Jul 25 13:20:39 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7432A1201D1 for ; Thu, 25 Jul 2019 13:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 OvocmEps1ViB for ; Thu, 25 Jul 2019 13:20:33 -0700 (PDT) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 297C21201EC for ; Thu, 25 Jul 2019 13:20:33 -0700 (PDT) Received: by mail-ot1-x329.google.com with SMTP id l15so52985419otn.9 for ; Thu, 25 Jul 2019 13:20:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=C6HcEAFqBiB/GCPZVytIGe+WK4d7povDuJ8PF5lOtHI=; b=cldjG/mpyp17/RhPF2nt+V/tKW3hnT5Kt2P0FHbmfSwMZx9RFWNFagT/2AoqSrqCbp EL5UUPhmq6XzEhPAQTmd6HSSPv9Yg92tL4ocKEs2t4H0v9CrUgF85JBpto2nBCzv3kv9 e9BkcpwteZyaP5HBY1el2aRUqyzhmpRUWh44tCIg6t6E+MrWhd/ALsUM3M7zyQ1EpmbE HVLBG274LoezZKe7AS+Dn0I7/jAK5oiAYtEi3OY8vsohI4U5pRUM1pT8ZdXCcRyc/RFW /zGP2KIuz3E/r/xLqge7lLrS7P8JZQhJn/K8Lh6fO8VGrEH/04KpqENUOame//Y3oEyg XXJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=C6HcEAFqBiB/GCPZVytIGe+WK4d7povDuJ8PF5lOtHI=; b=s0IjHhI/RU+sH+VpaI/jXiSu/dMnf9T0pudwm19zEq6Jp3jEO0kaq0P1yxhuVQW83r lRJPZPgDxDGrzIcIkXCZa4Y3vL931qlMXE7fcwUBlnMzQ00WMjCz0mLEBZFA8KmAIphm BGfvtJ0k67WoZ8u4oeLdIejlH6xIV9IQ6JLgYdqZRepSbP+beOSVx4EtY5p85b1A9egY qdYkf/+KL0mg5w+Oq4JknTfHG2PPY+MzCozb1A2yWOJvTRCWVXUpml+nvPuGtpMzb84H 9dWbrGEHXOLVML+/x5Ve08w8n9a28SJc7GUOc8Wd2ciB+XyF6d3rXXfmNalu+A46C9e8 YZrw== X-Gm-Message-State: APjAAAUlsx5anzUddzrVhJfPPjoBOo621HwhXQ/USRrPAuwjfN7bamqm omb2a+yP/1qQtLZO5CkKopUEjldCG8706d/vLxM= X-Google-Smtp-Source: APXvYqzkP2TV/PL7ZxPzJLM4tuJNQVR/0kUg8U3hWJVI0UNUowhhHIJwJ1SX6+fxygnWn5GBP7e0SFowVGcrNac6cIM= X-Received: by 2002:a9d:7411:: with SMTP id n17mr62102122otk.27.1564086032332; Thu, 25 Jul 2019 13:20:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alexander Azimov Date: Thu, 25 Jul 2019 23:20:20 +0300 Message-ID: To: "Jakob Heitz (jheitz)" Cc: "sidrops@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005afd81058e872826" Archived-At: Subject: Re: [Sidrops] draft-ietf-sidrops-aspa-verification-01: Handling unknowns X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 20:20:37 -0000 --0000000000005afd81058e872826 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Jakob, I believe your reading of the ASPA verification procedure is incorrect. Section 4 defines pairs wise verification procedure (let's call pair_verification) which returns valid, invalid and unknown. Sections 5.1 and 5.2 define verification procedure for upstream and downstream path respectively. In these procedures, the 'valid' and 'unknown' outcome of pair_verification is the same. These procedures return 'valid', 'invalid' and 'unverifiable' (in case of valid AS_SEQ + presence of AS_SET). So, your assumption that the algorithm works when all ASes in the as-path make attestations is incorrect. To perform verification you don't need to split ASPATH into triplets (or even bigger windows). I sent previously a linear function that makes verification for the downstream path, for the upstream path it even simpler. Since you are already working on the implementation I suggest to discuss it in person before the end of this meeting. It makes me really anxious if the specification is unclear for implementers. =D1=87=D1=82, 25 =D0=B8=D1=8E=D0=BB. 2019 =D0=B3. =D0=B2 08:04, Jakob Heitz= (jheitz) : > I believe the path verification algorithm works when all ASes in the > as-path > make attestations. If some of the ASes make no attestations, then a more > complete > algorithm is as follows: > > For every sequence (A, B, C) of consecutive ASes in an AS-path: > If A attests that B is not a provider and C attests that B is not a > provider, > then B leaked the route: B is transiting for free. The segment is invalid= . > If either A or C attests that B is a provider, then the AS-path segment > (A, B, C) is valid. > If neither A nor C make an attestation, then the leak state is unknown. > Even if B lists both A and C as providers, it is not necessarily a leak, > because either A or C could consider B as a provider for some of their > routes, even though they don't attest to it. > > If all the path segments are valid, then the whole path is valid. > If any of the path segments is invalid, then the whole path is invalid. > Else, at least one path segment is unknown and one more rule must be > applied: for any sequence of ASes (A, B1, ..., Bn, C), if A attests that = B1 > is not a provider and C attests that Bn is not a provider, then the AS-pa= th > is invalid. This is for any number of Bx greater than 1. > > This algorithm breaks the AS-PATH into triples instead of pairs. > For example, the AS_PATH (A,B,C,D,E) is broken into the triples: > (A,B,C), (B,C,D), (C,D,E). > I find it easier to reason about it like that. > It can probably be re-worded into pairs. > > An additional point: > If AS-SETs exist then complete sequences between the AS-SETs can be > checked for invalidity. > The best such an AS-PATH can get is unknown, but it can also be verified > invalid. > > Regards, > Jakob. > > -----Original Message----- > From: Sidrops On Behalf Of > internet-drafts@ietf.org > Sent: Monday, July 8, 2019 1:24 PM > To: i-d-announce@ietf.org > Cc: sidrops@ietf.org > Subject: [Sidrops] I-D Action: draft-ietf-sidrops-aspa-verification-01.tx= t > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the SIDR Operations WG of the IETF. > > Title : Verification of AS_PATH Using the Resource > Certificate Public Key Infrastructure and Autonomous System Provider > Authorization > Authors : Alexander Azimov > Eugene Bogomazov > Keyur Patel > Job Snijders > Filename : draft-ietf-sidrops-aspa-verification-01.txt > Pages : 10 > Date : 2019-07-08 > > Abstract: > This document defines the semantics of an Autonomous System Provider > Authorization object in the Resource Public Key Infrastructure to > verify the AS_PATH attribute of routes advertised in the Border > Gateway Protocol. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-verification/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-sidrops-aspa-verification-01 > > https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-verificatio= n-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidrops-aspa-verification-= 01 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > --=20 Best regards, Alexander Azimov --0000000000005afd81058e872826 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Jakob,

I believe your readin= g of the ASPA verification procedure is incorrect.

Section 4 defines pairs wise verification procedure (let's call p= air_verification) which returns valid, invalid and unknown.
S= ections 5.1 and 5.2 define verification procedure for upstream and downstre= am path respectively.

In these procedures, th= e 'valid' and 'unknown' outcome of pair_verification is the= same. These procedures return 'valid', 'invalid' and '= unverifiable' (in case of valid AS_SEQ + presence of AS_SET). So, your = assumption that the algorithm works when all ASes in the as-path make attes= tations is incorrect.

To perform verification=C2= =A0you don't need to split <= span class=3D"gmail-gr_ gmail-gr_1289 gmail-gr-alert gmail-gr_spell gmail-g= r_inline_cards gmail-gr_run_anim gmail-ContextualSpelling gmail-ins-del gma= il-multiReplace" id=3D"gmail-1289">ASPATH into triplets (or even big= ger windows). I sent previously a linear function that makes verification f= or the downstream path, for the upstream path it even simpler. Since you ar= e already working on the implementation I suggest to discuss it in person b= efore the end of this meeting. It makes me really anxious if the specificat= ion is unclear for implementers.

=D1=87=D1=82, 25 =D0=B8=D1=8E=D0= =BB. 2019 =D0=B3. =D0=B2 08:04, Jakob Heitz (jheitz) <jheitz@cisco.com>:
I believe the path verification algorithm works= when all ASes in the as-path
make attestations. If some of the ASes make no attestations, then a more co= mplete
algorithm is as follows:

For every sequence (A, B, C) of consecutive ASes in an AS-path:
If A attests that B is not a provider and C attests that B is not a provide= r,
then B leaked the route: B is transiting for free. The segment is invalid.<= br> If either A or C attests that B is a provider, then the AS-path segment=C2= =A0 (A, B, C) is valid.
If neither A nor C make an attestation, then the leak state is unknown. Eve= n if B lists both A and C as providers, it is not necessarily a leak, becau= se either A or C could consider B as a provider for some of their routes, e= ven though they don't attest to it.

If all the path segments are valid, then the whole path is valid.
If any of the path segments is invalid, then the whole path is invalid.
Else, at least one path segment is unknown and one more rule must be applie= d: for any sequence of ASes (A, B1, ..., Bn, C), if A attests that B1 is no= t a provider and C attests that Bn is not a provider, then the AS-path is i= nvalid. This is for any number of Bx greater than 1.

This algorithm breaks the AS-PATH into triples instead of pairs.
For example, the AS_PATH (A,B,C,D,E) is broken into the triples:
(A,B,C), (B,C,D), (C,D,E).
I find it easier to reason about it like that.
It can probably be re-worded into pairs.

An additional point:
If AS-SETs exist then complete sequences between the AS-SETs can be checked= for invalidity.
The best such an AS-PATH can get is unknown, but it can also be verified in= valid.

Regards,
Jakob.

-----Original Message-----
From: Sidrops <sidrops-bounces@ietf.org> On Behalf Of internet-drafts@ietf.org
Sent: Monday, July 8, 2019 1:24 PM
To: i-d-announce= @ietf.org
Cc: sidrops@ietf.org<= /a>
Subject: [Sidrops] I-D Action: draft-ietf-sidrops-aspa-verification-01.txt<= br>

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the SIDR Operations WG of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Verification of AS_PATH Using the Resource Certificate Public Key Infrastr= ucture and Autonomous System Provider Authorization
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Alex= ander Azimov
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Eugene Bogomazov
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Keyur Patel
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Job Snijders
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-sidrops-aspa-verification-01.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 10
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2019-07-08

Abstract:
=C2=A0 =C2=A0This document defines the semantics of an Autonomous System Pr= ovider
=C2=A0 =C2=A0Authorization object in the Resource Public Key Infrastructure= to
=C2=A0 =C2=A0verify the AS_PATH attribute of routes advertised in the Borde= r
=C2=A0 =C2=A0Gateway Protocol.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/d= oc/draft-ietf-sidrops-aspa-verification/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft= -ietf-sidrops-aspa-verification-01
https://datatracker.iet= f.org/doc/html/draft-ietf-sidrops-aspa-verification-01

A diff from the previous version is available at:
https://www.ietf.org/rfcd= iff?url2=3Ddraft-ietf-sidrops-aspa-verification-01


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
Sidrops mailing list
Sidrops@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sidrops

_______________________________________________
Sidrops mailing list
Sidrops@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sidrops


--
Best regards,
Alexander Azimov
--0000000000005afd81058e872826-- From nobody Thu Jul 25 22:38:57 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F15C51202A7 for ; Thu, 25 Jul 2019 22:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Nv6Y9fnx; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=MHKGum0Y 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 Lg-16YrU4TU3 for ; Thu, 25 Jul 2019 22:38:51 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87DD81202A5 for ; Thu, 25 Jul 2019 22:38:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28032; q=dns/txt; s=iport; t=1564119531; x=1565329131; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=7FA1y6IgdtttWeWFnVFecfhZVcUyFtpwHTO4KSTzOg4=; b=Nv6Y9fnx5hgLg3CZr77nAhD4pkGeLuHtvuiPAjHaQVPD9Z5Fb7mE5eaf VMyB98Gqb2slVLA6qKA02lyqsqnzWqrwrzaj+AL2pQ9b0G0pUWKun0LCg 8O+wpSKJbpfn0jXD41BtIdIcx6LepMFcQSC21/RoYqk7F/A0J1Cq8Hcps 4=; IronPort-PHdr: =?us-ascii?q?9a23=3AJinPfhD+/aD32qZAQuHfUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qg83kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuLv7nbjAoNM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAACckDpd/5ldJa1mGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUwYBAQELAYEULyQsA21VIAQLKoQeg0cDhFKILoJbfohWjX+BLoE?= =?us-ascii?q?kA1QJAQEBDAEBGAEMCAIBAYN6RgIXgkcjNAkOAQMBAQQBAQIBBm2FHgyFSgE?= =?us-ascii?q?BAQQBARARChMBASwLAQsEAgEGAg4DBAEBKAMCAgIfBgsUCQgBAQQOBQgagwG?= =?us-ascii?q?BHU0DHQECDJEDkGACgTiIYHGBMoJ6AQEFgTYCDkGDAA0LghMJgTQBi14XgUA?= =?us-ascii?q?/gRFGghc1PoIaRwEBAgEBFoFJKwkIgk0ygiaOfoR/iG2NIS1ACQKCGoZZiUC?= =?us-ascii?q?EEoItbYY4jjqKPIpIgXWKR4NPAgQCBAUCDgEBBYE9EziBWHAVGiGCbAmCOYN?= =?us-ascii?q?xhRSFP3IBgSiNXwEB?= X-IronPort-AV: E=Sophos;i="5.64,309,1559520000"; d="scan'208,217";a="607899259" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Jul 2019 05:38:50 +0000 Received: from XCH-RCD-020.cisco.com (xch-rcd-020.cisco.com [173.37.102.30]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x6Q5coHU019318 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 26 Jul 2019 05:38:50 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 26 Jul 2019 00:38:48 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 26 Jul 2019 01:38:48 -0400 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 26 Jul 2019 00:38:47 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=g2sfmVxIYKFMS/hMA3KVEHuNV1k2BacijD+UKsJkyYXhjjDTkCuL9DG/PE5xmcQQv9Zen1/WdHw8Yk5ypZfFHAlpWHsneX7FbLAQVhaC9ggPUIV1ZMip21QLLlmg9csv4vbrQmmyn8Yhqu2rMqCfJOAf4at1UXl+GdRXqtdU2IPXf6qCBuIJn5qsVNE7sMRVPQqUYGaiqmbbd4eTia3tTpxTEq+YAolieuFInM4teJqpStBPJZ47soiUaM5j98WG7hg1QOgRBRinjpb84NtuSJeDKbnTO3gETThGaMqKDcSRoJ1FhBNmwn+ITcZLg03zKf9FsowHx4NokK5cEHreNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7FA1y6IgdtttWeWFnVFecfhZVcUyFtpwHTO4KSTzOg4=; b=Jxa0HgpVOjj1fmIGyCms3I4aXPvdutKqYbvkdQYVSH3E3cXmGvo58/CWqu9iWUgemdTg9NxRIWwh5TfjGhf3fFOQtfALkPxewh7QH73YzqWxfSAN4bktZB0vAd/jV1eoSENylD1xAPlXH0onzM/NtOq99DSjFWbOTg9VG7sq5evFO5gRna5VnjU0f+QkXirMfJtSmQmqkbX/suzEYyiTdCF3B5uAOuhrHX7zpFTZarpzvORH28uBETqlDd43SFUCwuOrA7IJiyhZtC0aRpaQtvu9c+fX4CF5pgRE/+tNygVk+fELye5tqhKRKpAaVUEejSogehoD5OMnR3OUhSPIcA== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cisco.com;dmarc=pass action=none header.from=cisco.com;dkim=pass header.d=cisco.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7FA1y6IgdtttWeWFnVFecfhZVcUyFtpwHTO4KSTzOg4=; b=MHKGum0YXefHXIPa0w4/gNrUluuelsLIFosGGOKoZ1BC6VucCAzl96NkuhYYlOMI6KM5sTgCbfMXXTneQtWgFXy1uJnskq2DnjGpTblOkSu5imfvcDkBUUL2mw57PFQ8Ns862XwTDYMaaBfqndNdaNEE4x+pyMWDwk94N6qKZ/w= Received: from BYAPR11MB3751.namprd11.prod.outlook.com (20.178.238.144) by BYAPR11MB3015.namprd11.prod.outlook.com (20.177.225.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.14; Fri, 26 Jul 2019 05:38:46 +0000 Received: from BYAPR11MB3751.namprd11.prod.outlook.com ([fe80::a894:a92:ad6e:ee2a]) by BYAPR11MB3751.namprd11.prod.outlook.com ([fe80::a894:a92:ad6e:ee2a%7]) with mapi id 15.20.2115.005; Fri, 26 Jul 2019 05:38:46 +0000 From: "Jakob Heitz (jheitz)" To: Alexander Azimov CC: "sidrops@ietf.org" Thread-Topic: [Sidrops] draft-ietf-sidrops-aspa-verification-01: Handling unknowns Thread-Index: AdVCo7iaisAZRDdHT/a/3q2UygwIOwAgqjYAABL4rDA= Date: Fri, 26 Jul 2019 05:38:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jheitz@cisco.com; x-originating-ip: [2001:420:c0c8:1001::216] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7152e389-ad21-4971-3fa5-08d7118b877f x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB3015; x-ms-traffictypediagnostic: BYAPR11MB3015: x-ms-exchange-purlcount: 8 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 01106E96F6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(366004)(346002)(136003)(396003)(376002)(189003)(199004)(13464003)(66476007)(14454004)(66556008)(33656002)(66446008)(8936002)(64756008)(86362001)(256004)(6916009)(14444005)(6246003)(53936002)(53386004)(236005)(316002)(46003)(7736002)(478600001)(76116006)(66946007)(8676002)(446003)(25786009)(9686003)(5070765005)(76176011)(476003)(11346002)(6436002)(102836004)(6506007)(68736007)(99286004)(966005)(53546011)(71200400001)(606006)(71190400001)(2906002)(66574012)(15650500001)(6306002)(55016002)(52536014)(81156014)(4326008)(54896002)(186003)(486006)(7696005)(81166006)(790700001)(2420400007)(6116002)(229853002)(5660300002)(74316002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3015; H:BYAPR11MB3751.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: FeYfFIiZPwnRtlwouXsh5MHn0vxdyGNZAGQR8FeSlXKPBc7UVXsDAvi5JTdRUWnsys2xO5dVFyQjXoR1viSC1AahHdM800aeYuZ4oE57MlGMDJXwmVJ5pmnJgQ8DWYJdSd9AkXlsGsCr2p3oBH7Zp7brMe5yFWbewb0hKlgSOU4BAV98GhKHL6toPm0rFAS93C6vpmZ2j6yKYRAt+CaFpdZo77rL42H0JOcK9Ltw2PvIxyIgUQoYwcfMcjoY80mIgW7iXUDcvCez3HGY2ckMsQsphuC4AOSWsbbeI0K9VgL6IQrkPdZ34lTReS1X3pwnIRXJxZJpgKgKq7TaQWzEvqbxsMvJS3z6A3uUmtmX14Lyttn4/Fksu+r+DX5wmQqLtyNNlDSJ2eou8f09dTzXLYDiuKgrslU/v0vslRwisPw= Content-Type: multipart/alternative; boundary="_000_BYAPR11MB3751F9334FDC8E598D004388C0C00BYAPR11MB3751namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7152e389-ad21-4971-3fa5-08d7118b877f X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2019 05:38:46.5825 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jheitz@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3015 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.30, xch-rcd-020.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [Sidrops] draft-ietf-sidrops-aspa-verification-01: Handling unknowns X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 05:38:55 -0000 --_000_BYAPR11MB3751F9334FDC8E598D004388C0C00BYAPR11MB3751namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgeW91IHJlY2VpdmUgYW4gQVMtUEFUSCBvZiAyIEFTZXMgYW5kIG5laXRoZXIgb2YgdGhlbSBt YWtlIGFueSBhdHRlc3RhdGlvbiwNCnRoZW4geW91ciBwcm9jZWR1cmUgY2FsbHMgaXQgdmFsaWQu IEl0IGNvdWxkIGJlIGludmFsaWQsDQpzbyBpdCBtdXN0IGJlIGNvbnNpZGVyZWQgdW5rbm93bi4N Cg0KSWYgYW4gQVMtUEFUSCBjb250YWlucyBhbiBBUy1TRVQsIHRoZW4gdGhlIHNlZ21lbnRzIG9u IGVpdGhlciBzaWRlIG9mDQp0aGUgQVMtU0VUIGNhbiBzdGlsbCBiZSB2ZXJpZmllZC4gSWYgYW55 IHN1Y2ggc2VnbWVudCB0dXJucyBvdXQgdG8gYmUNCmludmFsaWQsIHRoZW4gdGhlIHdob2xlIHBh dGggbXVzdCBiZSBjb25zaWRlcmVkIGludmFsaWQsIG5vdCB1bnZlcmlmaWFibGUuDQoNCk15IHBy b2NlZHVyZSBhY2NvdW50cyBmb3IgdGhlc2UgY2FzZXMgYW5kIG1vcmUuDQpGb3IgdGhlIGNhc2Vz IHdoZXJlIGV2ZXJ5IEFTIG1ha2VzIGFuIGF0dGVzdGF0aW9uLCBteSBwcm9jZWR1cmUgYWdyZWVz IHdpdGggeW91cnMuDQoNCkJUVywgeW91IGhhdmUgYSBjb3B5L3Bhc3RlIGVycm9yIGluIDUuMiBE b3duc3RyZWFtIHBhdGhzOg0KSWYgYSByb3V0ZSBmcm9tIFJPVVRFX0FGSSBhZGRyZXNzIGZhbWls eSBpcyByZWNlaXZlZCBmcm9tIGEgY3VzdG9tZXINCnNob3VsZCBiZToNCg0KSWYgYSByb3V0ZSBm cm9tIFJPVVRFX0FGSSBhZGRyZXNzIGZhbWlseSBpcyByZWNlaXZlZCBmcm9tIGEgcHJvdmlkZXIN Cg0Kcy8gb3QgLyBvciAvDQoNCg0KUmVnYXJkcywNCkpha29iLg0KDQpGcm9tOiBBbGV4YW5kZXIg QXppbW92IDxhLmUuYXppbW92QGdtYWlsLmNvbT4NClNlbnQ6IFRodXJzZGF5LCBKdWx5IDI1LCAy MDE5IDE6MjAgUE0NClRvOiBKYWtvYiBIZWl0eiAoamhlaXR6KSA8amhlaXR6QGNpc2NvLmNvbT4N CkNjOiBzaWRyb3BzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1NpZHJvcHNdIGRyYWZ0LWlldGYt c2lkcm9wcy1hc3BhLXZlcmlmaWNhdGlvbi0wMTogSGFuZGxpbmcgdW5rbm93bnMNCg0KSmFrb2Is DQoNCkkgYmVsaWV2ZSB5b3VyIHJlYWRpbmcgb2YgdGhlIEFTUEEgdmVyaWZpY2F0aW9uIHByb2Nl ZHVyZSBpcyBpbmNvcnJlY3QuDQoNClNlY3Rpb24gNCBkZWZpbmVzIHBhaXJzIHdpc2UgdmVyaWZp Y2F0aW9uIHByb2NlZHVyZSAobGV0J3MgY2FsbCBwYWlyX3ZlcmlmaWNhdGlvbikgd2hpY2ggcmV0 dXJucyB2YWxpZCwgaW52YWxpZCBhbmQgdW5rbm93bi4NClNlY3Rpb25zIDUuMSBhbmQgNS4yIGRl ZmluZSB2ZXJpZmljYXRpb24gcHJvY2VkdXJlIGZvciB1cHN0cmVhbSBhbmQgZG93bnN0cmVhbSBw YXRoIHJlc3BlY3RpdmVseS4NCg0KSW4gdGhlc2UgcHJvY2VkdXJlcywgdGhlICd2YWxpZCcgYW5k ICd1bmtub3duJyBvdXRjb21lIG9mIHBhaXJfdmVyaWZpY2F0aW9uIGlzIHRoZSBzYW1lLiBUaGVz ZSBwcm9jZWR1cmVzIHJldHVybiAndmFsaWQnLCAnaW52YWxpZCcgYW5kICd1bnZlcmlmaWFibGUn IChpbiBjYXNlIG9mIHZhbGlkIEFTX1NFUSArIHByZXNlbmNlIG9mIEFTX1NFVCkuIFNvLCB5b3Vy IGFzc3VtcHRpb24gdGhhdCB0aGUgYWxnb3JpdGhtIHdvcmtzIHdoZW4gYWxsIEFTZXMgaW4gdGhl IGFzLXBhdGggbWFrZSBhdHRlc3RhdGlvbnMgaXMgaW5jb3JyZWN0Lg0KDQpUbyBwZXJmb3JtIHZl cmlmaWNhdGlvbiB5b3UgZG9uJ3QgbmVlZCB0byBzcGxpdCBBU1BBVEggaW50byB0cmlwbGV0cyAo b3IgZXZlbiBiaWdnZXIgd2luZG93cykuIEkgc2VudCBwcmV2aW91c2x5IGEgbGluZWFyIGZ1bmN0 aW9uIHRoYXQgbWFrZXMgdmVyaWZpY2F0aW9uIGZvciB0aGUgZG93bnN0cmVhbSBwYXRoLCBmb3Ig dGhlIHVwc3RyZWFtIHBhdGggaXQgZXZlbiBzaW1wbGVyLiBTaW5jZSB5b3UgYXJlIGFscmVhZHkg d29ya2luZyBvbiB0aGUgaW1wbGVtZW50YXRpb24gSSBzdWdnZXN0IHRvIGRpc2N1c3MgaXQgaW4g cGVyc29uIGJlZm9yZSB0aGUgZW5kIG9mIHRoaXMgbWVldGluZy4gSXQgbWFrZXMgbWUgcmVhbGx5 IGFueGlvdXMgaWYgdGhlIHNwZWNpZmljYXRpb24gaXMgdW5jbGVhciBmb3IgaW1wbGVtZW50ZXJz Lg0KDQrRh9GCLCAyNSDQuNGO0LsuIDIwMTkg0LMuINCyIDA4OjA0LCBKYWtvYiBIZWl0eiAoamhl aXR6KSA8amhlaXR6QGNpc2NvLmNvbTxtYWlsdG86amhlaXR6QGNpc2NvLmNvbT4+Og0KSSBiZWxp ZXZlIHRoZSBwYXRoIHZlcmlmaWNhdGlvbiBhbGdvcml0aG0gd29ya3Mgd2hlbiBhbGwgQVNlcyBp biB0aGUgYXMtcGF0aA0KbWFrZSBhdHRlc3RhdGlvbnMuIElmIHNvbWUgb2YgdGhlIEFTZXMgbWFr ZSBubyBhdHRlc3RhdGlvbnMsIHRoZW4gYSBtb3JlIGNvbXBsZXRlDQphbGdvcml0aG0gaXMgYXMg Zm9sbG93czoNCg0KRm9yIGV2ZXJ5IHNlcXVlbmNlIChBLCBCLCBDKSBvZiBjb25zZWN1dGl2ZSBB U2VzIGluIGFuIEFTLXBhdGg6DQpJZiBBIGF0dGVzdHMgdGhhdCBCIGlzIG5vdCBhIHByb3ZpZGVy IGFuZCBDIGF0dGVzdHMgdGhhdCBCIGlzIG5vdCBhIHByb3ZpZGVyLA0KdGhlbiBCIGxlYWtlZCB0 aGUgcm91dGU6IEIgaXMgdHJhbnNpdGluZyBmb3IgZnJlZS4gVGhlIHNlZ21lbnQgaXMgaW52YWxp ZC4NCklmIGVpdGhlciBBIG9yIEMgYXR0ZXN0cyB0aGF0IEIgaXMgYSBwcm92aWRlciwgdGhlbiB0 aGUgQVMtcGF0aCBzZWdtZW50ICAoQSwgQiwgQykgaXMgdmFsaWQuDQpJZiBuZWl0aGVyIEEgbm9y IEMgbWFrZSBhbiBhdHRlc3RhdGlvbiwgdGhlbiB0aGUgbGVhayBzdGF0ZSBpcyB1bmtub3duLiBF dmVuIGlmIEIgbGlzdHMgYm90aCBBIGFuZCBDIGFzIHByb3ZpZGVycywgaXQgaXMgbm90IG5lY2Vz c2FyaWx5IGEgbGVhaywgYmVjYXVzZSBlaXRoZXIgQSBvciBDIGNvdWxkIGNvbnNpZGVyIEIgYXMg YSBwcm92aWRlciBmb3Igc29tZSBvZiB0aGVpciByb3V0ZXMsIGV2ZW4gdGhvdWdoIHRoZXkgZG9u J3QgYXR0ZXN0IHRvIGl0Lg0KDQpJZiBhbGwgdGhlIHBhdGggc2VnbWVudHMgYXJlIHZhbGlkLCB0 aGVuIHRoZSB3aG9sZSBwYXRoIGlzIHZhbGlkLg0KSWYgYW55IG9mIHRoZSBwYXRoIHNlZ21lbnRz IGlzIGludmFsaWQsIHRoZW4gdGhlIHdob2xlIHBhdGggaXMgaW52YWxpZC4NCkVsc2UsIGF0IGxl YXN0IG9uZSBwYXRoIHNlZ21lbnQgaXMgdW5rbm93biBhbmQgb25lIG1vcmUgcnVsZSBtdXN0IGJl IGFwcGxpZWQ6IGZvciBhbnkgc2VxdWVuY2Ugb2YgQVNlcyAoQSwgQjEsIC4uLiwgQm4sIEMpLCBp ZiBBIGF0dGVzdHMgdGhhdCBCMSBpcyBub3QgYSBwcm92aWRlciBhbmQgQyBhdHRlc3RzIHRoYXQg Qm4gaXMgbm90IGEgcHJvdmlkZXIsIHRoZW4gdGhlIEFTLXBhdGggaXMgaW52YWxpZC4gVGhpcyBp cyBmb3IgYW55IG51bWJlciBvZiBCeCBncmVhdGVyIHRoYW4gMS4NCg0KVGhpcyBhbGdvcml0aG0g YnJlYWtzIHRoZSBBUy1QQVRIIGludG8gdHJpcGxlcyBpbnN0ZWFkIG9mIHBhaXJzLg0KRm9yIGV4 YW1wbGUsIHRoZSBBU19QQVRIIChBLEIsQyxELEUpIGlzIGJyb2tlbiBpbnRvIHRoZSB0cmlwbGVz Og0KKEEsQixDKSwgKEIsQyxEKSwgKEMsRCxFKS4NCkkgZmluZCBpdCBlYXNpZXIgdG8gcmVhc29u IGFib3V0IGl0IGxpa2UgdGhhdC4NCkl0IGNhbiBwcm9iYWJseSBiZSByZS13b3JkZWQgaW50byBw YWlycy4NCg0KQW4gYWRkaXRpb25hbCBwb2ludDoNCklmIEFTLVNFVHMgZXhpc3QgdGhlbiBjb21w bGV0ZSBzZXF1ZW5jZXMgYmV0d2VlbiB0aGUgQVMtU0VUcyBjYW4gYmUgY2hlY2tlZCBmb3IgaW52 YWxpZGl0eS4NClRoZSBiZXN0IHN1Y2ggYW4gQVMtUEFUSCBjYW4gZ2V0IGlzIHVua25vd24sIGJ1 dCBpdCBjYW4gYWxzbyBiZSB2ZXJpZmllZCBpbnZhbGlkLg0KDQpSZWdhcmRzLA0KSmFrb2IuDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBTaWRyb3BzIDxzaWRyb3BzLWJvdW5j ZXNAaWV0Zi5vcmc8bWFpbHRvOnNpZHJvcHMtYm91bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBP ZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9y Zz4NClNlbnQ6IE1vbmRheSwgSnVseSA4LCAyMDE5IDE6MjQgUE0NClRvOiBpLWQtYW5ub3VuY2VA aWV0Zi5vcmc8bWFpbHRvOmktZC1hbm5vdW5jZUBpZXRmLm9yZz4NCkNjOiBzaWRyb3BzQGlldGYu b3JnPG1haWx0bzpzaWRyb3BzQGlldGYub3JnPg0KU3ViamVjdDogW1NpZHJvcHNdIEktRCBBY3Rp b246IGRyYWZ0LWlldGYtc2lkcm9wcy1hc3BhLXZlcmlmaWNhdGlvbi0wMS50eHQNCg0KDQpBIE5l dyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1E cmFmdHMgZGlyZWN0b3JpZXMuDQpUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBTSURS IE9wZXJhdGlvbnMgV0cgb2YgdGhlIElFVEYuDQoNCiAgICAgICAgVGl0bGUgICAgICAgICAgIDog VmVyaWZpY2F0aW9uIG9mIEFTX1BBVEggVXNpbmcgdGhlIFJlc291cmNlIENlcnRpZmljYXRlIFB1 YmxpYyBLZXkgSW5mcmFzdHJ1Y3R1cmUgYW5kIEF1dG9ub21vdXMgU3lzdGVtIFByb3ZpZGVyIEF1 dGhvcml6YXRpb24NCiAgICAgICAgQXV0aG9ycyAgICAgICAgIDogQWxleGFuZGVyIEF6aW1vdg0K ICAgICAgICAgICAgICAgICAgICAgICAgICBFdWdlbmUgQm9nb21hem92DQogICAgICAgICAgICAg ICAgICAgICAgICAgIEtleXVyIFBhdGVsDQogICAgICAgICAgICAgICAgICAgICAgICAgIEpvYiBT bmlqZGVycw0KICAgICAgICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLXNpZHJvcHMtYXNw YS12ZXJpZmljYXRpb24tMDEudHh0DQogICAgICAgIFBhZ2VzICAgICAgICAgICA6IDEwDQogICAg ICAgIERhdGUgICAgICAgICAgICA6IDIwMTktMDctMDgNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRv Y3VtZW50IGRlZmluZXMgdGhlIHNlbWFudGljcyBvZiBhbiBBdXRvbm9tb3VzIFN5c3RlbSBQcm92 aWRlcg0KICAgQXV0aG9yaXphdGlvbiBvYmplY3QgaW4gdGhlIFJlc291cmNlIFB1YmxpYyBLZXkg SW5mcmFzdHJ1Y3R1cmUgdG8NCiAgIHZlcmlmeSB0aGUgQVNfUEFUSCBhdHRyaWJ1dGUgb2Ygcm91 dGVzIGFkdmVydGlzZWQgaW4gdGhlIEJvcmRlcg0KICAgR2F0ZXdheSBQcm90b2NvbC4NCg0KDQoN ClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zaWRyb3BzLWFzcGEtdmVy aWZpY2F0aW9uLw0KDQpUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUg YXQ6DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zaWRyb3BzLWFzcGEt dmVyaWZpY2F0aW9uLTAxDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2Ry YWZ0LWlldGYtc2lkcm9wcy1hc3BhLXZlcmlmaWNhdGlvbi0wMQ0KDQpBIGRpZmYgZnJvbSB0aGUg cHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQpodHRwczovL3d3dy5pZXRmLm9yZy9y ZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1zaWRyb3BzLWFzcGEtdmVyaWZpY2F0aW9uLTAxDQoNCg0K UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhl IHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmc+Lg0K DQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6 DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KU2lkcm9wcyBtYWlsaW5nIGxpc3QNClNp ZHJvcHNAaWV0Zi5vcmc8bWFpbHRvOlNpZHJvcHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpZHJvcHMNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NClNpZHJvcHMgbWFpbGluZyBsaXN0DQpTaWRyb3BzQGll dGYub3JnPG1haWx0bzpTaWRyb3BzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zaWRyb3BzDQoNCg0KLS0NCkJlc3QgcmVnYXJkcywNCkFsZXhhbmRlciBB emltb3YNCg== --_000_BYAPR11MB3751F9334FDC8E598D004388C0C00BYAPR11MB3751namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K cC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUt bmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0 OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpz cGFuLmdtYWlsLWdyDQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLWdyXzt9DQpzcGFuLkVtYWlsU3R5 bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciOw0KCWNvbG9yOiM3MDMwQTA7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0K CXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiM3MDMwQTAiPklmIHlvdSByZWNlaXZlIGFuIEFTLVBBVEggb2YgMiBBU2VzIGFuZCBu ZWl0aGVyIG9mIHRoZW0gbWFrZSBhbnkgYXR0ZXN0YXRpb24sPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBBMCI+dGhlbiB5b3Vy IHByb2NlZHVyZSBjYWxscyBpdCB2YWxpZC4gSXQgY291bGQgYmUgaW52YWxpZCw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNzAzMEEw Ij5zbyBpdCBtdXN0IGJlIGNvbnNpZGVyZWQgdW5rbm93bi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNzAzMEEwIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjoj NzAzMEEwIj5JZiBhbiBBUy1QQVRIIGNvbnRhaW5zIGFuIEFTLVNFVCwgdGhlbiB0aGUgc2VnbWVu dHMgb24gZWl0aGVyIHNpZGUgb2Y8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNzAzMEEwIj50aGUgQVMtU0VUIGNhbiBzdGlsbCBiZSB2 ZXJpZmllZC4gSWYgYW55IHN1Y2ggc2VnbWVudCB0dXJucyBvdXQgdG8gYmU8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNzAzMEEwIj5p bnZhbGlkLCB0aGVuIHRoZSB3aG9sZSBwYXRoIG11c3QgYmUgY29uc2lkZXJlZCBpbnZhbGlkLCBu b3QgdW52ZXJpZmlhYmxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOiM3MDMwQTAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM3MDMwQTAiPk15IHByb2NlZHVy ZSBhY2NvdW50cyBmb3IgdGhlc2UgY2FzZXMgYW5kIG1vcmUuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBBMCI+Rm9yIHRoZSBj YXNlcyB3aGVyZSBldmVyeSBBUyBtYWtlcyBhbiBhdHRlc3RhdGlvbiwgbXkgcHJvY2VkdXJlIGFn cmVlcyB3aXRoIHlvdXJzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOiM3MDMwQTAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM3MDMwQTAiPkJUVywgeW91IGhh dmUgYSBjb3B5L3Bhc3RlIGVycm9yIGluIDUuMiBEb3duc3RyZWFtIHBhdGhzOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5J ZiBhIHJvdXRlIGZyb20gUk9VVEVfQUZJIGFkZHJlc3MgZmFtaWx5IGlzIHJlY2VpdmVkIGZyb20g YSBjdXN0b21lcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOiM3MDMwQTAiPnNob3VsZCBiZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SWYgYSByb3V0ZSBmcm9tIFJPVVRFX0FGSSBh ZGRyZXNzIGZhbWlseSBpcyByZWNlaXZlZCBmcm9tIGEgcHJvdmlkZXI8bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM3MDMwQTAiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiM3MDMwQTAiPnMvIG90IC8gb3IgLzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM3MDMwQTAiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM3MDMwQTAi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOiM3MDMwQTAiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBBMCI+SmFrb2IuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBBMCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJv bTo8L2I+IEFsZXhhbmRlciBBemltb3YgJmx0O2EuZS5hemltb3ZAZ21haWwuY29tJmd0OyA8YnI+ DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEp1bHkgMjUsIDIwMTkgMToyMCBQTTxicj4NCjxiPlRv OjwvYj4gSmFrb2IgSGVpdHogKGpoZWl0eikgJmx0O2poZWl0ekBjaXNjby5jb20mZ3Q7PGJyPg0K PGI+Q2M6PC9iPiBzaWRyb3BzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbU2lk cm9wc10gZHJhZnQtaWV0Zi1zaWRyb3BzLWFzcGEtdmVyaWZpY2F0aW9uLTAxOiBIYW5kbGluZyB1 bmtub3duczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpha29iLDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGJlbGll dmUgeW91ciByZWFkaW5nIG9mIHRoZSBBU1BBIHZlcmlmaWNhdGlvbiBwcm9jZWR1cmUgaXMgaW5j b3JyZWN0Lg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlNlY3Rpb24gNCBkZWZpbmVzIHBhaXJzIHdpc2UgdmVyaWZpY2F0aW9uIHByb2NlZHVy ZSAobGV0J3MgY2FsbCBwYWlyX3ZlcmlmaWNhdGlvbikgd2hpY2ggcmV0dXJucyB2YWxpZCwgaW52 YWxpZCBhbmQgdW5rbm93bi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlNlY3Rpb25zIDUuMSBhbmQgNS4yIGRlZmluZSB2ZXJpZmljYXRpb24gcHJv Y2VkdXJlIGZvciB1cHN0cmVhbSBhbmQgZG93bnN0cmVhbSBwYXRoIHJlc3BlY3RpdmVseS4NCjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiB0 aGVzZSBwcm9jZWR1cmVzLCB0aGUgJ3ZhbGlkJyBhbmQgJ3Vua25vd24nIG91dGNvbWUgb2YgcGFp cl92ZXJpZmljYXRpb24gaXMgdGhlIHNhbWUuIFRoZXNlIHByb2NlZHVyZXMgcmV0dXJuICd2YWxp ZCcsICdpbnZhbGlkJyBhbmQgJ3VudmVyaWZpYWJsZScgKGluIGNhc2Ugb2YgdmFsaWQgQVNfU0VR ICYjNDM7IHByZXNlbmNlIG9mIEFTX1NFVCkuIFNvLCB5b3VyIGFzc3VtcHRpb24gdGhhdCB0aGUg YWxnb3JpdGhtDQogd29ya3Mgd2hlbiBhbGwgQVNlcyBpbiB0aGUgYXMtcGF0aCBtYWtlIGF0dGVz dGF0aW9ucyBpcyBpbmNvcnJlY3QuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRvIHBlcmZvcm0gdmVyaWZpY2F0aW9uJm5ic3A7eW91IGRvbid0 IG5lZWQgdG8gc3BsaXQgPHNwYW4gY2xhc3M9ImdtYWlsLWdyIj4NCkFTUEFUSDwvc3Bhbj4gaW50 byB0cmlwbGV0cyAob3IgZXZlbiBiaWdnZXIgd2luZG93cykuIEkgc2VudCBwcmV2aW91c2x5IGEg bGluZWFyIGZ1bmN0aW9uIHRoYXQgbWFrZXMgdmVyaWZpY2F0aW9uIGZvciB0aGUgZG93bnN0cmVh bSBwYXRoLCBmb3IgdGhlIHVwc3RyZWFtIHBhdGggaXQgZXZlbiBzaW1wbGVyLiBTaW5jZSB5b3Ug YXJlIGFscmVhZHkgd29ya2luZyBvbiB0aGUgaW1wbGVtZW50YXRpb24gSSBzdWdnZXN0IHRvIGRp c2N1c3MgaXQgaW4NCiBwZXJzb24gYmVmb3JlIHRoZSBlbmQgb2YgdGhpcyBtZWV0aW5nLiBJdCBt YWtlcyBtZSByZWFsbHkgYW54aW91cyBpZiB0aGUgc3BlY2lmaWNhdGlvbiBpcyB1bmNsZWFyIGZv ciBpbXBsZW1lbnRlcnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPtGH0YIsIDI1INC40Y7Quy4gMjAxOSDQsy4g0LIgMDg6MDQsIEpha29iIEhl aXR6IChqaGVpdHopICZsdDs8YSBocmVmPSJtYWlsdG86amhlaXR6QGNpc2NvLmNvbSI+amhlaXR6 QGNpc2NvLmNvbTwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBiZWxpZXZlIHRoZSBwYXRoIHZlcmlmaWNhdGlvbiBhbGdv cml0aG0gd29ya3Mgd2hlbiBhbGwgQVNlcyBpbiB0aGUgYXMtcGF0aDxicj4NCm1ha2UgYXR0ZXN0 YXRpb25zLiBJZiBzb21lIG9mIHRoZSBBU2VzIG1ha2Ugbm8gYXR0ZXN0YXRpb25zLCB0aGVuIGEg bW9yZSBjb21wbGV0ZTxicj4NCmFsZ29yaXRobSBpcyBhcyBmb2xsb3dzOjxicj4NCjxicj4NCkZv ciBldmVyeSBzZXF1ZW5jZSAoQSwgQiwgQykgb2YgY29uc2VjdXRpdmUgQVNlcyBpbiBhbiBBUy1w YXRoOjxicj4NCklmIEEgYXR0ZXN0cyB0aGF0IEIgaXMgbm90IGEgcHJvdmlkZXIgYW5kIEMgYXR0 ZXN0cyB0aGF0IEIgaXMgbm90IGEgcHJvdmlkZXIsPGJyPg0KdGhlbiBCIGxlYWtlZCB0aGUgcm91 dGU6IEIgaXMgdHJhbnNpdGluZyBmb3IgZnJlZS4gVGhlIHNlZ21lbnQgaXMgaW52YWxpZC48YnI+ DQpJZiBlaXRoZXIgQSBvciBDIGF0dGVzdHMgdGhhdCBCIGlzIGEgcHJvdmlkZXIsIHRoZW4gdGhl IEFTLXBhdGggc2VnbWVudCZuYnNwOyAoQSwgQiwgQykgaXMgdmFsaWQuPGJyPg0KSWYgbmVpdGhl ciBBIG5vciBDIG1ha2UgYW4gYXR0ZXN0YXRpb24sIHRoZW4gdGhlIGxlYWsgc3RhdGUgaXMgdW5r bm93bi4gRXZlbiBpZiBCIGxpc3RzIGJvdGggQSBhbmQgQyBhcyBwcm92aWRlcnMsIGl0IGlzIG5v dCBuZWNlc3NhcmlseSBhIGxlYWssIGJlY2F1c2UgZWl0aGVyIEEgb3IgQyBjb3VsZCBjb25zaWRl ciBCIGFzIGEgcHJvdmlkZXIgZm9yIHNvbWUgb2YgdGhlaXIgcm91dGVzLCBldmVuIHRob3VnaCB0 aGV5IGRvbid0IGF0dGVzdCB0bw0KIGl0Ljxicj4NCjxicj4NCklmIGFsbCB0aGUgcGF0aCBzZWdt ZW50cyBhcmUgdmFsaWQsIHRoZW4gdGhlIHdob2xlIHBhdGggaXMgdmFsaWQuPGJyPg0KSWYgYW55 IG9mIHRoZSBwYXRoIHNlZ21lbnRzIGlzIGludmFsaWQsIHRoZW4gdGhlIHdob2xlIHBhdGggaXMg aW52YWxpZC48YnI+DQpFbHNlLCBhdCBsZWFzdCBvbmUgcGF0aCBzZWdtZW50IGlzIHVua25vd24g YW5kIG9uZSBtb3JlIHJ1bGUgbXVzdCBiZSBhcHBsaWVkOiBmb3IgYW55IHNlcXVlbmNlIG9mIEFT ZXMgKEEsIEIxLCAuLi4sIEJuLCBDKSwgaWYgQSBhdHRlc3RzIHRoYXQgQjEgaXMgbm90IGEgcHJv dmlkZXIgYW5kIEMgYXR0ZXN0cyB0aGF0IEJuIGlzIG5vdCBhIHByb3ZpZGVyLCB0aGVuIHRoZSBB Uy1wYXRoIGlzIGludmFsaWQuIFRoaXMgaXMgZm9yIGFueSBudW1iZXIgb2YNCiBCeCBncmVhdGVy IHRoYW4gMS48YnI+DQo8YnI+DQpUaGlzIGFsZ29yaXRobSBicmVha3MgdGhlIEFTLVBBVEggaW50 byB0cmlwbGVzIGluc3RlYWQgb2YgcGFpcnMuPGJyPg0KRm9yIGV4YW1wbGUsIHRoZSBBU19QQVRI IChBLEIsQyxELEUpIGlzIGJyb2tlbiBpbnRvIHRoZSB0cmlwbGVzOjxicj4NCihBLEIsQyksIChC LEMsRCksIChDLEQsRSkuPGJyPg0KSSBmaW5kIGl0IGVhc2llciB0byByZWFzb24gYWJvdXQgaXQg bGlrZSB0aGF0Ljxicj4NCkl0IGNhbiBwcm9iYWJseSBiZSByZS13b3JkZWQgaW50byBwYWlycy48 YnI+DQo8YnI+DQpBbiBhZGRpdGlvbmFsIHBvaW50Ojxicj4NCklmIEFTLVNFVHMgZXhpc3QgdGhl biBjb21wbGV0ZSBzZXF1ZW5jZXMgYmV0d2VlbiB0aGUgQVMtU0VUcyBjYW4gYmUgY2hlY2tlZCBm b3IgaW52YWxpZGl0eS48YnI+DQpUaGUgYmVzdCBzdWNoIGFuIEFTLVBBVEggY2FuIGdldCBpcyB1 bmtub3duLCBidXQgaXQgY2FuIGFsc28gYmUgdmVyaWZpZWQgaW52YWxpZC48YnI+DQo8YnI+DQpS ZWdhcmRzLDxicj4NCkpha29iLjxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t PGJyPg0KRnJvbTogU2lkcm9wcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNpZHJvcHMtYm91bmNlc0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNpZHJvcHMtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7 IE9uIEJlaGFsZiBPZg0KPGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT48YnI+DQpTZW50OiBN b25kYXksIEp1bHkgOCwgMjAxOSAxOjI0IFBNPGJyPg0KVG86IDxhIGhyZWY9Im1haWx0bzppLWQt YW5ub3VuY2VAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pLWQtYW5ub3VuY2VAaWV0Zi5vcmc8 L2E+PGJyPg0KQ2M6IDxhIGhyZWY9Im1haWx0bzpzaWRyb3BzQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+c2lkcm9wc0BpZXRmLm9yZzwvYT48YnI+DQpTdWJqZWN0OiBbU2lkcm9wc10gSS1EIEFj dGlvbjogZHJhZnQtaWV0Zi1zaWRyb3BzLWFzcGEtdmVyaWZpY2F0aW9uLTAxLnR4dDxicj4NCjxi cj4NCjxicj4NCkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1s aW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy48YnI+DQpUaGlzIGRyYWZ0IGlzIGEgd29y ayBpdGVtIG9mIHRoZSBTSURSIE9wZXJhdGlvbnMgV0cgb2YgdGhlIElFVEYuPGJyPg0KPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRpdGxlJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDs6IFZlcmlmaWNhdGlvbiBvZiBBU19QQVRIIFVzaW5nIHRoZSBSZXNv dXJjZSBDZXJ0aWZpY2F0ZSBQdWJsaWMgS2V5IEluZnJhc3RydWN0dXJlIGFuZCBBdXRvbm9tb3Vz IFN5c3RlbSBQcm92aWRlciBBdXRob3JpemF0aW9uPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IEF1dGhvcnMmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBBbGV4YW5k ZXIgQXppbW92PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEV1Z2VuZSBC b2dvbWF6b3Y8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgS2V5dXIgUGF0 ZWw8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSm9iIFNuaWpkZXJzPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEZpbGVuYW1lJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IDogZHJhZnQtaWV0Zi1zaWRyb3BzLWFzcGEtdmVyaWZpY2F0aW9uLTAxLnR4dDxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBQYWdlcyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiAxMDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBEYXRlJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiAyMDE5LTA3 LTA4PGJyPg0KPGJyPg0KQWJzdHJhY3Q6PGJyPg0KJm5ic3A7ICZuYnNwO1RoaXMgZG9jdW1lbnQg ZGVmaW5lcyB0aGUgc2VtYW50aWNzIG9mIGFuIEF1dG9ub21vdXMgU3lzdGVtIFByb3ZpZGVyPGJy Pg0KJm5ic3A7ICZuYnNwO0F1dGhvcml6YXRpb24gb2JqZWN0IGluIHRoZSBSZXNvdXJjZSBQdWJs aWMgS2V5IEluZnJhc3RydWN0dXJlIHRvPGJyPg0KJm5ic3A7ICZuYnNwO3ZlcmlmeSB0aGUgQVNf UEFUSCBhdHRyaWJ1dGUgb2Ygcm91dGVzIGFkdmVydGlzZWQgaW4gdGhlIEJvcmRlcjxicj4NCiZu YnNwOyAmbmJzcDtHYXRld2F5IFByb3RvY29sLjxicj4NCjxicj4NCjxicj4NCjxicj4NClRoZSBJ RVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOjxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2lkcm9wcy1h c3BhLXZlcmlmaWNhdGlvbi8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLXNpZHJvcHMtYXNwYS12ZXJpZmljYXRpb24vPC9hPjxicj4N Cjxicj4NClRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDo8YnI+ DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zaWRyb3Bz LWFzcGEtdmVyaWZpY2F0aW9uLTAxIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtc2lkcm9wcy1hc3BhLXZlcmlmaWNhdGlvbi0wMTwvYT48YnI+ DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWll dGYtc2lkcm9wcy1hc3BhLXZlcmlmaWNhdGlvbi0wMSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1zaWRyb3BzLWFzcGEtdmVy aWZpY2F0aW9uLTAxPC9hPjxicj4NCjxicj4NCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJz aW9uIGlzIGF2YWlsYWJsZSBhdDo8YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9y ZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1zaWRyb3BzLWFzcGEtdmVyaWZpY2F0aW9uLTAxIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYt c2lkcm9wcy1hc3BhLXZlcmlmaWNhdGlvbi0wMTwvYT48YnI+DQo8YnI+DQo8YnI+DQpQbGVhc2Ug bm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBv ZiBzdWJtaXNzaW9uPGJyPg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJl IGF2YWlsYWJsZSBhdCA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj4NCnRvb2xzLmlldGYub3JnPC9hPi48YnI+DQo8YnI+DQpJbnRlcm5ldC1EcmFmdHMgYXJl IGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6PGJyPg0KPGEgaHJlZj0iZnRwOi8v ZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8iIHRhcmdldD0iX2JsYW5rIj5mdHA6Ly9mdHAu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLzwvYT48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClNpZHJvcHMgbWFpbGluZyBsaXN0 PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlNpZHJvcHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5T aWRyb3BzQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2lkcm9wcyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2lkcm9wczwvYT48YnI+DQo8YnI+DQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClNpZHJvcHMgbWFpbGluZyBs aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlNpZHJvcHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5TaWRyb3BzQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2lkcm9wcyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lkcm9wczwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyIGNsZWFyPSJhbGwiPg0K PGJyPg0KLS0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5BbGV4YW5kZXIgQXppbW92PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BYAPR11MB3751F9334FDC8E598D004388C0C00BYAPR11MB3751namp_-- From nobody Thu Jul 25 22:39:14 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AABAE1202A7; Thu, 25 Jul 2019 22:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=LtvJVTUq; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=RCqeAsos 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 MM_QX9Xs0paS; Thu, 25 Jul 2019 22:39:12 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 346061202A5; Thu, 25 Jul 2019 22:39:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=592; q=dns/txt; s=iport; t=1564119552; x=1565329152; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=wsloEWods3/IHScfp5GKm8jGLqg65Km9pgm0K4hntVY=; b=LtvJVTUqdt5pXg2/XvAhMnvtq279oWvzgrtijsJdBSwcj0uHErVbgBra foEB3W2Z+8ow+us9gmm1OHC7Ww+fJB0BQUpZvyBKPEo/ciCQRlnzXifCD Xc8zAasYgReC3/Gd7misxGXwbnS+ElvLVKQhieox+/DOlH1WHrrVKqY7e k=; IronPort-PHdr: =?us-ascii?q?9a23=3A68kMQxfFMhNt5kw5p860ok6vlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwKYD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/bSw3HdhQfFRk5Hq8d0NSHZW2ag=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B3AABwkTpd/4kNJK1mHAEBAQQBAQc?= =?us-ascii?q?EAQGBVAYBAQsBgUNQA4FCIAQLKodlA40ATJligS6BJANUCQEBAQwBAS0CAQG?= =?us-ascii?q?EQAKCXyM1CA4BAwEBBAEBAgEGbYUeDIVjKAYBATAIEQE+QiYBBAEaGoRrAx0?= =?us-ascii?q?BAqFvAoE4iGCCI4J6AQEFhQcYghMJgTQBi14XgUA/gVeDCoQuGIM7giaqeAk?= =?us-ascii?q?CghqUK4IdlW+KPIJ+l1UCBAIEBQIOAQEFgVEBNoFYcBWDJ4JCg3GKU3KBKY1?= =?us-ascii?q?fAQE?= X-IronPort-AV: E=Sophos;i="5.64,309,1559520000"; d="scan'208";a="300816015" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Jul 2019 05:39:11 +0000 Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x6Q5dBhW028167 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 26 Jul 2019 05:39:11 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 26 Jul 2019 00:39:10 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 26 Jul 2019 00:39:08 -0500 Received: from NAM05-BY2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 26 Jul 2019 00:39:08 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CimCVeXO4X1fl8+LYdM6viMGFfztm29rDg9nD/5UBSML9mvXag0XwbeXCPibVQa8EB3isdUo+rLzf07g1fZw9FQiOQZEnWVD0n7qi8LKEBv2n5qluTHPEB2qjU8KCBX1fEMu7hSgqxEs/o8DM9qUpNFBDbYqaaHGudBgDVoQuYzh17s2fjh3Ig5MmxVwrmDHbJAsl0gvB6uAyy5Nuy2RHB58OFOaVgpPMO/tbkx0kxTUV5DBJ7nG5msx9/X++iNR+JUyaN6NXAj/JjXvCsKpDtaNdEsPZBvQctTWz/Ow8+bK8hK2DMyRCovbst1nyvkUMJgLu7dSquUszM4/ac/Ysw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wsloEWods3/IHScfp5GKm8jGLqg65Km9pgm0K4hntVY=; b=nBxxLK4m+83MaDLaLVPO7QAGvnZlmMSsx5mFsQN08q7lO6sw+akZo+OTTNIINi7FYbx53YfJQG2PienzfpAn/VFZzJVnp4U8lLaFSC/ZzJ3tH3X7Em1HQxQhFw7LSJKkulac+jcw4vTdArt6425RmCMNhKFsm9B0Oqy0/7c3kBu8sxjI5NbE1mRZ7iIP8cXQhK1ElXEbhY/l3u2Xxl197Ybje5BcPj8r3fpFWM5HZqRWemELXEQJOIknPlhbZJ+dDMDrN3TsuozzJwoNzC3b1Xd4tXwtI5YAl5vK9od5lQdeUeM5iwQDbPnmmpNWq4sIup+YVaT2YkLygthe9MLWEQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cisco.com;dmarc=pass action=none header.from=cisco.com;dkim=pass header.d=cisco.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wsloEWods3/IHScfp5GKm8jGLqg65Km9pgm0K4hntVY=; b=RCqeAsosVYuHMd+CV43Vc/R2UdoIaIoxMT/ctJg6H5YscdG8DfOM37he5T9Bls/1obRGen2Va7Dx5qWEe4/kl+63jqv1K1twC0KdYBX6qyGVRmx9CS+y62MA9rv5ZKE5q6jHCVaoIC/WCVcOiq3d8WGNOzyYhIi+VuydzfhRAbc= Received: from BYAPR11MB3751.namprd11.prod.outlook.com (20.178.238.144) by BYAPR11MB3015.namprd11.prod.outlook.com (20.177.225.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.14; Fri, 26 Jul 2019 05:39:07 +0000 Received: from BYAPR11MB3751.namprd11.prod.outlook.com ([fe80::a894:a92:ad6e:ee2a]) by BYAPR11MB3751.namprd11.prod.outlook.com ([fe80::a894:a92:ad6e:ee2a%7]) with mapi id 15.20.2115.005; Fri, 26 Jul 2019 05:39:07 +0000 From: "Jakob Heitz (jheitz)" To: "sidrops@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: draft-ietf-sidrops-aspa-verification-01: Route Servers Thread-Index: AdVCqC+91zXm1fkvQN2jx6O7Fwx9/g== Date: Fri, 26 Jul 2019 05:39:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jheitz@cisco.com; x-originating-ip: [2001:420:c0c8:1001::216] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4f962624-b893-4b4e-59a1-08d7118b93ae x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB3015; x-ms-traffictypediagnostic: BYAPR11MB3015: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 01106E96F6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(366004)(346002)(136003)(396003)(376002)(189003)(199004)(66476007)(14454004)(66556008)(33656002)(66446008)(8936002)(64756008)(86362001)(256004)(53936002)(316002)(46003)(7736002)(478600001)(76116006)(66946007)(8676002)(25786009)(9686003)(110136005)(476003)(6436002)(305945005)(102836004)(6506007)(68736007)(99286004)(4744005)(2501003)(71200400001)(71190400001)(2906002)(55016002)(52536014)(81156014)(450100002)(186003)(486006)(7696005)(81166006)(6116002)(5660300002)(74316002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3015; H:BYAPR11MB3751.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: goDkFXGwkTnIKkCJsFRL4W9ftanhS8uScjGOMfpZztJx3Oluvf1vnjjEMRz6SmXQCnUswdsiiPLKqiTKi7PpDcO9TNcGka71R5oxPFHQO1MbZcHB1Awiid6TVb464hyumdfICYcTTjUBJkrlSdPEXa9slphf4EkCtIiK3BpAXefhxp9WibD8t9wuFCD8SgLihu582COKsts8NVScghuPWRR6sXRUWrKiDcYiHVWHfYHqk4/56pxFfUy4LKAPazb60lMYXsW9NNKqDUl77vxfUsT51kWonn6s1RgIQBLrWFFWVWuZnbQk07OioiKxXrNrJZT7kE3KduvED2+kHkeFrAvBpFsZzJJ+yq0lW3txzSHOWo1ijOa9BrLoihKIiK1uFyvKVojbe8o7YLs8IISgZeQYXf/b7gVK4ugtZSieNho= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4f962624-b893-4b4e-59a1-08d7118b93ae X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2019 05:39:07.1138 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jheitz@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3015 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.26, xch-aln-016.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: [Sidrops] draft-ietf-sidrops-aspa-verification-01: Route Servers X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 05:39:14 -0000 Route servers do not add their AS to the AS-path. Wouldn't it be easier to just ignore them? Treat them as the cable between the BGP speakers. It's the RS clients that have relationships with each other. Nobody has a relationship with a cable. This allows providers, customers and customer's customers to all exist on the same route server and have proper relationships with ea= ch other. Suppose AS-1 is Tier 1; AS-2 is Tier-2 and AS-3 is a customer of both AS-1 = and AS-2. AS-2 is also a customer of AS-1. They can all connect to the same route server. Regards, Jakob. From nobody Fri Jul 26 08:48:24 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 429EA120044 for ; Fri, 26 Jul 2019 08:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 T481vsC4hkOJ for ; Fri, 26 Jul 2019 08:48:19 -0700 (PDT) Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (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 D630212003E for ; Fri, 26 Jul 2019 08:48:18 -0700 (PDT) Received: by mail-ot1-x335.google.com with SMTP id r21so49758033otq.6 for ; Fri, 26 Jul 2019 08:48:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GYXD1quAR8wHu4FYkywkiNY7QZuL8BDV1HI5xb5zP2M=; b=M+ls0LXKd8tXe5O6u1A9nGkGNThlk/zVKUoox3Wg16DqBg0bnX7TAASwYiiasK5lT3 mDJUXhYgwk3yfozgFtVEh/qNTyWDANHviRXqdCht4QkZMIndayFj1J7XHzdWAryQDC9m VO5q9TPnymIiKGFSBlK7ZqVeTrUMGGAWlU53PSdU+1L3eYEPWSfp0BRc0TR+KqXbkrW+ sIMgG4Kt6ykoUdPktwlBtikjTmwePK7T7BG7YmWVYFOAZWT5XrscvIsroi7EAU2EJMpD 00YZQpbjzUpO3qxh5MGTsewrAMD4RU0F2p4DxPx8eNSDkAukwUE1pK70m4mZ2LsfmK/7 wJ0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GYXD1quAR8wHu4FYkywkiNY7QZuL8BDV1HI5xb5zP2M=; b=K7lrIAp9crzCGJ3rUNWm8E9NoI6Q9JFbBrrFj+r20MnB8IRAVBuapq19PHFhEJjxiz 8c1/qU4D2He+DjD4BqM/fNgZ+D/XABXcH0IU3KlH5QKXA3D9c7cI5jzZ967Y2tz+7O2e Q9KTbS8zIVPMdeJFhdhuklbqg4EMRj+8ezOOp21iBzTSc5tQNAoa+S5NWwnRPuzlKA9s mtcnVE7AdWtubOClp8/QhHdKeKVZUedxDVVy6hmF69BbDgDn2mrFD4jTIqzJ6AjaqDlA YXPruwUJLa7Y0mq9q27UZzvk4GJ/5vyiVV5tyRzrT5QX2vFq8vGcNdF3eVgDecKX0OCG yNSA== X-Gm-Message-State: APjAAAWXzCpQ/oTTOHMj1EzM83+HVvlPNmIVgtn2pxRQL9aHqbvjTcrk wjPu07+SPyxzUUX6/5MowGehJ+F9eBb4owDTYi3lpABj X-Google-Smtp-Source: APXvYqyE9WbdAOIcO3PNnZWS9t7msc/aZPo+9ZbXejCq8IAN94pSjdVN8qsNKXijQYvJkk/2JoQpq5ANgSNDWv5M89E= X-Received: by 2002:a9d:7411:: with SMTP id n17mr65421174otk.27.1564156098094; Fri, 26 Jul 2019 08:48:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alexander Azimov Date: Fri, 26 Jul 2019 18:48:07 +0300 Message-ID: To: "Jakob Heitz (jheitz)" Cc: "sidrops@ietf.org" Content-Type: multipart/alternative; boundary="00000000000099abd1058e9778a3" Archived-At: Subject: Re: [Sidrops] draft-ietf-sidrops-aspa-verification-01: Handling unknowns X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 15:48:22 -0000 --00000000000099abd1058e9778a3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In this email, I will answer Jacob's comments + make a brief follow up of our f2f discussion. =D0=BF=D1=82, 26 =D0=B8=D1=8E=D0=BB. 2019 =D0=B3. =D0=B2 08:38, Jakob Heitz= (jheitz) : > If you receive an AS-PATH of 2 ASes and neither of them make any > attestation, > > then your procedure calls it valid. It could be invalid, > > so it must be considered unknown. > It is an interesting point. When I was writing verification > > > If an AS-PATH contains an AS-SET, then the segments on either side of > > the AS-SET can still be verified. If any such segment turns out to be > > invalid, then the whole path must be considered invalid, not unverifiable= . > > > > My procedure accounts for these cases and more. > > For the cases where every AS makes an attestation, my procedure agrees > with yours. > > > > BTW, you have a copy/paste error in 5.2 Downstream paths: > > If a route from ROUTE_AFI address family is received from a customer > > should be: > > If a route from ROUTE_AFI address family is received from a provider > > > > s/ ot / or / > > > > > > Regards, > > Jakob. > > > > *From:* Alexander Azimov > *Sent:* Thursday, July 25, 2019 1:20 PM > *To:* Jakob Heitz (jheitz) > *Cc:* sidrops@ietf.org > *Subject:* Re: [Sidrops] draft-ietf-sidrops-aspa-verification-01: > Handling unknowns > > > > Jakob, > > > > I believe your reading of the ASPA verification procedure is incorrect. > > > > Section 4 defines pairs wise verification procedure (let's call > pair_verification) which returns valid, invalid and unknown. > > Sections 5.1 and 5.2 define verification procedure for upstream and > downstream path respectively. > > > > In these procedures, the 'valid' and 'unknown' outcome of > pair_verification is the same. These procedures return 'valid', 'invalid' > and 'unverifiable' (in case of valid AS_SEQ + presence of AS_SET). So, yo= ur > assumption that the algorithm works when all ASes in the as-path make > attestations is incorrect. > > > > To perform verification you don't need to split ASPATH into triplets (or > even bigger windows). I sent previously a linear function that makes > verification for the downstream path, for the upstream path it even > simpler. Since you are already working on the implementation I suggest to > discuss it in person before the end of this meeting. It makes me really > anxious if the specification is unclear for implementers. > > > > =D1=87=D1=82, 25 =D0=B8=D1=8E=D0=BB. 2019 =D0=B3. =D0=B2 08:04, Jakob Hei= tz (jheitz) : > > I believe the path verification algorithm works when all ASes in the > as-path > make attestations. If some of the ASes make no attestations, then a more > complete > algorithm is as follows: > > For every sequence (A, B, C) of consecutive ASes in an AS-path: > If A attests that B is not a provider and C attests that B is not a > provider, > then B leaked the route: B is transiting for free. The segment is invalid= . > If either A or C attests that B is a provider, then the AS-path segment > (A, B, C) is valid. > If neither A nor C make an attestation, then the leak state is unknown. > Even if B lists both A and C as providers, it is not necessarily a leak, > because either A or C could consider B as a provider for some of their > routes, even though they don't attest to it. > > If all the path segments are valid, then the whole path is valid. > If any of the path segments is invalid, then the whole path is invalid. > Else, at least one path segment is unknown and one more rule must be > applied: for any sequence of ASes (A, B1, ..., Bn, C), if A attests that = B1 > is not a provider and C attests that Bn is not a provider, then the AS-pa= th > is invalid. This is for any number of Bx greater than 1. > > This algorithm breaks the AS-PATH into triples instead of pairs. > For example, the AS_PATH (A,B,C,D,E) is broken into the triples: > (A,B,C), (B,C,D), (C,D,E). > I find it easier to reason about it like that. > It can probably be re-worded into pairs. > > An additional point: > If AS-SETs exist then complete sequences between the AS-SETs can be > checked for invalidity. > The best such an AS-PATH can get is unknown, but it can also be verified > invalid. > > Regards, > Jakob. > > -----Original Message----- > From: Sidrops On Behalf Of > internet-drafts@ietf.org > Sent: Monday, July 8, 2019 1:24 PM > To: i-d-announce@ietf.org > Cc: sidrops@ietf.org > Subject: [Sidrops] I-D Action: draft-ietf-sidrops-aspa-verification-01.tx= t > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the SIDR Operations WG of the IETF. > > Title : Verification of AS_PATH Using the Resource > Certificate Public Key Infrastructure and Autonomous System Provider > Authorization > Authors : Alexander Azimov > Eugene Bogomazov > Keyur Patel > Job Snijders > Filename : draft-ietf-sidrops-aspa-verification-01.txt > Pages : 10 > Date : 2019-07-08 > > Abstract: > This document defines the semantics of an Autonomous System Provider > Authorization object in the Resource Public Key Infrastructure to > verify the AS_PATH attribute of routes advertised in the Border > Gateway Protocol. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-verification/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-sidrops-aspa-verification-01 > > https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-verificatio= n-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidrops-aspa-verification-= 01 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > > > > -- > > Best regards, > > Alexander Azimov > --=20 Best regards, Alexander Azimov --00000000000099abd1058e9778a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In this email, I will answer Jacob's comments + m= ake a brief follow up of our f2f discussion.

<= div class=3D"gmail_quote">
=D0=BF=D1= =82, 26 =D0=B8=D1=8E=D0=BB. 2019 =D0=B3. =D0=B2 08:38, Jakob Heitz (jheitz)= <jheitz@cisco.com>:

If you receive an AS-PATH of 2 ASes an= d neither of them make any attestation,

then your procedure calls it valid. It= could be invalid,

so it must be considered unknown.

It is an interesting point. When I was = writing verification
=C2=A0

=C2=A0

If an AS-PATH contains an AS-SET, then= the segments on either side of

the AS-SET can still be verified. If a= ny such segment turns out to be

invalid, then the whole path must be c= onsidered invalid, not unverifiable.

=C2=A0

My procedure accounts for these cases = and more.

For the cases where every AS makes an = attestation, my procedure agrees with yours.

=C2=A0

BTW, you have a copy/paste error in 5.= 2 Downstream paths:

If a route from ROUTE_AFI address family is rece= ived from a customer

should be:

If a route from ROUTE_AFI address family i=
s received from a provider

=C2=A0

s/ ot / or /

=C2=A0

=C2=A0

Regards,

Jakob.

=C2=A0

From: Alexander Azimov <a.e.azimov@gmail.com>
Sent: Thursday, July 25, 2019 1:20 PM
To: Jakob Heitz (jheitz) <jheitz@cisco.com>
Cc: sidrops@ie= tf.org
Subject: Re: [Sidrops] draft-ietf-sidrops-aspa-verification-01: Hand= ling unknowns

=C2=A0

Jakob,

=C2=A0

I believe your reading of the ASPA verification proc= edure is incorrect.

=C2=A0

Section 4 defines pairs wise verification procedure = (let's call pair_verification) which returns valid, invalid and unknown= .

Sections 5.1 and 5.2 define verification procedure f= or upstream and downstream path respectively.

=C2=A0

In these procedures, the 'valid' and 'un= known' outcome of pair_verification is the same. These procedures retur= n 'valid', 'invalid' and 'unverifiable' (in case of= valid AS_SEQ + presence of AS_SET). So, your assumption that the algorithm= works when all ASes in the as-path make attestations is incorrect.<= u>

=C2=A0

To perform verification=C2=A0you don't need to s= plit ASPATH int= o triplets (or even bigger windows). I sent previously a linear function th= at makes verification for the downstream path, for the upstream path it eve= n simpler. Since you are already working on the implementation I suggest to= discuss it in person before the end of this meeting. It makes me really an= xious if the specification is unclear for implementers.

=C2=A0

=D1=87=D1=82, 25 =D0=B8=D1=8E=D0=BB. 2019 =D0=B3. = =D0=B2 08:04, Jakob Heitz (jheitz) <jheitz@cisco.com>:

I believe the path verification algorithm works when= all ASes in the as-path
make attestations. If some of the ASes make no = attestations, then a more complete
algorithm is as follows:

For every sequence (A, B, C) of consecutive ASes in an AS-path:
If A= attests that B is not a provider and C attests that B is not a provider,then B leaked the route: B is transiting for free. The segment is invalid= .
If either A or C attests that B is a provider, then the AS-path segmen= t=C2=A0 (A, B, C) is valid.
If neither A nor C make an attestation, then= the leak state is unknown. Even if B lists both A and C as providers, it i= s not necessarily a leak, because either A or C could consider B as a provi= der for some of their routes, even though they don't attest to it.

If all the path segments are valid, then the whole path is valid.
If= any of the path segments is invalid, then the whole path is invalid.
El= se, at least one path segment is unknown and one more rule must be applied:= for any sequence of ASes (A, B1, ..., Bn, C), if A attests that B1 is not = a provider and C attests that Bn is not a provider, then the AS-path is inv= alid. This is for any number of Bx greater than 1.

This algorithm breaks the AS-PATH into triples instead of pairs.
For= example, the AS_PATH (A,B,C,D,E) is broken into the triples:
(A,B,C), (= B,C,D), (C,D,E).
I find it easier to reason about it like that.
It ca= n probably be re-worded into pairs.

An additional point:
If AS-SETs exist then complete sequences betwee= n the AS-SETs can be checked for invalidity.
The best such an AS-PATH ca= n get is unknown, but it can also be verified invalid.

Regards,
Jakob.

-----Original Message-----
From: Sidrops <sidrops-bounces@ietf.org> On = Behalf Of int= ernet-drafts@ietf.org
Sent: Monday, July 8, 2019 1:24 PM
To: i-d-announce@ietf.or= g
Cc: sidrops@= ietf.org
Subject: [Sidrops] I-D Action: draft-ietf-sidrops-aspa-veri= fication-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories.
This draft is a work item of the SIDR Operations WG of the IETF= .

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: Verification of AS_PATH Using the Resource Certificate Public Key Infr= astructure and Autonomous System Provider Authorization
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Alexander Azimov=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Eugene Bogomazov
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Keyur Patel
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 Job Snijders
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 = =C2=A0 =C2=A0 =C2=A0 : draft-ietf-sidrops-aspa-verification-01.txt
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 10=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2019-07-08

Abstract:
=C2=A0 =C2=A0This document defines the semantics of an Aut= onomous System Provider
=C2=A0 =C2=A0Authorization object in the Resourc= e Public Key Infrastructure to
=C2=A0 =C2=A0verify the AS_PATH attribute= of routes advertised in the Border
=C2=A0 =C2=A0Gateway Protocol.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sidro= ps-aspa-verification/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-sidrops-aspa-= verification-01
https://datatracker.ietf.org/doc/html/draf= t-ietf-sidrops-aspa-verification-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ie= tf-sidrops-aspa-verification-01


Please note that it may take a couple of minutes from the time of submi= ssion
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
Sidrops mailing list=
Sidrops@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sidrops

_______________________________________________
Sidrops mailing list=
Sidrops@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sidrops



--

Best regards,

Alexander Azimov



--
Best regards,
Alexander Azimov
--00000000000099abd1058e9778a3-- From nobody Fri Jul 26 09:07:58 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9796D12003E for ; Fri, 26 Jul 2019 09:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 cbFMwoolMoXG for ; Fri, 26 Jul 2019 09:07:54 -0700 (PDT) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (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 5C65C120072 for ; Fri, 26 Jul 2019 09:07:47 -0700 (PDT) Received: by mail-ot1-x32a.google.com with SMTP id j19so17391310otq.2 for ; Fri, 26 Jul 2019 09:07:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4WDJBt0T4lYyEcRvOxoU95FOfElAEyBkXe0BGc6/SYY=; b=fOebjRecFqjcP1tSNbj2BJhkIyEJ5fZF4ZxUbMs36EEl9VqRi4Z3xDk6QI2xy+9pXj vSIK9iNFI2CXKkbKRa1josu5CmxjOM/Zxl5AmL0PsrxQoaHvZexRP/NZpBSJHIg/lRAz Xx/7ASATfgJQ3h0vaFPOVorShGnyusT3GLLlPdtbqjWE3cE9hPdOhfXbHRaaux6PXwzW HsY6hkSr79nEmGhFCxeJ36i7uxH4pF4ybKZYZWuGf7spOXeXxL7FlkjVM9uimriOoF8X 9o515lpvbxSyOpWMPOaIsAZxVr/eodxDSKwmFdV9ee7ubxctCnOPNQInosC3VjfkmCN+ V6Ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4WDJBt0T4lYyEcRvOxoU95FOfElAEyBkXe0BGc6/SYY=; b=fPaGbIVtA0BmiN8HCMBTgmVSByIHpE3NVY9jIHPSZvqCSbIgam2Csbac/0R9IVZKTf yApAZTx/wZ8yDs7LSWIkZKz8jaJHkOLeLs/Cf+wIsmyh+r7E6RZRnXAus3aASs1zi7Ct htus05rUEnfxxbEtQHOnzmpWP4AgRaKiglPeWYWvWE10cK3uGqszGHfrEZIHubJTaSh0 UZTGHypEPqsKV86K8uiuvonTgm/VE+s4Ex0TixaJiGWJa+m33MyARvaL4O9mUPHcnEYY eWrdJxz3vYOX9vzjhlQpbCo8fVU8I0EfCN9c40uYEsGqL6l5aypxli8/wLaFVHN6Mfeo I2Rw== X-Gm-Message-State: APjAAAUzQuVGnHB/Qt/vhGNZygVOf/MYwiQk06JEJDTPPZgrgkzB6+mx UK844nRFhMN/qGbl07ysCllPxwOcz+WMfr9p7N8= X-Google-Smtp-Source: APXvYqyCiecDicJW3+i9O53SAo59X5VTOGSj3I3nL9g7fLDD5x0BK8AXJBdikrNvUbT0VC9LtcMbR1C/qoQROLjHzsQ= X-Received: by 2002:a9d:7411:: with SMTP id n17mr65498958otk.27.1564157266713; Fri, 26 Jul 2019 09:07:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alexander Azimov Date: Fri, 26 Jul 2019 19:07:35 +0300 Message-ID: To: "Jakob Heitz (jheitz)" Cc: "sidrops@ietf.org" Content-Type: multipart/alternative; boundary="00000000000041680e058e97bebe" Archived-At: Subject: Re: [Sidrops] draft-ietf-sidrops-aspa-verification-01: Handling unknowns X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 16:07:57 -0000 --00000000000041680e058e97bebe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm sorry for the last email. It was supposed to be bigger. =D0=BF=D1=82, 26 =D0=B8=D1=8E=D0=BB. 2019 =D0=B3. =D0=B2 08:38, Jakob Heitz= (jheitz) : > If you receive an AS-PATH of 2 ASes and neither of them make any > attestation, > > then your procedure calls it valid. It could be invalid, > > so it must be considered unknown. > It an interesting point. When I was writing the ASPATH verification procedure I had in mind that we need to detect invalids. But for debugging purposes, it might be also useful to distinguish fully verified paths where all pairs are valid and those paths that represent a combination of valid and unknown pairs. It will also require clarification that for backward compatibility such unknown paths MUST be treated as valid. We should add this option into consideration. If an AS-PATH contains an AS-SET, then the segments on either side of > > the AS-SET can still be verified. If any such segment turns out to be > > invalid, then the whole path must be considered invalid, not unverifiable= . > I do agree and that's how both downstream path upstream path procedures are defined in the draft. As we discussed in person, we might need additional clarification in the beginning where {AS(I), AS(I-1)...} sequence is defined. > My procedure accounts for these cases and more. > > For the cases where every AS makes an attestation, my procedure agrees > with yours. > If you have ASPA(1, 2) you can't make assumptions about relations of 2. Otherwise, it may lead to incorrect results in the case of siblings. BTW, you have a copy/paste error in 5.2 Downstream paths: > > If a route from ROUTE_AFI address family is received from a customer > > should be: > > If a route from ROUTE_AFI address family is received from a provider > > Yes, you are right. Copy-paste can become tricky. Will be fixed in the next version. --00000000000041680e058e97bebe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm sorry for the last email. It was = supposed to be bigger.

=D0=BF=D1=82, 26 =D0=B8=D1=8E=D0=BB. 2019 =D0=B3.= =D0=B2 08:38, Jakob Heitz (jheitz) <jheitz@cisco.com>:

If you receive an AS-PATH of 2 ASes an= d neither of them make any attestation,

then your procedure calls it valid. It= could be invalid,

so it must be considered unknown.

It an interesting point. When I was writing = the ASPATH verification procedure I had in mind that we need to detect inva= lids. But for debugging purposes, it might be also useful to distinguish fu= lly verified paths where all pairs are valid and those paths that represent= a combination of valid and unknown pairs. It will also require clarificati= on that for backward compatibility such unknown paths MUST be treated as va= lid. We should add this option into consideration.

If an AS-PATH contains an AS-SET, then= the segments on either side of

the AS-SET can still be verified. If a= ny such segment turns out to be

invalid, then the whole path must be c= onsidered invalid, not unverifiable.

I do agree and that's how both downstream path upstream path procedur= es are defined in the draft.
As we discussed in person, we m= ight need additional clarification in the beginning where {AS(I), AS(I-1)..= .} sequence is defined.
=C2=A0

My procedure accounts for these cases = and more.

For the cases where every AS makes an = attestation, my procedure agrees with yours.

If you have ASPA(1, 2) you can't make assumptions about relat= ions of 2. Otherwise, it may lead to incorrect results in the case of sibli= ngs.

BTW, you have a copy/paste error in 5.= 2 Downstream paths:

If a route from ROUTE_AFI address family is rece= ived from a customer

should be:

If a route from ROUTE_AFI address family i=
s received from a provider
Yes, y= ou are right. Copy-paste can become tricky. Will be fixed in the next versi= on.

--00000000000041680e058e97bebe-- From nobody Fri Jul 26 18:35:38 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1411201E8 for ; Fri, 26 Jul 2019 18:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=RbBNz3bP; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=uBP4PO4R 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 Zk2qtjf_y__k for ; Fri, 26 Jul 2019 18:35:34 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5186A1201CE for ; Fri, 26 Jul 2019 18:35:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13459; q=dns/txt; s=iport; t=1564191334; x=1565400934; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=qYeArgxcvgXFIyCGx+R3quQF/H64TkCtiAk1KLsEjrU=; b=RbBNz3bPgnKJMPMpEbu641ZMC7KD/FI8TkAFatOjOHKpud9wPRm39Rc0 FzRWeMIzlMgZ5A8adnjjL7jskDwKK2dLj+NNHjENgN+C/deaI3fAsH6og aNqF5OxHqgVoviaLGTz2NMu1WWAkiBDSF0hGL0jnGiX2otM7MNxco4Neu I=; IronPort-PHdr: =?us-ascii?q?9a23=3AthXqaxZBjEZqXI8OdI4ReCT/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20Q6bRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavobyE7ANZqX15+9Hb9Ok9QS47z?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CrAADfqTtd/5FdJa1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBZ4EVLyQsA4FCIAQLKoQeg0cDjH+ML4kohFeBQoEQA1QJAQE?= =?us-ascii?q?BDAEBLQIBAYRAAheCSyM4EwEDAQEEAQECAQZthR4MhUsCBBIRHQEBMAcBDwI?= =?us-ascii?q?BBgIOMQMCAgIfERQRAQEEDgUigwCBHk0DHQECj2iQYAKBOIhgcYEygnoBAQW?= =?us-ascii?q?CR4JBDQuCEwmBNItfF4FAP4ERJx+CTD6CGoF3ARIBgyoygiaOfoR/iG6NTkA?= =?us-ascii?q?JAoIakBmDdxuSMIVdij2MPYpHg08CBAIEBQIOAQEFgWchZ3FwFTsqAYJBUBA?= =?us-ascii?q?UgU6DcYpTcgGBKIpEgkMBAQ?= X-IronPort-AV: E=Sophos;i="5.64,313,1559520000"; d="scan'208,217";a="309042533" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Jul 2019 01:35:33 +0000 Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x6R1ZXQI027719 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 27 Jul 2019 01:35:33 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 26 Jul 2019 20:35:32 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 26 Jul 2019 21:35:31 -0400 Received: from NAM05-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 26 Jul 2019 21:35:31 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JMs3D0V80aEc/uGci4o5Cdgyky7LSjbKAGcfiLj7Gud5Ur00ChnsmyyUxu6iJduoYAIPEPNOsljAPWM3mDhEkRBIBX98iY1esiQw3cyttLem9qZfEzSrcVXmJtJtBsy2CIM6qdmaTzyL8T4ROurLeLQujTGLeuKdRIz/wOvuEsLK2KkIfCJGkQFSq2s4BzHw+XlCL2aQK2EAp3G9xHpuLdQ59T3Xnl+k2efV3bZpIoHeShn9gNk1omBSNzEm6PBuNn0KqyPk4t11FR0e4lG7qECVmIjNXR7jxWZK5wmrWUdbv3ZaWbLXLPtd8C9hUb4PDiYHi4D1CUVbLpHDNf5Wdw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qYeArgxcvgXFIyCGx+R3quQF/H64TkCtiAk1KLsEjrU=; b=miyaHEmlIETxmfndWBUOiDh0ImV4zHu/8JQ/ii0Uj4oG9EE0oMSgm+CZpNpFIjdGouPAOBtfgbA6ohUdK9GkFqR1U+JMs+lLFwBVzyj903zAhoi6yN0/oCMk2V6S3Qx4udBRDrhpd6r1wpF37ZsqZZDiL+x4mng9SDA2brLb42090R5JKzTemPT08gu2BLgU5MfKOMnRliLhj5AmonwwfBa8ISVNuYUjnreTOsBGAovoUaR8geHDWA4dmY8yJe1MOxBLFYOhD25F78+YcEjMgKL10wDka4KEDnC+IUt9j3XphdS7eAz9uRsHJEUlIlC9ea9dOqEKBqy5sjg6uDXphQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cisco.com;dmarc=pass action=none header.from=cisco.com;dkim=pass header.d=cisco.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qYeArgxcvgXFIyCGx+R3quQF/H64TkCtiAk1KLsEjrU=; b=uBP4PO4RZsYJ7Ai9kWEqr33xBtflYCZIb5d1yBErRTHrKkZkP0R4+UsJDWqaIg7b6XAebvvN1C9o0JFtaLy7JGtsbhnF1lKfmwNbbsh88uS/3L+VRR+sCQyOQ2YL/v7Tt6HkJp8oxjv+OIo8c6HwbNafTR6na41eZmY/aVWeu10= Received: from BYAPR11MB3751.namprd11.prod.outlook.com (20.178.238.144) by BYAPR11MB3269.namprd11.prod.outlook.com (20.177.185.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2115.10; Sat, 27 Jul 2019 01:35:29 +0000 Received: from BYAPR11MB3751.namprd11.prod.outlook.com ([fe80::a894:a92:ad6e:ee2a]) by BYAPR11MB3751.namprd11.prod.outlook.com ([fe80::a894:a92:ad6e:ee2a%7]) with mapi id 15.20.2115.005; Sat, 27 Jul 2019 01:35:29 +0000 From: "Jakob Heitz (jheitz)" To: Alexander Azimov CC: "sidrops@ietf.org" Thread-Topic: [Sidrops] draft-ietf-sidrops-aspa-verification-01: Handling unknowns Thread-Index: AdVCo7iaisAZRDdHT/a/3q2UygwIOwAgqjYAABL4rDAAFn4rgAAT1XNE Date: Sat, 27 Jul 2019 01:35:29 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jheitz@cisco.com; x-originating-ip: [2600:387:b:5::a1] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3fef9b16-17bb-4baa-90b0-08d71232b547 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB3269; x-ms-traffictypediagnostic: BYAPR11MB3269: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01110342A5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(376002)(346002)(366004)(39860400002)(136003)(189003)(199004)(446003)(6436002)(102836004)(76176011)(99286004)(6506007)(53546011)(478600001)(71190400001)(5660300002)(25786009)(14454004)(6916009)(4326008)(486006)(476003)(15650500001)(11346002)(46003)(71200400001)(66946007)(68736007)(316002)(66446008)(66556008)(186003)(8936002)(81156014)(8676002)(81166006)(2906002)(76116006)(6116002)(66476007)(6512007)(54896002)(2616005)(256004)(36756003)(86362001)(7736002)(33656002)(6246003)(6486002)(229853002)(5070765005)(53936002)(14444005)(236005)(64756008)(91956017); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3269; H:BYAPR11MB3751.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 7YK1E2d02qIvNIAoLVY1PmeJccAaOEhbA6JY9b8MpManN3W4qv0QZSk6qTWjjJDgAuxGMBTb2zgcsQfrXwzk98LLFw9qINn14fUcwaEfdG9N0QvURuoZDR9nuhZ3TkcgyTJy77FSYG57V+Bqepi+544UiYj4l9zXKGlheS3HGjoV8/gxLeSJAQYbBfqV+RmJ5PtbBPwP+q7Tfcyx+7iUY8zqwkghx6BwwTFqsqCvuG8+8S3hsn7YfOGFIAB1JMIxsHJG91Xsp9VB+o3jMri8OfQXeTqDQpXooSXfLv0SGFDaPILlezsSpWhhUW6MhgQIp0cNZRayAZF371clb7NsRn0dw5rKGRPT0b742gpzFVJc9F8VFrAEWccPxS0WlC6CmNCdJ6FpVNlevtgmbQsGWihwYvAqaW/TNKm8R1VyvwU= Content-Type: multipart/alternative; boundary="_000_D85DA5AE703D4DC8A656D0D2C6A3B776ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3fef9b16-17bb-4baa-90b0-08d71232b547 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2019 01:35:29.3386 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jheitz@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3269 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.22, xch-aln-012.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: Re: [Sidrops] draft-ietf-sidrops-aspa-verification-01: Handling unknowns X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2019 01:35:37 -0000 --_000_D85DA5AE703D4DC8A656D0D2C6A3B776ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGRyYWZ0IHN0YXRlczoNCg0KQW4gQVNQQSBhdHRlc3RzIHRoYXQgYSBDdXN0b21lciBBUyBo b2xkZXIgKENBUykgaGFzIGF1dGhvcml6ZWQgYSBwYXJ0aWN1bGFyIFByb3ZpZGVyIEFTIChQQVMp IHRvIHByb3BhZ2F0ZSB0aGUgQ3VzdG9tZXLigJlzIElQdjQvSVB2NiBhbm5vdW5jZW1lbnRzIG9u d2FyZCwgZS5nLiB0byB0aGUgUHJvdmlkZXLigJlzIHVwc3RyZWFtIHByb3ZpZGVycyBvciBwZWVy cy4NCg0KSSBzdWdnZXN0IHRvIG1ha2UgdGhpcyBtb3JlIHByZWNpc2UgYW5kIHRvIGFkZCB0aGUg Im90aGVyd2lzZSIgY29uZGl0aW9uOg0KDQpBbiBBU1BBIGF0dGVzdHMgdGhhdCBhIEN1c3RvbWVy IEFTIGhvbGRlciAoQ0FTKSBoYXMgYXV0aG9yaXplZCBhIHBhcnRpY3VsYXIgUHJvdmlkZXIgQVMg KFBBUykgdG8gcHJvcGFnYXRlIHRoZSBDdXN0b21lcuKAmXMgSVB2NC9JUHY2IGFubm91bmNlbWVu dHMgdG8gYWxsIG9mIHRoZSBwcm92aWRlcidzIG5laWdoYm9ycy4gSWYgYW4gQVMsIEFTLUEgcHVi bGlzaGVzIGF0IGxlYXN0IG9uZSBBU1BBIGFuZCBpdCBsaXN0cyBBUy1CIGFzIGEgcHJvdmlkZXIg YW5kIEFTLUMgaXMgY29ubmVjdGVkIHRvIEFTLUEsIGJ1dCBBUy1BIGRvZXMgbm90IGxpc3QgQVMt QyBpbiBhbiBBU1BBLCB0aGVuIEFTLUEgYXV0aG9yaXplcyBBUy1CIHRvIHByb3BhZ2F0ZSB0aGUg YW5ub3VuY2VtZW50cyBvZiBBUy1BIHRvIGFsbCBvZiBBUy1CJ3MgbmVpZ2hib3IgQVNlcyBhbmQg YXV0aG9yaXplcyBBUy1DIHRvIHByb3BhZ2F0ZSBBUy1BJ3MgYW5ub3VuY2VtZW50cyBvbmx5IHRv IEFTZXMgdGhhdCBjb25zaWRlciBBUy1DIHRvIGJlIHRoZWlyIHByb3ZpZGVyLiBJLmUuLCBBUy1B IHByb2hpYml0cyBBUy1DIGZyb20gcHJvcGFnYXRpbmcgdGhlIGFubm91bmNlbWVudHMgb2YgQVMt QSB0byBBUy1EIGlmIEFTLUQgZG9lcyBub3QgY29uc2lkZXIgQVMtQyB0byBiZSBwcm92aWRlciBm b3IgQVMtRC4NCg0KQ29uc2VxdWVudGx5LCBhIGNoYWluIG9mIEFTUEFzIGNhbiBiZSB1c2VkIHRv IHZlcmlmeSB0aGUgcGxhdXNpYmlsaXR5IG9mIGFuIEFTLVBBVEguDQoNCg0KVGhhbmtzLA0KSmFr b2IuDQoNCg0KT24gSnVsIDI2LCAyMDE5LCBhdCAxMTowOCBBTSwgQWxleGFuZGVyIEF6aW1vdiA8 YS5lLmF6aW1vdkBnbWFpbC5jb208bWFpbHRvOmEuZS5hemltb3ZAZ21haWwuY29tPj4gd3JvdGU6 DQoNCkknbSBzb3JyeSBmb3IgdGhlIGxhc3QgZW1haWwuIEl0IHdhcyBzdXBwb3NlZCB0byBiZSBi aWdnZXIuDQoNCtC/0YIsIDI2INC40Y7Quy4gMjAxOSDQsy4g0LIgMDg6MzgsIEpha29iIEhlaXR6 IChqaGVpdHopIDxqaGVpdHpAY2lzY28uY29tPG1haWx0bzpqaGVpdHpAY2lzY28uY29tPj46DQpJ ZiB5b3UgcmVjZWl2ZSBhbiBBUy1QQVRIIG9mIDIgQVNlcyBhbmQgbmVpdGhlciBvZiB0aGVtIG1h a2UgYW55IGF0dGVzdGF0aW9uLA0KdGhlbiB5b3VyIHByb2NlZHVyZSBjYWxscyBpdCB2YWxpZC4g SXQgY291bGQgYmUgaW52YWxpZCwNCnNvIGl0IG11c3QgYmUgY29uc2lkZXJlZCB1bmtub3duLg0K SXQgYW4gaW50ZXJlc3RpbmcgcG9pbnQuIFdoZW4gSSB3YXMgd3JpdGluZyB0aGUgQVNQQVRIIHZl cmlmaWNhdGlvbiBwcm9jZWR1cmUgSSBoYWQgaW4gbWluZCB0aGF0IHdlIG5lZWQgdG8gZGV0ZWN0 IGludmFsaWRzLiBCdXQgZm9yIGRlYnVnZ2luZyBwdXJwb3NlcywgaXQgbWlnaHQgYmUgYWxzbyB1 c2VmdWwgdG8gZGlzdGluZ3Vpc2ggZnVsbHkgdmVyaWZpZWQgcGF0aHMgd2hlcmUgYWxsIHBhaXJz IGFyZSB2YWxpZCBhbmQgdGhvc2UgcGF0aHMgdGhhdCByZXByZXNlbnQgYSBjb21iaW5hdGlvbiBv ZiB2YWxpZCBhbmQgdW5rbm93biBwYWlycy4gSXQgd2lsbCBhbHNvIHJlcXVpcmUgY2xhcmlmaWNh dGlvbiB0aGF0IGZvciBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IHN1Y2ggdW5rbm93biBwYXRocyBN VVNUIGJlIHRyZWF0ZWQgYXMgdmFsaWQuIFdlIHNob3VsZCBhZGQgdGhpcyBvcHRpb24gaW50byBj b25zaWRlcmF0aW9uLg0KDQpJZiBhbiBBUy1QQVRIIGNvbnRhaW5zIGFuIEFTLVNFVCwgdGhlbiB0 aGUgc2VnbWVudHMgb24gZWl0aGVyIHNpZGUgb2YNCnRoZSBBUy1TRVQgY2FuIHN0aWxsIGJlIHZl cmlmaWVkLiBJZiBhbnkgc3VjaCBzZWdtZW50IHR1cm5zIG91dCB0byBiZQ0KaW52YWxpZCwgdGhl biB0aGUgd2hvbGUgcGF0aCBtdXN0IGJlIGNvbnNpZGVyZWQgaW52YWxpZCwgbm90IHVudmVyaWZp YWJsZS4NCkkgZG8gYWdyZWUgYW5kIHRoYXQncyBob3cgYm90aCBkb3duc3RyZWFtIHBhdGggdXBz dHJlYW0gcGF0aCBwcm9jZWR1cmVzIGFyZSBkZWZpbmVkIGluIHRoZSBkcmFmdC4NCkFzIHdlIGRp c2N1c3NlZCBpbiBwZXJzb24sIHdlIG1pZ2h0IG5lZWQgYWRkaXRpb25hbCBjbGFyaWZpY2F0aW9u IGluIHRoZSBiZWdpbm5pbmcgd2hlcmUge0FTKEkpLCBBUyhJLTEpLi4ufSBzZXF1ZW5jZSBpcyBk ZWZpbmVkLg0KDQpNeSBwcm9jZWR1cmUgYWNjb3VudHMgZm9yIHRoZXNlIGNhc2VzIGFuZCBtb3Jl Lg0KRm9yIHRoZSBjYXNlcyB3aGVyZSBldmVyeSBBUyBtYWtlcyBhbiBhdHRlc3RhdGlvbiwgbXkg cHJvY2VkdXJlIGFncmVlcyB3aXRoIHlvdXJzLg0KSWYgeW91IGhhdmUgQVNQQSgxLCAyKSB5b3Ug Y2FuJ3QgbWFrZSBhc3N1bXB0aW9ucyBhYm91dCByZWxhdGlvbnMgb2YgMi4gT3RoZXJ3aXNlLCBp dCBtYXkgbGVhZCB0byBpbmNvcnJlY3QgcmVzdWx0cyBpbiB0aGUgY2FzZSBvZiBzaWJsaW5ncy4N Cg0KQlRXLCB5b3UgaGF2ZSBhIGNvcHkvcGFzdGUgZXJyb3IgaW4gNS4yIERvd25zdHJlYW0gcGF0 aHM6DQpJZiBhIHJvdXRlIGZyb20gUk9VVEVfQUZJIGFkZHJlc3MgZmFtaWx5IGlzIHJlY2VpdmVk IGZyb20gYSBjdXN0b21lcg0Kc2hvdWxkIGJlOg0KDQpJZiBhIHJvdXRlIGZyb20gUk9VVEVfQUZJ IGFkZHJlc3MgZmFtaWx5IGlzIHJlY2VpdmVkIGZyb20gYSBwcm92aWRlcg0KDQpZZXMsIHlvdSBh cmUgcmlnaHQuIENvcHktcGFzdGUgY2FuIGJlY29tZSB0cmlja3kuIFdpbGwgYmUgZml4ZWQgaW4g dGhlIG5leHQgdmVyc2lvbi4NCg0K --_000_D85DA5AE703D4DC8A656D0D2C6A3B776ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpU aGUgZHJhZnQgc3RhdGVzOg0KPGRpdj48YnI+DQo8ZGl2PkFuIEFTUEEgYXR0ZXN0cyB0aGF0IGEg Q3VzdG9tZXIgQVMgaG9sZGVyIChDQVMpIGhhcyBhdXRob3JpemVkIGEgcGFydGljdWxhciBQcm92 aWRlciBBUyAoUEFTKSB0byBwcm9wYWdhdGUgdGhlIEN1c3RvbWVy4oCZcyBJUHY0L0lQdjYgYW5u b3VuY2VtZW50cyBvbndhcmQsIGUuZy4gdG8gdGhlIFByb3ZpZGVy4oCZcyB1cHN0cmVhbSBwcm92 aWRlcnMgb3IgcGVlcnMuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JIHN1Z2dlc3Qg dG8gbWFrZSB0aGlzIG1vcmUgcHJlY2lzZSBhbmQgdG8gYWRkIHRoZSAmcXVvdDtvdGhlcndpc2Um cXVvdDsgY29uZGl0aW9uOjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QW4gQVNQQSBh dHRlc3RzIHRoYXQgYSBDdXN0b21lciBBUyBob2xkZXIgKENBUykgaGFzIGF1dGhvcml6ZWQgYSBw YXJ0aWN1bGFyIFByb3ZpZGVyIEFTIChQQVMpIHRvIHByb3BhZ2F0ZSB0aGUgQ3VzdG9tZXLigJlz IElQdjQvSVB2NiBhbm5vdW5jZW1lbnRzIHRvIGFsbCBvZiB0aGUgcHJvdmlkZXIncyBuZWlnaGJv cnMuIElmIGFuIEFTLCBBUy1BIHB1Ymxpc2hlcyBhdCBsZWFzdCBvbmUgQVNQQSBhbmQgaXQgbGlz dHMgQVMtQiBhcyBhIHByb3ZpZGVyDQogYW5kIEFTLUMgaXMgY29ubmVjdGVkIHRvIEFTLUEsIGJ1 dCBBUy1BIGRvZXMgbm90IGxpc3QgQVMtQyBpbiBhbiBBU1BBLCB0aGVuIEFTLUEgYXV0aG9yaXpl cyBBUy1CIHRvIHByb3BhZ2F0ZSB0aGUgYW5ub3VuY2VtZW50cyBvZiBBUy1BIHRvIGFsbCBvZiBB Uy1CJ3MgbmVpZ2hib3IgQVNlcyBhbmQgYXV0aG9yaXplcyBBUy1DIHRvIHByb3BhZ2F0ZSBBUy1B J3MgYW5ub3VuY2VtZW50cyBvbmx5IHRvIEFTZXMgdGhhdCBjb25zaWRlciBBUy1DIHRvDQogYmUg dGhlaXIgcHJvdmlkZXIuIEkuZS4sIEFTLUEgcHJvaGliaXRzIEFTLUMgZnJvbSBwcm9wYWdhdGlu ZyB0aGUgYW5ub3VuY2VtZW50cyBvZiBBUy1BIHRvIEFTLUQgaWYgQVMtRCBkb2VzIG5vdCBjb25z aWRlciBBUy1DIHRvIGJlIHByb3ZpZGVyIGZvciBBUy1ELjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+Q29uc2VxdWVudGx5LCBhIGNoYWluIG9mIEFTUEFzIGNhbiBiZSB1c2VkIHRvIHZl cmlmeSB0aGUgcGxhdXNpYmlsaXR5IG9mIGFuIEFTLVBBVEguPC9kaXY+DQo8ZGl2Pjxicj4NCjxk aXY+PGJyPg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIiBkaXI9Imx0ciI+VGhhbmtzLDxi cj4NCjxkaXY+SmFrb2IuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGRp cj0ibHRyIj48YnI+DQpPbiBKdWwgMjYsIDIwMTksIGF0IDExOjA4IEFNLCBBbGV4YW5kZXIgQXpp bW92ICZsdDs8YSBocmVmPSJtYWlsdG86YS5lLmF6aW1vdkBnbWFpbC5jb20iPmEuZS5hemltb3ZA Z21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGRpcj0i bHRyIj5JJ20gc29ycnkgZm9yIHRoZSBsYXN0IGVtYWlsLiBJdCB3YXMgc3VwcG9zZWQgdG8gYmUg YmlnZ2VyLjxicj4NCjwvZGl2Pg0KPGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGRp diBkaXI9Imx0ciIgY2xhc3M9ImdtYWlsX2F0dHIiPtC/0YIsIDI2INC40Y7Quy4gMjAxOSDQsy4g 0LIgMDg6MzgsIEpha29iIEhlaXR6IChqaGVpdHopICZsdDs8YSBocmVmPSJtYWlsdG86amhlaXR6 QGNpc2NvLmNvbSI+amhlaXR6QGNpc2NvLmNvbTwvYT4mZ3Q7Ojxicj4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4 O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgi Pg0KPGRpdiBsYW5nPSJFTi1VUyI+DQo8ZGl2IGNsYXNzPSJnbWFpbC1tXzg0ODU5MjE1Mjk3NzY5 NjIyMTVXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOnJn YigxMTIsNDgsMTYwKSI+SWYgeW91IHJlY2VpdmUgYW4gQVMtUEFUSCBvZiAyIEFTZXMgYW5kIG5l aXRoZXIgb2YgdGhlbSBtYWtlIGFueSBhdHRlc3RhdGlvbiw8L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOnJnYigxMTIsNDgsMTYwKSI+dGhlbiB5b3VyIHByb2Nl ZHVyZSBjYWxscyBpdCB2YWxpZC4gSXQgY291bGQgYmUgaW52YWxpZCw8L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOnJnYigxMTIsNDgsMTYwKSI+c28gaXQgbXVz dCBiZSBjb25zaWRlcmVkIHVua25vd24uPC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQpJdCBhbiBpbnRlcmVzdGluZyBwb2ludC4gV2hlbiBJIHdhcyB3cml0aW5nIHRo ZSBBU1BBVEggdmVyaWZpY2F0aW9uIHByb2NlZHVyZSBJIGhhZCBpbiBtaW5kIHRoYXQgd2UgbmVl ZCB0byBkZXRlY3QgaW52YWxpZHMuIEJ1dCBmb3IgZGVidWdnaW5nIHB1cnBvc2VzLCBpdCBtaWdo dCBiZSBhbHNvIHVzZWZ1bCB0byBkaXN0aW5ndWlzaCBmdWxseSB2ZXJpZmllZCBwYXRocyB3aGVy ZSBhbGwgcGFpcnMgYXJlIHZhbGlkIGFuZCB0aG9zZSBwYXRocyB0aGF0DQogcmVwcmVzZW50IGEg Y29tYmluYXRpb24gb2YgdmFsaWQgYW5kIHVua25vd24gcGFpcnMuIEl0IHdpbGwgYWxzbyByZXF1 aXJlIGNsYXJpZmljYXRpb24gdGhhdCBmb3IgYmFja3dhcmQgY29tcGF0aWJpbGl0eSBzdWNoIHVu a25vd24gcGF0aHMgTVVTVCBiZSB0cmVhdGVkIGFzIHZhbGlkLiBXZSBzaG91bGQgYWRkIHRoaXMg b3B0aW9uIGludG8gY29uc2lkZXJhdGlvbi4NCjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21h aWxfcXVvdGUiPjxicj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1h cmdpbjowcHggMHB4IDBweCAwLjhleDtib3JkZXItbGVmdDoxcHggc29saWQgcmdiKDIwNCwyMDQs MjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgbGFuZz0iRU4tVVMiPg0KPGRpdiBjbGFzcz0i Z21haWwtbV84NDg1OTIxNTI5Nzc2OTYyMjE1V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpyZ2IoMTEyLDQ4LDE2MCkiPjx1PjwvdT48dT48L3U+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpyZ2IoMTEyLDQ4LDE2MCki PklmIGFuIEFTLVBBVEggY29udGFpbnMgYW4gQVMtU0VULCB0aGVuIHRoZSBzZWdtZW50cyBvbiBl aXRoZXIgc2lkZSBvZjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpyZ2IoMTEyLDQ4LDE2MCkiPnRoZSBBUy1TRVQgY2FuIHN0aWxsIGJl IHZlcmlmaWVkLiBJZiBhbnkgc3VjaCBzZWdtZW50IHR1cm5zIG91dCB0byBiZTx1PjwvdT48dT48 L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpyZ2IoMTEy LDQ4LDE2MCkiPmludmFsaWQsIHRoZW4gdGhlIHdob2xlIHBhdGggbXVzdCBiZSBjb25zaWRlcmVk IGludmFsaWQsIG5vdCB1bnZlcmlmaWFibGUuPC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2PkkgZG8gYWdyZWUgYW5kIHRoYXQncyBob3cgYm90aCBkb3duc3Ry ZWFtIHBhdGggdXBzdHJlYW0gcGF0aCBwcm9jZWR1cmVzIGFyZSBkZWZpbmVkIGluIHRoZSBkcmFm dC4NCjxicj4NCjwvZGl2Pg0KPGRpdj5BcyB3ZSBkaXNjdXNzZWQgaW4gcGVyc29uLCB3ZSBtaWdo dCBuZWVkIGFkZGl0aW9uYWwgY2xhcmlmaWNhdGlvbiBpbiB0aGUgYmVnaW5uaW5nIHdoZXJlIHtB UyhJKSwgQVMoSS0xKS4uLn0gc2VxdWVuY2UgaXMgZGVmaW5lZC48YnI+DQo8L2Rpdj4NCjxkaXY+ Jm5ic3A7PC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJn aW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIw NCk7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGxhbmc9IkVOLVVTIj4NCjxkaXYgY2xhc3M9Imdt YWlsLW1fODQ4NTkyMTUyOTc3Njk2MjIxNVdvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6cmdiKDExMiw0OCwxNjApIj48dT48L3U+PHU+PC91Pjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6cmdiKDExMiw0OCwxNjApIj5N eSBwcm9jZWR1cmUgYWNjb3VudHMgZm9yIHRoZXNlIGNhc2VzIGFuZCBtb3JlLjx1PjwvdT48dT48 L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpyZ2IoMTEy LDQ4LDE2MCkiPkZvciB0aGUgY2FzZXMgd2hlcmUgZXZlcnkgQVMgbWFrZXMgYW4gYXR0ZXN0YXRp b24sIG15IHByb2NlZHVyZSBhZ3JlZXMgd2l0aCB5b3Vycy48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+SWYgeW91IGhhdmUgQVNQQSgxLCAyKSB5b3UgY2Fu J3QgbWFrZSBhc3N1bXB0aW9ucyBhYm91dCByZWxhdGlvbnMgb2YgMi4gT3RoZXJ3aXNlLCBpdCBt YXkgbGVhZCB0byBpbmNvcnJlY3QgcmVzdWx0cyBpbiB0aGUgY2FzZSBvZiBzaWJsaW5ncy48L2Rp dj4NCjxicj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjow cHggMHB4IDBweCAwLjhleDtib3JkZXItbGVmdDoxcHggc29saWQgcmdiKDIwNCwyMDQsMjA0KTtw YWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgbGFuZz0iRU4tVVMiPg0KPGRpdiBjbGFzcz0iZ21haWwt bV84NDg1OTIxNTI5Nzc2OTYyMjE1V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpyZ2IoMTEyLDQ4LDE2MCkiPjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpyZ2IoMTEyLDQ4LDE2MCkiPkJUVywg eW91IGhhdmUgYSBjb3B5L3Bhc3RlIGVycm9yIGluIDUuMiBEb3duc3RyZWFtIHBhdGhzOjx1Pjwv dT48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+SWYgYSByb3V0ZSBmcm9tIFJPVVRFX0FGSSBhZGRyZXNzIGZhbWlseSBpcyByZWNlaXZl ZCBmcm9tIGEgY3VzdG9tZXI8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6cmdiKDExMiw0OCwxNjApIj5zaG91bGQgYmU6PHU+PC91Pjx1 PjwvdT48L3NwYW4+PC9wPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPklmIGEgcm91 dGUgZnJvbSBST1VURV9BRkkgYWRkcmVzcyBmYW1pbHkgaXMgcmVjZWl2ZWQgZnJvbSBhIHByb3Zp ZGVyPC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+WWVz LCB5b3UgYXJlIHJpZ2h0LiBDb3B5LXBhc3RlIGNhbiBiZWNvbWUgdHJpY2t5LiBXaWxsIGJlIGZp eGVkIGluIHRoZSBuZXh0IHZlcnNpb24uPC9kaXY+DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_D85DA5AE703D4DC8A656D0D2C6A3B776ciscocom_-- From nobody Mon Jul 29 01:07:16 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE0712008C for ; Mon, 29 Jul 2019 01:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl 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 7OJ-4HiULf53 for ; Mon, 29 Jul 2019 01:07:12 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6D3C120033 for ; Mon, 29 Jul 2019 01:07:12 -0700 (PDT) Received: from [IPv6:2001:981:4b52:1:410b:4bee:13d8:63f1] (unknown [IPv6:2001:981:4b52:1:410b:4bee:13d8:63f1]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 4B6372CB37; Mon, 29 Jul 2019 10:07:10 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1564387630; bh=GNIn74VucBNi56BUaKhnK6dqdoNYkuPBds0P1hu9Y1A=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=fv3HmK4C4r96bdO5ZHa8hwRhppm2oXVzkWRtp7cB8DDYJoB+8sI7YG/uPGWM12Zc8 i7x0DunGBx3gzrXlz/dZzMEn00N5kFnCnwAPiEk5clBbHcCPeWUtGdrgI3bFEUb4W5 xNsw4+dqk2kplzhB/tKP+q4uxUqhIdLDwqnxEUf4= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Tim Bruijnzeels In-Reply-To: Date: Mon, 29 Jul 2019 10:07:09 +0200 Cc: SIDR Operations WG Content-Transfer-Encoding: 7bit Message-Id: <09ECA279-AB99-4967-AB2F-77BEF261E837@nlnetlabs.nl> References: To: Randy Bush X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Sidrops] draft-ymbk-sidrops-ov-egress X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2019 08:07:14 -0000 > On 23 Jul 2019, at 22:37, Randy Bush wrote: > > request wg adoption of draft-ymbk-sidrops-ov-egress support > > randy > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Mon Jul 29 05:01:17 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF4CA120120 for ; Mon, 29 Jul 2019 05:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 f4dc8ubvrOgV for ; Mon, 29 Jul 2019 05:01:14 -0700 (PDT) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97D661200F8 for ; Mon, 29 Jul 2019 05:01:14 -0700 (PDT) Received: from allealle.ripe.net ([193.0.23.12]) by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hs4L2-000CJe-2j; Mon, 29 Jul 2019 14:01:12 +0200 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::e02]) by allealle.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hs4K5-0005vi-4W; Mon, 29 Jul 2019 14:00:13 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Oleg Muravskiy In-Reply-To: Date: Mon, 29 Jul 2019 14:00:12 +0200 Cc: SIDR Operations WG Content-Transfer-Encoding: 7bit Message-Id: References: To: Randy Bush X-Mailer: Apple Mail (2.3445.104.11) X-ACL-Warn: Delaying message X-RIPE-Signature: c408758d4ce2e8eb06762a65a3365b7443803a099a96bac100e148f1fce8e9cf Archived-At: Subject: Re: [Sidrops] draft-ymbk-sidrops-ov-egress X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2019 12:01:16 -0000 On 23 Jul 2019, at 22:37, Randy Bush wrote: > > request wg adoption of draft-ymbk-sidrops-ov-egress > > randy Support Oleg