From nobody Fri Mar 1 02:25: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 EBBAB130DE4; Fri, 1 Mar 2019 02:25:08 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 o0vqQQhMuD2D; Fri, 1 Mar 2019 02:25:05 -0800 (PST) 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 39464130E2F; Fri, 1 Mar 2019 02:25:05 -0800 (PST) Received: by mail-ot1-x32c.google.com with SMTP id t7so20477520otk.8; Fri, 01 Mar 2019 02:25:05 -0800 (PST) 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=MBHkpMRhUifqXIHzzd1cHjKifPM/PJ4H0ohSH4/EJv0=; b=PQ4Wj6FTHh76iwJJJvX1dsuB8r+ad3Bez/Jkx6j6/YHS5/9MQOsKqzt30Ge3GmTNzq NQaH+owEiP9Ve7sTgSSRYvY1imLqOJohjaTGm+2ebCeCpIByUBiSOGmUkURSzjDQx6lX +c9MU5IxkUzO6D763gg+L+yuf5uxR9zBw/Q9cXwpjpHf8HrjCGKlIgPohE3O0PsMGvH/ 7IdUSf3TAmg84Vu4RIe/d2mks3gCO7TNFMHqMMtdGn8RpZNywMQX9Dm7oBU/Jkp9i+Hb fxIGi1idQU607COPzKqQDoJcQa79QhQ6NAmr3ADwTQxg/xxBRc5OILYCZ7lU1YVj0V/b i87Q== 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=MBHkpMRhUifqXIHzzd1cHjKifPM/PJ4H0ohSH4/EJv0=; b=KNa/jjNkLvWKmMeEGT7T1OH7VuJDN64s/KRlKrFpRtBg3e664BL97uiG7iJlDJasaQ uVkHLFb21tIsh7/T/XwcHIBqxIU05aJAbj25cHDLS8Eskatg6UAcQiZCW7NRFYNEYb4Q iiQtqJr5GpfWdAj55jikKJD9MCuUBJWoU2CBxfK/lNCz3XMnctn0Q1UQSh1m0PJCGLAV f04ecRgMCkjx6YurLuFfxab9yGbOp3R1GzWZ2I8HSPQdZZFZaFjZrYZEixvu5Tq2fzNq ykuBp2fxnM30mh+yseyvI5itD06A3dL3cBrfwTq8sOj3NGLWZU2sgQt7Wkig0bQN7rOx LKZw== X-Gm-Message-State: APjAAAVVB4F5q+UZddn1Ab0b2kOT/+LhyDRgVAEoqw32lVmF8FTDoTWw NqbpQZGndZfKs4gu0H/YtWewMduE/R/izhXpO9M= X-Google-Smtp-Source: APXvYqxzYpAdUI2zt+VtD3UfuDR+LMw6ePu1ywY3nhVKQxuyHiwg9B0ygQXR0r0SxIylB4cOZ/RLy5n9aXdbRKOOdWk= X-Received: by 2002:a9d:2c01:: with SMTP id f1mr2642517otb.311.1551435904047; Fri, 01 Mar 2019 02:25:04 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Alexander Azimov Date: Fri, 1 Mar 2019 13:24:52 +0300 Message-ID: To: "Sriram, Kotikalapudi (Fed)" Cc: "sidrops-chairs@ietf.org" , "sidrops@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f3e05d058305d157" Archived-At: Subject: Re: [Sidrops] WG Adoption call draft-azimov-sidrops-aspa-verification 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, 01 Mar 2019 10:25:09 -0000 --000000000000f3e05d058305d157 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In #1 I meant to say 'victim': Can you please clarify to me next scenario with three ISPs: - Victim advertises /23 to Upstream, does use BGPSec, has ROA record with maxlength 24 - Upstream, does use BGPSec - Attacker, advertises /24 that belongs to *Victim*, adds its ASN at the beginning of ASPath, doesn't use BGPSec Will Upstream, according to RFC8205, accept the hijacked route from Attacker? Anyway, I'm open for discussion about proper wording here. =D1=87=D1=82, 28 =D1=84=D0=B5=D0=B2=D1=80. 2019 =D0=B3. =D0=B2 20:53, Alexa= nder Azimov : > Sriram, > > I'm glad to see your comments! Please see my answers below. > > Comment #1: >> >> I would strongly suggest deletion of the last two sentences of >> >> the second paragraph in the Intro section. >> >> You talk about downgrade attacks with BGPsec there. >> >> The two sentences in question are inconsistent with how >> >> incremental deployment of BGPsec really works. >> >> Please read RFC 8205 Section 7.9 -- the idea of contiguous BGPsec ASes. >> >> Regarding your attacker downgrading BGPsec comments, >> >> John Scudder also suggested to you in IETF 102, >> >> =E2=80=9CIt is not necessary to make that extreme claim for your proposa= l, >> >> if I were you, I wouldn=E2=80=99t.=E2=80=9D See video at ~48 minute mar= k: >> >> https://www.youtube.com/watch?v=3DLnXLB_MlpAs >> > Can you please clarify to me next scenario with three ISPs: > > - Victim advertises /23 to Upstream, does use BGPSec, has ROA record > with maxlength 24 > - Upstream, does use BGPSec > - Attacker, advertises /24 that belongs to Upstream, adds its ASN in > the beginning of ASPath, doesn't use BGPSec > > Will Upsream, according to RFC8205, accept hijacked route from Attacker? > Anyway, I'm open for discussion about proper wording here. > > >> Comment #2: Improvement of the algorithm for detection >> >> Consider this topology example: >> >> >> >> AS3 AS5 >> >> / \ / >> >> AS2 AS4 >> >> / >> >> AS1 >> >> >> >> The peering relations are C2P going up and P2C going down (in the pic). >> >> AS1, AS2 and AS4 have created ASPAs. AS3 has not created ASPA. >> >> Let us say AS4 accidentally leaks to AS5 the route received from AS3. >> >> The route=E2=80=99s AS_PATH is AS4 AS3 AS2 AS1. >> >> I think your algorithm (section 5) would fail to detect the leak. >> >> But I would suggest a modified algorithm which is as follows: >> >> At AS5, when it sees that AS3 does not have ASPA, it then considers >> >> the ASPA of the next more recent AS in the path which is AS4 here. >> >> From AS4=E2=80=99s ASPA, AS5 determines that AS3 is a provider of AS4, >> >> and hence successfully detects that the update is a route leak. >> >> So, I think the algorithm in section 5 needs to be modified per >> suggestion above. >> > This suggestion sounds great but it has an issue. Imagine that AS3 and AS= 4 > have what is commonly named 'complex' relation. So they are both > customer-provider to one another. And in your scenario, where only AS4 > creates ASPA it may result in rejection of valid routes, which will make > AS4 quite unhappy... > > >> Comment #3: >> >> In the figure below, AS1 originates p1 and AS2 originates p2. >> >> AS1 is a provider of AS2 for p1 and AS1 is a customer of AS2 for p2. >> >> AS1 announces p1 to AS2 as P2C. AS2 announces p2 to AS1 as P2C. >> >> AS3 is provider of AS2. >> >> >> >> ---------P2C-------> >> >> p1 AS1 >> ---> -----p1 AS2 AS1---> >> >> AS1------------------(hybrid/complex)----------AS2---------- C2P >> ----------->AS3 >> >> <--- p2 AS2 >> >> <---------P2C------- >> >> AS1 creates an ASPA: {AS1, AS2, IPv4} >> >> AS2 creates an ASPA: {AS2, AS1, IPv4} >> >> >> >> Now consider AS2 leaks route for p1 to AS3. Then AS3 is unable to detect >> the leak. >> >> AS3 looks at the ASPA: {AS1, AS2, IPv4} and determines that AS1 is a >> customer of AS2, >> >> and hence determines incorrectly that the Update: p1 AS2 AS1 is not a >> leak. >> >> The ASPA scheme fails to work in this case for leak detection. >> >> This is a limitation of the ASPA scheme because ASPAs are per AFI and no= t >> per prefix. >> > Fully agreed. Simplicity comes with its own cost. > And that's why we still need community-based leak detection that can work > per-prefix. And it's our duty as-coauthors (and my debt, which I need to > admit) to finally push it forward. > I'm going to add an explicit statement in the next version of the draft. > > >> Comment #4: Not all malicious leaks / hijacks are detected >> >> In the topology below, AS2 leaks the path it learned from its peer AS4 t= o >> >> its provider AS3 with path modification to avoid route leak detection, >> >> or one may think of it as a hijack with feasible path insertion. >> >> In either case, the Update: p2 AS2 AS1 from AS2 to AS3 is >> >> illegitimate but defies detection despite all ASes participating in >> ASPA. >> >> >> >> AS3 >> AS5 >> >> \ p1 AS2 AS1 / >> >> \ p2 AS2 AS1 / >> >> \ / >> >> \ <----p2 AS4 AS1-- / >> >> AS2 -------p2p----------AS4 >> >> \ / >> >> \ p1 AS1 /p2 AS1 >> >> \ / >> >> AS1 >> >> (p1, p2) >> >> >> > Thinking about it as hijack adds simplicity to the picture. Customers may > still be hijacked by its direct or indirect providers. While it > significantly limits the attacker vector and highly unlikely to happen in > the real world, it must be clearly stated in the draft. Pushed to stack. > >> >> Comment #5: Path verification vs. path feasibility >> >> Based on the above examples, in the draft, perhaps it is better to say >> >> that the path is assessed feasible rather than say that the path is >> verified. >> > I'm not a native speaker but for me 'feasibility' sounds a bit odd. I > would be glad to learn other opinions from the wg members. Anyway, this > question should not become a showstopper. > > Comment #6: >> >> In paragraph #1 in the Intro section, [I-D.ymbk-idr-bgp-eotr-policy] is >> referenced. >> >> Based on WG consensus, we merged [I-D.ymbk-idr-bgp-eotr-policy] and >> >> [I-D.idr-route-leak-detection-mitigation] and the latter is the WG >> document >> >> that we are working on together since April 2018. >> >> So, [I-D.idr-route-leak-detection-mitigation] is the more appropriate >> >> document to cite for the ongoing WG effort. >> > I don't think there was a need in such a detailed history of the question= . > :) > Valid point. I'll change the link with the next update. > > > -- > Best regards, > Alexander Azimov > --=20 Best regards, Alexander Azimov --000000000000f3e05d058305d157 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In #1 I meant to say 'victim':

<= div>
Can you please clarify to me next scenario with three ISPs:
=
  • Victim advertises /23 to Upstream, does use BGPSec, has ROA re= cord with maxlength 24
  • U= pstream, does use BGPSec
  • Attacker, advertises /24 that belongs to Victim, adds its ASN at the beginn= ing of ASPath, doesn't use BGPSec
Will Upstream, accordin= g to RFC8205, accept the hijacked route from Attacker?
Anyway, I&= #39;m open for discussion about proper wording here.

= =D1=87=D1=82, 28 =D1=84=D0=B5=D0=B2=D1=80. 2019 =D0=B3. =D0=B2 20:53, Alexa= nder Azimov <a.e.azimov@gmail.co= m>:
Sriram,
<= div>
I'm glad to see your comments! Please see my answers= below.

Comment #1:

I would strongly suggest deletion of the last two se= ntences of

the second paragraph in the Intro section.

You talk about downgrade attacks with BGPsec there.<= /p>

The two sentences in question are inconsistent with = how=20

incremental deployment of BGPsec really works.

Please read RFC 8205 Section 7.9 -- the idea of cont= iguous BGPsec ASes.

Regarding your attacker downgrading BGPsec comments,=

John Scudder also suggested to you in IETF 102,

=E2=80=9CIt is not necessary to make that extreme cl= aim for your proposal,

if I were you, I wouldn=E2=80=99t.=E2=80=9D=C2=A0 Se= e video at ~48 minute mark:

https://www.youtube.com/watch?v=3DLnXLB_MlpAs

Can you please clarify to me next scenario = with three ISPs:
  • Victim advertises /23 to Upstream, = does use BGPSec, has ROA record with maxlength 24
  • Upstream, doe= s use BGPSec
  • Attacker, advertises /24 that belongs to Upstream, add= s its ASN in the beginning of ASPath, doesn't use BGPSec
= Will Upsream, according to RFC8205, accept hijacked route from Attacker?
Anyway, I'm open for discussion about proper wording here.
<= /div>=C2=A0

Comment #2: Impr= ovement of the algorithm for detection=20

Consider this topology example:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 AS3= =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 AS5

=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=C2=A0 \=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 /

=C2=A0=C2=A0=C2=A0 AS2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 AS4

=C2=A0=C2=A0=C2=A0/

AS1=C2=A0

=C2=A0

The peering relations are C2P going up and P2C going= down (in the pic).

AS1, AS2 and AS4 have created ASPAs. AS3 has not cre= ated ASPA.

Let us say AS4 accidentally leaks to AS5 the route r= eceived from AS3.

The route=E2=80=99s AS_PATH is AS4 AS3 AS2 AS1.

I think your algorithm (section 5) would fail to det= ect the leak.

But I would suggest a modified algorithm which is as= follows:

At AS5, when it sees that AS3 does not have ASPA, it= then considers

the ASPA of the next more recent AS in the path whic= h is AS4 here.

From AS4=E2=80=99s ASPA, AS5 determines that AS3 is = a provider of AS4,

and hence successfully detects that the update is a = route leak.

So, I think the algorithm in section 5 needs to be m= odified per suggestion above.

This suggestion s= ounds great but it has an issue. Imagine that AS3 and AS4 have what is comm= only named 'complex' relation. So they are both customer-provider t= o one another. And in your scenario, where only AS4 creates ASPA it may res= ult in rejection of valid routes, which will make AS4 quite unhappy...
= =C2=A0=C2=A0

Comment #3:

In the figure below, AS1 originates p1 and AS2 origi= nates p2.

AS1 is a provider of AS2 for p1 and AS1 is a custome= r of AS2 for p2.

AS1 announces p1 to AS2 as P2C. AS2 announces p2 to = AS1 as P2C.

AS3 is provider of AS2.

=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ---------P2C-----= -->

=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=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=A0p1 AS1 --->=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=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=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -----p1 AS2 AS1--->=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=C2= =A0

AS1------------------(hybrid/complex)----------AS2--= -------- C2P ----------->AS3

=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 <--- p2 AS2

=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <---------P2C-= ------

AS1 creates an ASPA: {AS1, AS2, IPv4}

AS2 creates an ASPA: {AS2, AS1, IPv4}

=C2=A0

Now consider AS2 leaks route for p1 to AS3. Then AS3= is unable to detect the leak.

AS3 looks at the ASPA: {AS1, AS2, IPv4} and determin= es that AS1 is a customer of AS2,

and hence determines incorrectly that the Update: p1= AS2 AS1 is not a leak.

The ASPA scheme fails to work in this case for leak = detection.

This is a limitation of the ASPA scheme because ASPA= s are per AFI and not per prefix.

Fully agreed.= Simplicity comes with its own cost.
And that's why we still need co= mmunity-based leak detection that can work per-prefix. And it's our dut= y as-coauthors (and my debt, which I need to admit) to finally push it forw= ard.
I'm going to add an explicit statement in the next version of= the draft.
=C2=A0

Comment #4: Not all malicious leaks / hijacks are detected

In the topology below, AS2 leaks the path it learned= from its peer AS4 to

its provider AS3 with path modification to avoid rou= te leak detection,

or one may think of it as a hijack with feasible pat= h insertion.=C2=A0=C2=A0

In either case, the Update: p2 AS2 AS1 from AS2 to A= S3 is=20

illegitimate but defies detection despite all ASes p= articipating in ASPA.=C2=A0=C2=A0=C2=A0

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 AS3= =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=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=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=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 AS5

=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 \=C2=A0 p1 AS2 AS1=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=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=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0\ p2 AS2 AS1=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=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=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=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=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= =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=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=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=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=C2=A0 \=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <----p2 AS4 AS1--=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 AS2 -------p2p----------AS4

=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=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\=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=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=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=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=C2=A0=C2=A0=C2=A0=C2=A0 \ p1 AS1=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /p2 AS1

=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=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=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=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=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=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=C2=A0=C2= =A0=C2=A0=C2=A0 AS1

=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=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 (p1, p2)=C2=A0

=C2=A0

Thinking about it= as hijack adds simplicity to the picture. Customers may still be hijacked = by its direct or indirect providers. While it significantly limits the atta= cker vector and highly unlikely to happen in the real world, it must be cle= arly stated in the draft. Pushed to stack.
=C2=A0

Comment #5: Path verification vs. path feasibility

Based on the above examples, in the draft, perhaps i= t is better to say

that the path is assessed feasible rather than say t= hat the path is verified.

I'm not a native speaker but for me 'f= easibility' sounds a bit odd. I would be glad to learn other opinions f= rom the wg members. Anyway, this question should not become a showstopper.<= /div>

Comment #6:

In paragraph #1 in the Intro section, [I-D.ymbk-idr-= bgp-eotr-policy] is referenced.

Based on WG consensus, we merged [I-D.ymbk-idr-bgp-e= otr-policy] and

[I-D.idr-route-leak-detection-mitigation] and the la= tter is the WG document

that we are working on together since April 2018.=

So, [I-D.idr-route-leak-detection-mitigation] is the= more appropriate

document to cite for the ongoing WG effort.

I don't think there was a need in such a detailed h= istory of the question. :)
Valid point. I'll change the link with th= e next update.
=C2=A0

--
Best regards,
Alexander Azimov


--
Best regards,
Alexander Azimov
--000000000000f3e05d058305d157-- From nobody Fri Mar 1 13:12:28 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 74D8F130F17; Fri, 1 Mar 2019 13:10:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: sidrops@ietf.org, warren@kumari.net X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155147460047.6101.13567246966523103534.idtracker@ietfa.amsl.com> Date: Fri, 01 Mar 2019 13:10:00 -0800 Archived-At: Subject: [Sidrops] sidrops - Requested session has been scheduled for IETF 104 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: Fri, 01 Mar 2019 21:10:10 -0000 Dear Liz Flynn, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. sidrops Session 1 (1:00 requested) Tuesday, 26 March 2019, Morning Session I 0900-1100 Room Name: Congress Hall 3 size: 250 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/104/sessions/sidrops.ics Request Information: --------------------------------------------------------- Working Group Name: SIDR Operations Area Name: Operations and Management Area Session Requester: Liz Flynn Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 80 Conflicts to Avoid: First Priority: idr grow Second Priority: opsarea opsec Third Priority: opsawg People who must be present: Keyur Patel Alvaro Retana Chris Morrow Warren "Ace" Kumari Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sat Mar 2 17:36: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 5A6501200D8; Sat, 2 Mar 2019 17:36:14 -0800 (PST) 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 zXxANYWm2IoG; Sat, 2 Mar 2019 17:36:10 -0800 (PST) Received: from GCC01-CY1-obe.outbound.protection.outlook.com (mail-eopbgr830131.outbound.protection.outlook.com [40.107.83.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F72412785F; Sat, 2 Mar 2019 17:36:10 -0800 (PST) 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=E0fmLGHqXh3eQKL6JGSOpHZDZ5+/7/hDIuG0MgLXzvM=; b=j7mJ36bhnHEzgoA97YPbWzHaOgCcVSegfo0kkm1gEei5pRbgCyNH4/gKu8LZurDQddofpC19QKvi4UJsqaJYERBoXLFh72JXGE2ojMethWRmxSvTvt3KToppbXRm+3rnjFcDMIsr3GlCyOlF+INH0BY8Ab3UoFgLIT53LGNMdOg= Received: from SN6PR0901MB2366.namprd09.prod.outlook.com (52.132.115.159) by SN6PR0901MB2368.namprd09.prod.outlook.com (52.132.116.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.18; Sun, 3 Mar 2019 01:36:08 +0000 Received: from SN6PR0901MB2366.namprd09.prod.outlook.com ([fe80::5c3a:f8a5:80dd:2d85]) by SN6PR0901MB2366.namprd09.prod.outlook.com ([fe80::5c3a:f8a5:80dd:2d85%5]) with mapi id 15.20.1665.017; Sun, 3 Mar 2019 01:36:08 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Alexander Azimov CC: "sidrops-chairs@ietf.org" , "sidrops@ietf.org" Thread-Topic: [Sidrops] WG Adoption call draft-azimov-sidrops-aspa-verification Thread-Index: AQHUz46GzEO4+XNrd0q8gcAsK5oxyqX2kuYAgAKHMLA= Date: Sun, 3 Mar 2019 01:36:08 +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.219.64] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 26171441-ceed-44fa-ad38-08d69f789c3f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7153060)(7193020); SRVR:SN6PR0901MB2368; x-ms-traffictypediagnostic: SN6PR0901MB2368: x-ms-exchange-purlcount: 3 x-microsoft-exchange-diagnostics: =?Windows-1252?Q?1; SN6PR0901MB2368; 23:sT1gdMp3Lxu284YOtCZ/iIWW8xxPc8g7Kig?= =?Windows-1252?Q?n50ZhEs2R+P7vQln0J7C8TlOeklTix11qb5VJ1/uCx3ng+lZBd8efraT?= =?Windows-1252?Q?DoeNdU0FvPUktEJ3uRwnwIl/vOhOtUKxxOGId8VWQsFqNi6RC8IRp//f?= =?Windows-1252?Q?SUPf1XaWrhnIbjFzjYcCVk5NV+QRuYjsd/nb0OYOLauytblH1+XPndDn?= =?Windows-1252?Q?6Lk7JDYXSaX4+360SpCYWqFCoKyEtu5BfDxyoMyoKnsmjBTTSf8CW8A0?= =?Windows-1252?Q?cfhustXJhQs9H5Cp0Pqg65QO1gWkotMrTngemhaz2h/VpjSFWcFmYree?= =?Windows-1252?Q?ldPF0WDt/4NOnX71vaKGAV7SsjsEFnYM0frLTbYnLw5eQ+yKGqY6G4F7?= =?Windows-1252?Q?3er7SHNEVyDJ6nwyHPPnb8p/cQlTVjXKgnm33LX3m4Lp0MgUXRqDz4gw?= =?Windows-1252?Q?p78jqX9hhXu7gkcg2dLORgJxFLkZQp3RmerjUopyBFdTXGAGzZ3FkXkb?= =?Windows-1252?Q?mJ0GnoQ6eFEHP+v5U1Pxxai0udseD7pzdB6GA7XNFlJOC+QuO41nPmxo?= =?Windows-1252?Q?sz7DzCWXQx7JNEjaOyBRq5bBwKMOKTJAzswatsJBrHogUCB6URep3MFK?= =?Windows-1252?Q?/zmqNZ+RMiAiwGy5zHh1fCT/hSyLQF9+b3Z9kqmRAkWryYGpDPxjQTW8?= =?Windows-1252?Q?BOYawN6UNaMyFEmolRXpa5t8qYAt8FohXUHcIBxP2wEdil01VDuKp6Ft?= =?Windows-1252?Q?OEsxKtYw6urzGneLDAzrfiaE4SnmPGPDx+Cwrc42oPXmo+ykkhSMvHTN?= =?Windows-1252?Q?xTy11sVUNQEge0GfFoU8K7mLsUECCxuAnNzsuVc8OyUKZavy/No1ZMvg?= =?Windows-1252?Q?W3V9euQHtBwP5WIy22CJb1lMTI8IC7oXcX0GcosXhg97xfhPq68y02iD?= =?Windows-1252?Q?TThKHlA4Cmdu+RoZuP/hm1+WA+6NWzk/M6gqQCXISPZ0FXwHKzib7+fJ?= =?Windows-1252?Q?HTjdsEZxNyF31E7js/w+TApZ8batLB8FI7KD3eVg9VDzAaSFYMr2h9Qn?= =?Windows-1252?Q?LlOo3oBqRznS2DbOWWr+/NdlEf5npLlEXrRQa17/N11eoiMX1o3CSc26?= =?Windows-1252?Q?o1Y6K1qaPJSHq38TstQm5wRFIWptdUaw5RYjPtFNdUv3ScFGuhZmBc64?= =?Windows-1252?Q?xDbDmgiPJ89+8W/nsJDLOzTm9yI78cu1nS6HchQDtCIuaTwveEBYRQ55?= =?Windows-1252?Q?NY+rEdBYdCVZdC9AFtzgANhUJJCBw9/ZXlnwNukmzconBnftoDRzRaEs?= =?Windows-1252?Q?MJ+mU0xaZNYzCZ72kXUfh04KX2FdkHyjUc+x1bVuU3CsrBlpkqvJjBoZ?= =?Windows-1252?Q?VelhtlMgfbYfdkU7ODXaeVqF72poOMSGUJwhPdDFWnuq3qf36qeYowZv?= =?Windows-1252?Q?b4aeAlxhOnCtELTSNfcANgjh7f7Yiys9wHQVKmzfKzUWrguAkWwx5Iov?= =?Windows-1252?Q?5sxbIWnI=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 096507C068 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(376002)(396003)(136003)(39850400004)(52314003)(189003)(199004)(33656002)(11346002)(446003)(8936002)(86362001)(305945005)(7736002)(6506007)(68736007)(26005)(15650500001)(486006)(74316002)(316002)(2420400007)(476003)(97736004)(76176011)(25786009)(81166006)(105586002)(8676002)(106356001)(54906003)(102836004)(6116002)(3846002)(81156014)(53936002)(99286004)(66066001)(6916009)(55016002)(6436002)(9686003)(6306002)(7696005)(5660300002)(71190400001)(71200400001)(256004)(14444005)(6246003)(52536013)(14454004)(229853002)(4326008)(186003)(966005)(2906002)(478600001)(10710500007); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR0901MB2368; H:SN6PR0901MB2366.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: mXmDAYIpsXOHuVWiJnMd+epwKNSTs86riB1iCWVO1rEqgTZJaKjb5W3J2qbY7TDZTdbQfIAuB3wVnRY1xmP2XvgmW/PFp/WnlXzLNpgWjQz5ESRaHepgtknPHp1TVNoI/VghGcnouh94TA07LwnA9E+NJfpsMMyRfJ+Lauleu5z06ToDtvmBMbFgTdC8ylGyeNczOhtEazbE9ZjECfMFZIiMhMPTGYT4JFXRfNyKor5cgAyli8W4bILbA83BUxt+cqw7vHL407WetkI8bdZtbLUmU6J3wK1AXmmlj39SJirDpj119baryDNr6TszVlY6CRqIX7LBTRee1dJLCvwepFPv9MaP9oTjjO1M/lV+Mt1LKrKWZ1R2g/WBzKAGzjtrF4BgMJuJ+vA2SSuxD31lw7TqwFsoUOmsoSLIKjg/OuI= Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 26171441-ceed-44fa-ad38-08d69f789c3f X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2019 01:36:08.4133 (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-Transport-CrossTenantHeadersStamped: SN6PR0901MB2368 Archived-At: Subject: Re: [Sidrops] WG Adoption call draft-azimov-sidrops-aspa-verification 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, 03 Mar 2019 01:36:15 -0000 Hi Alex, So, yes there are things we need to careful about in the design. Also, got to be careful about claiming, =93this mechanism guarantees detection of both malicious and accidental route leaks=94.=20 There is a new Comment #0 that I have added here. And I have other comments inline below.=20 Comment#0: One more thing occurred to me. This is very basic.=20 Consider these frequently occurring examples of route leaks: AS1 (Tier 1)----P2C---->AS2 (customer)----C2P-----> AS3 AS1 (Tier 1)----p2p---->AS2 (Tier 1)----p2p-----> AS3 (Tier 1) AS2 leaks the route learned from AS1 in both cases above.=20 AS1 being a Tier 1, never has to create an ASPA (has no providers). =20 Regardless of whether AS2 created an ASPA or not, AS3 is not able to detect the leaks in both cases above (per algorithm in the draft). This same issue arises even in the example of Comment #2 if AS3 in that example were a Tier 1. >>Comment #1 --- snip --- >Can you please clarify to me next scenario with three ISPs:=20 > - Victim advertises /23 to Upstream, does use BGPSec,=20 > has ROA record with maxlength 24 > - Upstream, does use BGPSec > - Attacker, advertises /24 that belongs to Victim, adds its ASN at=20 > the beginning of ASPath, doesn't use BGPSec >Will Upstream, according to RFC8205, accept the hijacked route from Attack= er? >Anyway, I'm open for discussion about proper wording here. The idea of a BGPsec cloud (some call it island) needs to be understood. I hope you had chance to read RFC 8205 Section 7.9 =96=20 the idea of contiguous BGPsec ASes. A group of contiguous BGPsec ASes decides that they=20 require signed updates (i.e., BGPsec) from Day X *within their cloud*.=20 What that means is that they have knowledge that they are=20 contiguous (all connected to each other by some # of hops), and they all do BGPsec. And they decide that BGPsec must be done end-to-end within their BGPsec cloud.=20 Then from Day X, they require signed/valid paths for prefixes=20 that *originate within their BGPsec cloud*. (Prefixes originated from outside the cloud may be unsigned and may possibly be subject to signature stripping.)=20 Then in your example, the attack is not possible within the cloud (i.e., if attacker strips the signatures for any prefix that originated=20 in that BGPsec cloud, his unsigned update is Invalid and not accepted; it would be the same as the attacker himself suppressing the update.) The wording I can suggest is:=20 BGPsec [RFC 8205] is computationally expensive and it is uncertain=20 when its adoption/deployment may happen. Just FYI=85 BGPsec is computationally expensive but there are optimization efforts that may be helpful (if BGPsec adoption ever gets going): http://www.freepatentsonline.com/y2019/0036943.html =20 (Juniper=92s BGPsec optimization patent) https://www.nanog.org/meetings/abstract?id=3D3043=20 =20 https://www.sciencedirect.com/science/article/pii/S0140366417303365 =20 >>Comment #2: Improvement of the algorithm for detection ---- snip ----- > This suggestion sounds great but it has an issue. Imagine that AS3 and AS= 4 > have what is commonly named 'complex' relation. So they are both > customer-provider to one another. And in your scenario, where only AS4 > creates ASPA it may result in rejection of valid routes, which will make > AS4 quite unhappy... Yes, agree. ASPA has a shortcoming nevertheless. >> Comment #3: --- snip --- > Fully agreed. Simplicity comes with its own cost. > And that's why we still need community-based leak detection that can work > per-prefix. And it's our duty as-coauthors (and my debt, which I need to > admit) to finally push it forward. > I'm going to add an explicit statement in the next version of the draft. Yes, the per-prefix solution (existing WG draft) is a necessary component. >> Comment #4: Not all malicious leaks / hijacks are detected >> >> In the topology below, AS2 leaks the path it learned from its peer AS4 t= o >> its provider AS3 with path modification to avoid route leak detection, >> or one may think of it as a hijack with feasible path insertion. >> In either case, the Update: p2 AS2 AS1 from AS2 to AS3 is >> illegitimate but defies detection despite all ASes participating in ASPA= . >> >> AS3 = AS5 >> \ p1 AS2 AS1 / >> \ p2 AS2 AS1 / >> \ / >> \ <----p2 AS4 AS1-- / >> AS2 -------p2p----------AS4 >> \ / >> \ p1 AS1 /p2 AS1 >> \ / >> AS1 >> (p1, p2) >> > Thinking about it as hijack adds simplicity to the picture. Customers may > still be hijacked by its direct or indirect providers. While it > significantly limits the attacker vector and highly unlikely to happen in > the real world, it must be clearly stated in the draft. Pushed to stack. It is both. Hard to rule out malicious leak with path modification. When considering malicious scenarios, the above would not be unlikely. I think this is typically what the determined attacker (AS2) might do to maliciously increase their revenue. =20 >> Comment #5: Path verification vs. path feasibility >> >> Based on the above examples, in the draft, perhaps it is better to say >> >> that the path is assessed feasible rather than say that the path is >> verified. >> > I'm not a native speaker but for me 'feasibility' sounds a bit odd. I > would be glad to learn other opinions from the wg members. Anyway, this > question should not become a showstopper. BGPsec provides hard assurance that path seen in the update is correct. ASPA can provide confirmation that the path is possible/feasible. It cannot assure that path seen in the update is the actual path that the update traversed. This is clear from the above example (Comm. #4). We can meet in Prague. I'll be happy to discuss=20 and we can try to help resolve these (to the extent possible).=20 Thanks. Sriram= From nobody Mon Mar 4 12:14:08 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 B3C69130E62 for ; Mon, 4 Mar 2019 12:14:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=kumari-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 T2oVT-mcnJW5 for ; Mon, 4 Mar 2019 12:14:04 -0800 (PST) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 AD07C128D0B for ; Mon, 4 Mar 2019 12:14:03 -0800 (PST) Received: by mail-wr1-x433.google.com with SMTP id d17so6966686wre.10 for ; Mon, 04 Mar 2019 12:14:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=khFBiuDv33zv+Sj4BV5gUWdQvWY7WZnoSJw2X09P8sM=; b=tQgxjqbJb5z12c4vMgCGLhzJze/E94uz3syYaiogW9uqSJ6tKOZm7KWoYlSrRilsqV UhiOig8Y1y4ssNAlbC6u0TQunqmjC5R/agFjRQOU3IxcpGBlAkCvBqUqiYBs48q18ynX ZB32/Nt5ycFZdtokUVTMrOmrkOpVft9WjyVP6+1G2oER/IbrRt4IOMgdr05aqW6oUuiC uAVTdbhWyWMiQHlPx/BEZl/mXN49ix4cViXZHCWHFo4a09lO8sQli9tLFjmeWaJkaNla vvz9YEIuN/OD/+cSzq7sP664W1IWTs9vind1UdxSRUj8/UNrHq165dGKtsOxmC8eOBYQ pTUw== 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=khFBiuDv33zv+Sj4BV5gUWdQvWY7WZnoSJw2X09P8sM=; b=nl7orVdZFMx+avOITTE0DNpQw8Ein86DbORJEU9PGQfmndYUwVtbh2WZXFYWPfzobW DsN4LO/fk9MuW2GOKKnhVQPmfWwLK8DfQKs1mOSMmD4v2sg+Ac5jHtQyRA2eZkBn7j9T cXTIj5ToJGvPi0+m9FtckcCYnRIJ7ctgSYLMVM30+WH/CL5AmjoLO/z4ow6Spg8MxC9a 7x9iD2yuq+TUHLUKuulstYiWVQP+N4TjyGnc/GMavqxChdle8NkTRdpZQbzw13rp8ONN 12Y2CwDNLW2bUysvyI4kXrXd3pWy1F8XILoUvzBqNfUBK/TbZj6k9weuM+UF34nhJjvN oiqg== X-Gm-Message-State: APjAAAV5DqgFI6bIMPCfZhRzEbJ9dkKjyrU9Y6WRtjbXjawDkISwxKzd e1gp70p+GryN5ZTDaceajlkl8F/TvQNXiaAb0b/45ezj0N4= X-Google-Smtp-Source: APXvYqxyUwUYZWvfbZqBr203D8xt11SGunBrIC4QYW5tm1Igot1r+Sqt3vTq+ZAT8UuoVBMsrkzLJq7ixIvEfH9KNho= X-Received: by 2002:a5d:4585:: with SMTP id p5mr14986146wrq.178.1551730441614; Mon, 04 Mar 2019 12:14:01 -0800 (PST) MIME-Version: 1.0 From: Warren Kumari Date: Mon, 4 Mar 2019 15:13:25 -0500 Message-ID: To: draft-ietf-sidrops-https-tal@ietf.org, SIDR Operations WG Content-Type: multipart/alternative; boundary="000000000000c2850805834a65d8" Archived-At: Subject: [Sidrops] AD Review of draft-ietf-sidrops-https-tal 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, 04 Mar 2019 20:14:07 -0000 --000000000000c2850805834a65d8 Content-Type: text/plain; charset="UTF-8" Hi there, Thank you for this document, it's a well written and easy to understand draft. I do have a few nits -- they are really minor, but if you address them now, it will minimize the chance of the document getting stuck later (once people start commenting on nits, they quickly grow to become larger issues :-)) 1: The document is missing an IANA Consideration section. Even though it doesn't ask for any IANA actions, it should state this -- see https://www.ietf.org/id-info/checklist#anchor4 (Basically, just add an IANA Considerations section and say: "This document has no actions for IANA." 2: This is still using the RFC2119 text. Can you please replace it with RFC 8174? Yes, these are both just annoying nits, but addressing them now will prevent issues later in the process... W -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --000000000000c2850805834a65d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi there,

Thank you for this document, it's a well written and eas= y to understand
draft. I do have a few nits -- they are really minor, but i= f you address them now, it will minimize the chance of the document getting= stuck later (once people start commenting on nits, they quickly grow to be= come larger issues :-))

1: The document is missing an IANA Considerati= on section.=C2=A0
Even though it doesn't ask for any IANA actions, it s= hould state this -- see=C2=A0https://www.ietf.org/id-info/checklist#anchor4

<= div class=3D"gmail_default" style=3D"font-family:verdana,sans-serif">(Basic= ally, just add an IANA Considerations section and say: "This document has no actions for IANA."

2: This is still using the RFC2119 text. Can you please replace i= t with RFC8174?
<= div class=3D"gmail_default">

<= /span>
Yes, these= are both just annoying nits, but addressing them now will prevent issues l= ater in the process...
<= br>
W
--
I don't think= the execution is relevant when it was obviously a bad idea in the first pl= ace.
This is like putting rabid weasels in your pants, and later express= ing regret at having chosen those particular rabid weasels and that pair of= pants.
=C2=A0 =C2=A0---maf
--000000000000c2850805834a65d8-- From nobody Mon Mar 4 12:17:42 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 8E0D0128D0B; Mon, 4 Mar 2019 12:17:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk CC: morrowc@ops-netman.net, draft-ietf-sidrops-bgpsec-algs-rfc8208-bis@ietf.org, sidrops@ietf.org, sidrops-chairs@ietf.org, Chris Morrow , warren@kumari.net Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Message-ID: <155173065454.5293.12378198225835356593.idtracker@ietfa.amsl.com> Date: Mon, 04 Mar 2019 12:17:34 -0800 Archived-At: Subject: [Sidrops] Last Call: (BGPsec Algorithms, Key Formats, and Signature Formats) to Proposed Standard 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, 04 Mar 2019 20:17:35 -0000 The IESG has received a request from the SIDR Operations WG (sidrops) to consider the following document: - 'BGPsec Algorithms, Key Formats, and Signature Formats' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-03-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies the algorithms, algorithm parameters, asymmetric key formats, asymmetric key sizes, and signature formats used in BGPsec (Border Gateway Protocol Security). This document updates RFC 8208 ("BGPsec Algorithms, Key Formats, and Signature Formats") by adding Special-Use Algorithm IDs and correcting the range of unassigned algorithms IDs to fill the complete range. This document also includes example BGPsec UPDATE messages as well as the private keys used to generate the messages and the certificates necessary to validate those signatures. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-sidrops-bgpsec-algs-rfc8208-bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-sidrops-bgpsec-algs-rfc8208-bis/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Mar 4 12:28: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 F236A12D4ED; Mon, 4 Mar 2019 12:28:17 -0800 (PST) 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.92.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <155173129794.5257.14817033443544230360@ietfa.amsl.com> Date: Mon, 04 Mar 2019 12:28:17 -0800 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-https-tal-07.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, 04 Mar 2019 20:28:18 -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 : Resource Public Key Infrastructure (RPKI) Trust Anchor Locator Authors : Geoff Huston Samuel Weiler George Michaelson Stephen Kent Tim Bruijnzeels Filename : draft-ietf-sidrops-https-tal-07.txt Pages : 11 Date : 2019-03-04 Abstract: This document defines a Trust Anchor Locator (TAL) for the Resource Public Key Infrastructure (RPKI). TALs allow Relying Parties in the RPKI to download the current Trust Anchor (TA) CA certificate from one or more locations, and verify that the key of this self-signed certificate matches the key on the TAL. Thus, Relying Parties can be configured with TA keys, but allow these TAs to change the content of their CA certificate. In particular it allows TAs to change the set of Internet Number Resources included in the RFC3779 extension of their certificate. This document obsoletes the previous definition of Trust Anchor Locators in RFC 7730 by adding support for HTTPS URIs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-https-tal/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-https-tal-07 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-https-tal-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-https-tal-07 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 Mar 4 12:30: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 8A0E1130F96 for ; Mon, 4 Mar 2019 12:30:52 -0800 (PST) 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_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 qz_OZIxPPrK1 for ; Mon, 4 Mar 2019 12:30:51 -0800 (PST) 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 DDA2E130F2A for ; Mon, 4 Mar 2019 12:30:49 -0800 (PST) Received: from [192.168.192.27] (dhcp-089-098-091-015.chello.nl [89.98.91.15]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id B2B5D2A733; Mon, 4 Mar 2019 21:30:47 +0100 (CET) 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=1551731447; bh=d+hwbck6xNgrumGivrUTD8uleCv7aYFzCWugC+hV+vA=; h=Subject:From:In-Reply-To:Date:References:To; b=qNms5I7RL4eaY2toemRtCLbG0XraLnqC88eCoREQE+lTX52FZ9fz+W7wt3/co9aMF RW3k3emVKQeqreQ2z3E7gS5vQLWc4LA/BJIM3s6tFoJw2EIjNOxcXSbbZit7uDq7O7 hAA7SEVxx69ouwj7DGYGTtzKd/hqE/y51wQYQPdM= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Tim Bruijnzeels In-Reply-To: <155173129794.5257.14817033443544230360@ietfa.amsl.com> Date: Mon, 4 Mar 2019 21:30:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <85897EED-175D-4FDF-A6C0-B62843C2519B@nlnetlabs.nl> References: <155173129794.5257.14817033443544230360@ietfa.amsl.com> To: SIDR Operations WG X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-https-tal-07.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, 04 Mar 2019 20:30:52 -0000 Hi all, This version addresses the nits pointed out by Warren Kumari. Thanks = Warren! Tim > On 4 Mar 2019, at 21:28, 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 : Resource Public Key Infrastructure (RPKI) = Trust Anchor Locator > Authors : Geoff Huston > Samuel Weiler > George Michaelson > Stephen Kent > Tim Bruijnzeels > Filename : draft-ietf-sidrops-https-tal-07.txt > Pages : 11 > Date : 2019-03-04 >=20 > Abstract: > This document defines a Trust Anchor Locator (TAL) for the Resource > Public Key Infrastructure (RPKI). TALs allow Relying Parties in the > RPKI to download the current Trust Anchor (TA) CA certificate from > one or more locations, and verify that the key of this self-signed > certificate matches the key on the TAL. Thus, Relying Parties can = be > configured with TA keys, but allow these TAs to change the content = of > their CA certificate. In particular it allows TAs to change the set > of Internet Number Resources included in the RFC3779 extension of > their certificate. >=20 > This document obsoletes the previous definition of Trust Anchor > Locators in RFC 7730 by adding support for HTTPS URIs. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidrops-https-tal/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-sidrops-https-tal-07 > https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-https-tal-07 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidrops-https-tal-07 >=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 Mar 4 12:46: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 2BD04130DEF for ; Mon, 4 Mar 2019 12:46:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 (2048-bit key) header.d=kumari-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 fNU-MXUFJjNi for ; Mon, 4 Mar 2019 12:46:35 -0800 (PST) Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) (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 61D331294FA for ; Mon, 4 Mar 2019 12:46:35 -0800 (PST) Received: by mail-wr1-x444.google.com with SMTP id o17so7067628wrw.3 for ; Mon, 04 Mar 2019 12:46:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ltzrXnEbNjgWlNUQgjNA+3vxpsjsylwiYpEgFdZiBqk=; b=cFOKWrF5jh4l+62SEd9E8fzet7yBIWoAOPDF5E2tqfAmM2Gbq4fKL3s2DpwCGnPkEv EhepSkAOBhioGb77f55rZCo7n8TO8HDEEn6Kr87fSIMUmV80v7JZ23HOvIecP8NJBmok u2Rxv5Y3wpaBnuOgdvPa2xXMaWTzKbluFFyngNgXEjaOhihSZgJdq/hU4fRcuapmp+wt o7/HxQoC1OGSq63kQWi0vmHLkoZWG2VP1j2dDifnk9gvtzzBlWxFJCfZgSwn+n/uWpBQ yIuqu554qDCVhwownO23h+DYvGTnq/NrCqut37UE5qxhdBR4Hm4n2zJROecfK0mvL7S1 mNpw== 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=ltzrXnEbNjgWlNUQgjNA+3vxpsjsylwiYpEgFdZiBqk=; b=nQ93z2AXp65wmxLhU6j2eei5UN0OnjZAgHR/ZsoJNrIWQvtWKbHhBD0sh9JNCX6/EJ sS+RMgyvpuZg8e25H07ZG8lqiEmGbm+PEkSwE2WGvQO0relgkpOLmQ4fj92nJv9+1/z1 MjlLTyIato0bHTY+DmcsuM1TifIfkee3vuyvxsQhgt5PpuRT46qXFxNgiOYyQZl4++iS GdDIDMLJWiCednySSp4eFB7Hi/2aorJnCRISuwSSDbgjYtGr3sIsPR42OMRxVsLPkbHL rx036jAF4veDGPk8F11zpg3oTRI3OSl7bFpjHw5MbAyg7H1l6DEFXU7txxqlCi1ws52z Z9Lw== X-Gm-Message-State: APjAAAXSFt7xHmHKQDq0cJ4i/dM8IhGF9e9NrKc5vWzQ+SKJz1tngoLc /0NL1fqojiTkutjTMZ9V3SYakywZsWlWSQS61eOPrw== X-Google-Smtp-Source: APXvYqwoihmkfLe2DI/TL2PE2KL61rxsbpbLpF4eXR6A3ShwJEuQ/CEsfafzz0KDf+3XaVm4KbzSR0DAiwtQ3qeQuV4= X-Received: by 2002:adf:8061:: with SMTP id 88mr13314832wrk.77.1551732393464; Mon, 04 Mar 2019 12:46:33 -0800 (PST) MIME-Version: 1.0 References: <155173129794.5257.14817033443544230360@ietfa.amsl.com> <85897EED-175D-4FDF-A6C0-B62843C2519B@nlnetlabs.nl> In-Reply-To: <85897EED-175D-4FDF-A6C0-B62843C2519B@nlnetlabs.nl> From: Warren Kumari Date: Mon, 4 Mar 2019 15:45:56 -0500 Message-ID: To: Tim Bruijnzeels Cc: SIDR Operations WG Content-Type: multipart/alternative; boundary="000000000000196a2f05834adadd" Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-https-tal-07.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, 04 Mar 2019 20:46:39 -0000 --000000000000196a2f05834adadd Content-Type: text/plain; charset="UTF-8" On Mon, Mar 4, 2019 at 3:30 PM Tim Bruijnzeels wrote: > Hi all, > > This version addresses the nits pointed out by Warren Kumari. Thanks > Warren! > Nah, thanks for a: doing it, and b: not minding that it is busy-work. IETF LC started. W > > Tim > > > On 4 Mar 2019, at 21:28, internet-drafts@ietf.org wrote: > > > > > > 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 : Resource Public Key Infrastructure (RPKI) Trust > Anchor Locator > > Authors : Geoff Huston > > Samuel Weiler > > George Michaelson > > Stephen Kent > > Tim Bruijnzeels > > Filename : draft-ietf-sidrops-https-tal-07.txt > > Pages : 11 > > Date : 2019-03-04 > > > > Abstract: > > This document defines a Trust Anchor Locator (TAL) for the Resource > > Public Key Infrastructure (RPKI). TALs allow Relying Parties in the > > RPKI to download the current Trust Anchor (TA) CA certificate from > > one or more locations, and verify that the key of this self-signed > > certificate matches the key on the TAL. Thus, Relying Parties can be > > configured with TA keys, but allow these TAs to change the content of > > their CA certificate. In particular it allows TAs to change the set > > of Internet Number Resources included in the RFC3779 extension of > > their certificate. > > > > This document obsoletes the previous definition of Trust Anchor > > Locators in RFC 7730 by adding support for HTTPS URIs. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-sidrops-https-tal/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-sidrops-https-tal-07 > > https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-https-tal-07 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-https-tal-07 > > > > > > 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 > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --000000000000196a2f05834adadd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Mar 4, 2019 at 3:30 PM Tim B= ruijnzeels <tim@nlnetlabs.nl>= wrote:
Hi all,<= br>
This version addresses the nits pointed out by Warren Kumari. Thanks Warren= !

Nah, thanks for a: doing it, and b: not mi= nding that it is busy-work.

IETF LC started.
W

=C2= =A0

Tim

> On 4 Mar 2019, at 21:28, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> 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: Resource Public Key Infrastructure (RPKI) Trust Anchor Locator
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: = Geoff Huston
>=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 Samuel Weiler
>=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 George Michaelson
>=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 Stephen Kent
>=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 Tim Bruijnzeels
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-sidrops-https-tal-07.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 11
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2019-03-04
>
> Abstract:
>=C2=A0 =C2=A0This document defines a Trust Anchor Locator (TAL) for the= Resource
>=C2=A0 =C2=A0Public Key Infrastructure (RPKI).=C2=A0 TALs allow Relying= Parties in the
>=C2=A0 =C2=A0RPKI to download the current Trust Anchor (TA) CA certific= ate from
>=C2=A0 =C2=A0one or more locations, and verify that the key of this sel= f-signed
>=C2=A0 =C2=A0certificate matches the key on the TAL.=C2=A0 Thus, Relyin= g Parties can be
>=C2=A0 =C2=A0configured with TA keys, but allow these TAs to change the= content of
>=C2=A0 =C2=A0their CA certificate.=C2=A0 In particular it allows TAs to= change the set
>=C2=A0 =C2=A0of Internet Number Resources included in the RFC3779 exten= sion of
>=C2=A0 =C2=A0their certificate.
>
>=C2=A0 =C2=A0This document obsoletes the previous definition of Trust A= nchor
>=C2=A0 =C2=A0Locators in RFC 7730 by adding support for HTTPS URIs.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/= draft-ietf-sidrops-https-tal/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ie= tf-sidrops-https-tal-07
> https://datatracker.ietf.o= rg/doc/html/draft-ietf-sidrops-https-tal-07
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff= ?url2=3Ddraft-ietf-sidrops-https-tal-07
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> 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<= br>
_______________________________________________
Sidrops mailing list
Sidrops@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sidrops


--
I don't think the execution is relevant when= it was obviously a bad idea in the first place.
This is like putting ra= bid weasels in your pants, and later expressing regret at having chosen tho= se particular rabid weasels and that pair of pants.
=C2=A0 =C2=A0---maf<= /div>
--000000000000196a2f05834adadd-- From nobody Mon Mar 4 12:53:53 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 475CB12D4ED; Mon, 4 Mar 2019 12:53:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk CC: morrowc@ops-netman.net, sidrops@ietf.org, sidrops-chairs@ietf.org, Chris Morrow , draft-ietf-sidrops-https-tal@ietf.org, warren@kumari.net Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Message-ID: <155173282523.5114.18298777805376987899.idtracker@ietfa.amsl.com> Date: Mon, 04 Mar 2019 12:53:45 -0800 Archived-At: Subject: [Sidrops] Last Call: (Resource Public Key Infrastructure (RPKI) Trust Anchor Locator) to Proposed Standard 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, 04 Mar 2019 20:53:45 -0000 The IESG has received a request from the SIDR Operations WG (sidrops) to consider the following document: - 'Resource Public Key Infrastructure (RPKI) Trust Anchor Locator' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-03-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a Trust Anchor Locator (TAL) for the Resource Public Key Infrastructure (RPKI). TALs allow Relying Parties in the RPKI to download the current Trust Anchor (TA) CA certificate from one or more locations, and verify that the key of this self-signed certificate matches the key on the TAL. Thus, Relying Parties can be configured with TA keys, but allow these TAs to change the content of their CA certificate. In particular it allows TAs to change the set of Internet Number Resources included in the RFC3779 extension of their certificate. This document obsoletes the previous definition of Trust Anchor Locators in RFC 7730 by adding support for HTTPS URIs. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-sidrops-https-tal/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-sidrops-https-tal/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Mar 5 06:22:06 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 00A4F126C7E; Tue, 5 Mar 2019 06:22:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-sidrops-rtr-keying@ietf.org, Chris Morrow , sidrops-chairs@ietf.org, morrowc@ops-netman.net, sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155179571999.24615.8922799654551036309.idtracker@ietfa.amsl.com> Date: Tue, 05 Mar 2019 06:21:59 -0800 Archived-At: Subject: [Sidrops] Alissa Cooper's No Objection on draft-ietf-sidrops-rtr-keying-04: (with COMMENT) 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, 05 Mar 2019 14:22:00 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-sidrops-rtr-keying-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my DISCUSS and COMMENT. From nobody Tue Mar 5 09:38: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 ACF8D1312D0; Tue, 5 Mar 2019 09:38:13 -0800 (PST) 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_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 7B1p1VwWHXhf; Tue, 5 Mar 2019 09:38:10 -0800 (PST) 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 6C8EE131055; Tue, 5 Mar 2019 09:38:07 -0800 (PST) Received: by mail-ot1-x329.google.com with SMTP id b3so8147576otp.4; Tue, 05 Mar 2019 09:38:07 -0800 (PST) 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=CQLoyE2L5G3276wWi/JZH/4GE2rsMiH6D/cIZxa0+xo=; b=PkkX9sg0aZ9OqA8AFKlOLCursumpCmT3ec3tqwF1JkHfqvd/1oMltNZxTrOc7u8v7f 5duAN11khP1awdOml+mM5+3kpvMsauMjem1O1NvbO1ocZzx+qqCde7H795+gsn0meJU6 xVLKnEVMGqlTF+v7NUKiqxJvWiLnbb9SuPbMGZfafiU1HI282f2b5Q7oG2CUctD/UhCi Y1vVqKRRaIXALR8/q7yVyhfnYeMnALxiHgwJdxyek1ajwMzJ1fmHhNPSMp70+l1M8Ags +Co8CkvRmRHCcbbMlLlOzXAjDXw2Msx8yN4ve7eN34lf9BP1e38YPm8CyPaf/2cPntoy ICYA== 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=CQLoyE2L5G3276wWi/JZH/4GE2rsMiH6D/cIZxa0+xo=; b=koQE5eLCdSHzzeGYwC1UNSyN/jHI1iMbC9I9PQkj7iz7+DLWdLu4I4mRaL/pX18vTP 2Om1tCT/50Vk4NRtwDdwLjNptbWAewGMhL3OsihQI4XOsJsYdXehU3llSgr2AYSSw5x/ 6VVN6tI/EahzqGnHEhHaF6W6sNpfhsLyxPPoi5ooNDDok81VZN6DgfqzrFIlUFxQ+mPV kRYrKE0GXsNVXUudY6F5v0z0xI5KL8lfTxo48lW3p3CODWmFbmIde4VRUqhbzzGqT2Lv 07ZCvganjoyZ3L3wUs/4GgfDs3gc1eqH6o0QWqZNGn84BfWi3xjI2VnpMb1fgKfOicBG QYzw== X-Gm-Message-State: APjAAAX7RAaLzJoXbb+HyV6K6iHwaT7XWRdZLJINHxZ3cNLpc61x6B82 G8W00kaYwokXVr1ZoIm508W/7DC0d4BBPSOxW+k= X-Google-Smtp-Source: APXvYqyMZXlElZ4KFQhDn8K0vkezynQspk0qZXE2bW7kK+Cl4Dss2m6nAzhp7/ixQqYZ3FLIs0jANvsqfJ6x4HpeNCo= X-Received: by 2002:a9d:3f24:: with SMTP id m33mr1557398otc.147.1551807486421; Tue, 05 Mar 2019 09:38:06 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Alexander Azimov Date: Tue, 5 Mar 2019 20:37:54 +0300 Message-ID: To: "Sriram, Kotikalapudi (Fed)" Cc: "sidrops-chairs@ietf.org" , "sidrops@ietf.org" Content-Type: multipart/alternative; boundary="000000000000fcf48605835c5518" Archived-At: Subject: Re: [Sidrops] WG Adoption call draft-azimov-sidrops-aspa-verification 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, 05 Mar 2019 17:38:19 -0000 --000000000000fcf48605835c5518 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Sriram, Please see my inline comments. =D0=B2=D1=81, 3 =D0=BC=D0=B0=D1=80. 2019 =D0=B3. =D0=B2 04:36, Sriram, Koti= kalapudi (Fed) < kotikalapudi.sriram@nist.gov>: > Hi Alex, > > So, yes there are things we need to careful about in the design. > Also, got to be careful about claiming, =E2=80=9Cthis mechanism > guarantees detection of both malicious and accidental route leaks=E2=80= =9D. > > There is a new Comment #0 that I have added here. > And I have other comments inline below. > > Comment#0: > One more thing occurred to me. This is very basic. > Consider these frequently occurring examples of route leaks: > > AS1 (Tier 1)----P2C---->AS2 (customer)----C2P-----> AS3 > AS1 (Tier 1)----p2p---->AS2 (Tier 1)----p2p-----> AS3 (Tier 1) > > AS2 leaks the route learned from AS1 in both cases above. > AS1 being a Tier 1, never has to create an ASPA (has no providers). > Regardless of whether AS2 created an ASPA or not, > AS3 is not able to detect the leaks in both cases above > (per algorithm in the draft). > This same issue arises even in the example of Comment #2 > if AS3 in that example were a Tier 1. > You seem to be misreading in section 6. Quote: An ASPA with a provider AS of 0 is a statement by the customer AS that the its routes should not be received by any relying party AS from any of its customers or peers. So, Tier1/IXes should create only ASPA0 - and it will be enough to detect anomalies with its prefixes by any other ISP in the world. >Can you please clarify to me next scenario with three ISPs: > > - Victim advertises /23 to Upstream, does use BGPSec, > > has ROA record with maxlength 24 > > - Upstream, does use BGPSec > > - Attacker, advertises /24 that belongs to Victim, adds its ASN at > > the beginning of ASPath, doesn't use BGPSec > >Will Upstream, according to RFC8205, accept the hijacked route from > Attacker? > >Anyway, I'm open for discussion about proper wording here. > > The idea of a BGPsec cloud (some call it island) needs to be understood. > I hope you had chance to read RFC 8205 Section 7.9 =E2=80=93 > the idea of contiguous BGPsec ASes. > A group of contiguous BGPsec ASes decides that they > require signed updates (i.e., BGPsec) from Day X *within their cloud*. > What that means is that they have knowledge that they are > contiguous (all connected to each other by some # of hops), > and they all do BGPsec. And they decide that BGPsec must be done > end-to-end within their BGPsec cloud. > Then from Day X, they require signed/valid paths for prefixes > that *originate within their BGPsec cloud*. > (Prefixes originated from outside the cloud may be unsigned > and may possibly be subject to signature stripping.) > Then in your example, the attack is not possible within the cloud > (i.e., if attacker strips the signatures for any prefix that originated > in that BGPsec cloud, his unsigned update is Invalid and not accepted; > it would be the same as the attacker himself suppressing the update.) > I've read 7.9 section multiple times, and there wasn't able to find anything related to 'clouds' or conditional acceptance of unsigned routes if there are signed less specifics. May be you would like to write another document that will clearly describe this procedure? >>Comment #2: Improvement of the algorithm for detection > ---- snip ----- > > > This suggestion sounds great but it has an issue. Imagine that AS3 and > AS4 > > have what is commonly named 'complex' relation. So they are both > > customer-provider to one another. And in your scenario, where only AS4 > > creates ASPA it may result in rejection of valid routes, which will mak= e > > AS4 quite unhappy... > > Yes, agree. ASPA has a shortcoming nevertheless. > You have suggested an improvement and I explained why it is not applicable. I've never heard that careful design is a shortcoming. > >> Comment #4: Not all malicious leaks / hijacks are detected > >> > >> In the topology below, AS2 leaks the path it learned from its peer AS4 > to > >> its provider AS3 with path modification to avoid route leak detection, > >> or one may think of it as a hijack with feasible path insertion. > >> In either case, the Update: p2 AS2 AS1 from AS2 to AS3 is > >> illegitimate but defies detection despite all ASes participating in > ASPA. > >> > >> AS3 > AS5 > >> \ p1 AS2 AS1 / > >> \ p2 AS2 AS1 / > >> \ / > >> \ <----p2 AS4 AS1-- / > >> AS2 -------p2p----------AS4 > >> \ / > >> \ p1 AS1 /p2 AS1 > >> \ / > >> AS1 > >> (p1, p2) > >> > > > Thinking about it as hijack adds simplicity to the picture. Customers m= ay > > still be hijacked by its direct or indirect providers. While it > > significantly limits the attacker vector and highly unlikely to happen = in > > the real world, it must be clearly stated in the draft. Pushed to stack= . > > It is both. Hard to rule out malicious leak with path modification. > When considering malicious scenarios, the above would not be unlikely. > I think this is typically what the determined attacker (AS2) might do to > maliciously increase their revenue. Do you think that malicious attack from the provider, that has contracted agreement with its customer (and already propagates customer's prefixes) is likely to happen? >From what I know from real hijack issues - it's not. > >> Comment #5: Path verification vs. path feasibility > >> > >> Based on the above examples, in the draft, perhaps it is better to say > >> > >> that the path is assessed feasible rather than say that the path is > >> verified. > >> > > > I'm not a native speaker but for me 'feasibility' sounds a bit odd. I > > would be glad to learn other opinions from the wg members. Anyway, this > > question should not become a showstopper. > > BGPsec provides hard assurance that path seen in the update is correct. > ASPA can provide confirmation that the path is possible/feasible. > It cannot assure that path seen in the update is the actual path > that the update traversed. This is clear from the above example (Comm. #4= ). > > We can meet in Prague. I'll be happy to discuss > and we can try to help resolve these (to the extent possible). > Arguing about BGPSec isn't my goal at this point in time, nor it is the purpose of the draft. I can't say you convinced me about naming, but as you know, I'm always open to constructive discussions. --=20 Best regards, Alexander Azimov --000000000000fcf48605835c5518 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Sriram,

Pleas= e see my inline comments.

=D0=B2=D1=81, 3 =D0=BC=D0=B0=D1=80. 2019= =D0=B3. =D0=B2 04:36, Sriram, Kotikalapudi (Fed) <kotikalapudi.sriram@nist.gov>:
<= 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">Hi Alex,

So, yes there are things we need to careful about in the design.
Also, got to be careful about claiming, =E2=80=9Cthis mechanism
guarantees detection of both malicious and accidental route leaks=E2=80=9D.=

There is a new Comment #0 that I have added here.
And I have other comments inline below.

Comment#0:
One more thing occurred to me. This is very basic.
Consider these frequently occurring examples of route leaks:

AS1 (Tier 1)----P2C---->AS2 (customer)----C2P-----> AS3
AS1 (Tier 1)----p2p---->AS2 (Tier 1)----p2p-----> AS3 (Tier 1)

AS2 leaks the route learned from AS1 in both cases above.
AS1 being a Tier 1, never has to create an ASPA (has no providers).=C2=A0 <= br> Regardless of whether AS2 created an ASPA or not,
AS3 is not able to detect the leaks in both cases above
(per algorithm in the draft).
This same issue arises even in the example of Comment #2
if AS3 in that example were a Tier 1.
You seem to be m= isreading in section 6. Quote:
   An ASPA with a provider AS of 0 is a statem=
ent by the customer AS
   that the its routes should not be received by any relying party AS
   from any of its customers or peers.
So, Tier1/IXes should create only ASPA0 - and it will be enough = to detect anomalies with its prefixes by any other ISP in the world.

>Can= you please clarify to me next scenario with three ISPs:
> - Victim advertises /23 to Upstream, does use BGPSec,
>=C2=A0 =C2=A0 has ROA record with maxlength 24
> - Upstream, does use BGPSec
> - Attacker, advertises /24 that belongs to Victim, adds its ASN at >=C2=A0 =C2=A0 the beginning of ASPath, doesn't use BGPSec
>Will Upstream, according to RFC8205, accept the hijacked route from Att= acker?
>Anyway, I'm open for discussion about proper wording here.

The idea of a BGPsec cloud (some call it island) needs to be understood. I hope you had chance to read RFC 8205 Section 7.9 =E2=80=93
the idea of contiguous BGPsec ASes.
A group of contiguous BGPsec ASes decides that they
require signed updates (i.e., BGPsec) from Day X *within their cloud*.
What that means is that they have knowledge that they are
contiguous (all connected to each other by some # of hops),
and they all do BGPsec. And they decide that BGPsec must be done
end-to-end within their BGPsec cloud.
Then from Day X, they require signed/valid paths for prefixes
that *originate within their BGPsec cloud*.
(Prefixes originated from outside the cloud may be unsigned
and may possibly be subject to signature stripping.)
Then in your example, the attack is not possible within the cloud
(i.e., if attacker strips the signatures for any prefix that originated in that BGPsec cloud, his unsigned update is Invalid and not accepted;
it would be the same as the attacker himself suppressing the update.)
I've read 7.9 section multiple times, and there wasn't a= ble to find anything related to 'clouds' or conditional acceptance = of unsigned routes if there are signed less specifics.
May be you would = like to write another document that will clearly describe this procedure?

=C2=A0 >>Comment #2: Improvement of the algorithm for detection
---- snip -----

> This suggestion sounds great but it has an issue. Imagine that AS3 and= AS4
> have what is commonly named 'complex' relation. So they are bo= th
> customer-provider to one another. And in your scenario, where only AS4=
> creates ASPA it may result in rejection of valid routes, which will ma= ke
> AS4 quite unhappy...

Yes, agree. ASPA has a shortcoming nevertheless.
You h= ave suggested an improvement and I explained why it is not applicable. I= 9;ve never heard that careful design is a shortcoming.
=C2=A0=
>> Commen= t #4: Not all malicious leaks / hijacks are detected
>>
>> In the topology below, AS2 leaks the path it learned from its peer= AS4 to
>> its provider AS3 with path modification to avoid route leak detect= ion,
>> or one may think of it as a hijack with feasible path insertion. >> In either case, the Update: p2 AS2 AS1 from AS2 to AS3 is
>> illegitimate but defies detection despite all ASes participating i= n ASPA.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 AS3=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 =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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 AS5
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\=C2=A0 p1 A= S2 AS1=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 =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 =C2=A0 =C2=A0\ p2 = AS2 AS1=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 =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 =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 =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/
>>=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 =C2=A0 =C2=A0 =C2=A0<----p2 AS4 AS1--=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 =C2=A0 AS2 -------p2p----------AS4
>>=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 =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 =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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 \ p1 AS1=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0/p2 AS1
>>=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 =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/
>>=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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0AS= 1
>>=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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (p1, p2)
>>

> Thinking about it as hijack adds simplicity to the picture. Customers = may
> still be hijacked by its direct or indirect providers. While it
> significantly limits the attacker vector and highly unlikely to happen= in
> the real world, it must be clearly stated in the draft. Pushed to stac= k.

It is both. Hard to rule out malicious leak with path modification.
When considering malicious scenarios, the above would not be unlikely.
I think this is typically what the determined attacker (AS2) might do to maliciously increase their revenue.
Do you think that malicious= attack from the provider, that has contracted agreement with its customer = (and already propagates customer's prefixes) is likely to happen?
From what I know from real hijack issues - i= t's not.
=C2=A0
>> Comment #5: Path verification vs. path feasibility
>>
>> Based on the above examples, in the draft, perhaps it is better to= say
>>
>> that the path is assessed feasible rather than say that the path i= s
>> verified.
>>

> I'm not a native speaker but for me 'feasibility' sounds a= bit odd. I
> would be glad to learn other opinions from the wg members. Anyway, thi= s
> question should not become a showstopper.

BGPsec provides hard assurance that path seen in the update is correct.
ASPA can provide confirmation that the path is possible/feasible.
It cannot assure that path seen in the update is the actual path
that the update traversed. This is clear from the above example (Comm. #4).=

We can meet in Prague. I'll be happy to discuss
and we can try to help resolve these (to the extent possible).
Arguing about BGPSec isn't my goal at this point in time, nor it i= s the purpose of the draft.
I can't say you convinced me about namin= g, but as you know, I'm always open to constructive discussions.
--
Best regards,
Alexander Azimov
--000000000000fcf48605835c5518-- From nobody Tue Mar 5 16:28:03 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 1A8F1131127; Tue, 5 Mar 2019 16:27:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 0Zl8xEnNbHZh; Tue, 5 Mar 2019 16:27:52 -0800 (PST) Received: from GCC01-CY1-obe.outbound.protection.outlook.com (mail-eopbgr830138.outbound.protection.outlook.com [40.107.83.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B86D13113A; Tue, 5 Mar 2019 16:27:52 -0800 (PST) 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=OqFYdY4fvNckLuVjKwilnBY/NnV8HiIFBJU2zmSiZDw=; b=1NGMXLXbDOD7GR3fr5xZbn9yAHcpFRc2akamE05Rf3gGb8T/1UvB/ryNsM3/7Njp8SGflRO/jPMVQ87MgM4WinBtpvT41toM3m7SILMqTYbSGXb39X3/aTBEKTibhQ3/VAk9AKT3pAjsuZSobFWz1cq50ALrRn3GZh3HzUYjV9w= Received: from SN6PR0901MB2366.namprd09.prod.outlook.com (52.132.115.159) by SN6PR0901MB2365.namprd09.prod.outlook.com (52.132.115.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.16; Wed, 6 Mar 2019 00:27:49 +0000 Received: from SN6PR0901MB2366.namprd09.prod.outlook.com ([fe80::5c3a:f8a5:80dd:2d85]) by SN6PR0901MB2366.namprd09.prod.outlook.com ([fe80::5c3a:f8a5:80dd:2d85%5]) with mapi id 15.20.1665.020; Wed, 6 Mar 2019 00:27:49 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Alexander Azimov CC: "sidrops-chairs@ietf.org" , "sidrops@ietf.org" Thread-Topic: [Sidrops] WG Adoption call draft-azimov-sidrops-aspa-verification Thread-Index: AQHUz46GzEO4+XNrd0q8gcAsK5oxyqX2kuYAgAKHMLCABDsgAIAAbffw Date: Wed, 6 Mar 2019 00:27:49 +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: 75c859e2-a696-4574-991e-08d6a1ca9063 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:SN6PR0901MB2365; x-ms-traffictypediagnostic: SN6PR0901MB2365: x-microsoft-exchange-diagnostics: =?utf-8?B?MTtTTjZQUjA5MDFNQjIzNjU7MjM6THpSNXBmVDdSS1NyRVRBVDZ2WENCcnRR?= =?utf-8?B?alFwaTI5Sjl5bWlkWWs5a1FGaFVmaGk2QjAyUUhaTzVvRFR1SHhHT0dWd0px?= =?utf-8?B?NjA0aHFaL2dhbndMVnByR0x4RFhNOUdoOUlPbUduTjNocXd2bk1ST3VhZTc4?= =?utf-8?B?c0QvcWN0V3Z3Z24valRJRk55Sk1DSFV1Z2xuSnBHbm9sMk9iZGN2ZTVsWEZo?= =?utf-8?B?dXVXekVCaGUwNVc5OVo5WHkzQjFXRE1kM2ZLcjF2aFFyeVJaVFB4Y0lkL0dn?= =?utf-8?B?RGo2NEppU0tpWmxLcW9lekljQjV6WFpMNno4a3I4NTFXS3pzTm5uVVB2Ynpr?= =?utf-8?B?eHkwdHphK2ZpZGppZFRhK1pWSVFoRFdxSmR0NUlKeW9obTViY1dwSi9qVTVq?= =?utf-8?B?bGxxQ1UrNGRkTVgzaFlLdDYraitOb21ERjFnZkJwOEo4ODl1aXovV1RIdWk4?= =?utf-8?B?VXI5YnZRQVF3QVZJSGZWV2xqL1RlTkJMalFWczI3NTU0dTd6SGoxbVgzY2xR?= =?utf-8?B?bmZzTlpZUHI0R0ZLalRrUTJ3Nkd5c2ZGNnN2WVBWQ2ZDN2lsRm1hbGNmUG1o?= =?utf-8?B?NVlIV0xCMnpaelpmcWIwMVMvU0IxZHIxdU9BT2p4R2R5V0RrdEc3QTdHT0Fy?= =?utf-8?B?enh5eVlYRTNrMzluUjhvc2N3VjlSZjkxYUlCSzZGeXUybllSN2JpK2hGM3dD?= =?utf-8?B?enkwenR3OXVRWTlKTTgwZkRQbU9HZzFCMVUvd2RKbC80Y0VRdG5iUFBpYWQ5?= =?utf-8?B?dWVGSGpxR0RDaktPUTlyclNVNCsrQWZUSGNtK0l1OXVzY0tMLzRVOG52SjJE?= =?utf-8?B?UVVwelpUdllFOUlqUVJ5SjVrbzI3R2RFNkpjMXhOc09HSDlZOHh3YndCdFNv?= =?utf-8?B?WEZuZk1CbHRHUDY4WjZVVkhFVkNoY3dxekdKSHpEWjg1UFVid3RHc1lKV0to?= =?utf-8?B?VkJBS2JpdlRwMi8yYWNDY3RpYURrdnAyV25PTjhMeU5zb0d2dDVwK1ZQYUM5?= =?utf-8?B?aVB3dVpKbWMySWozSmppU21rcVpBSzNTdW9YeXgrZ2RDSENKSU1wU2JCTGtD?= =?utf-8?B?dnZPM1Y5dHpBM3U4b1V5bmMzNEw0QVJvYk1acm0rZzlCa2pYREtlKzJIamxh?= =?utf-8?B?aE05c2luRDFQVkRSSzVWTTQ0WFVvckZqOU1LNFFXcUY1aU5uWndUTGFiMExw?= =?utf-8?B?QmpTOENzamMxbE1kb1ZuV1FYRFlYdk5KZ1lLbEZIRzIwWVVUcnFWZ0ZURG50?= =?utf-8?B?emt1ZFhZbzFWWW5zN1VEN0Jzc1hBb3F6dlA4cHl6Q0orakt5ajQ0NDVOSFpG?= =?utf-8?B?QytDWm5icHc2S0FaM01IcjMzQk0yMWMzNWF0aXNwbm5rWE1mMG8xUVU5R214?= =?utf-8?B?OHBVeGhBTHMrdTRtSjVycHFzcVRQN2RPcnRta3EvQjlEand0VjdjTDZhYlZU?= =?utf-8?B?bFA3WitXMUJselE4NTlsNmhwdWVIaGZSYU1HczMrL09IQXpkVzZPTFhlbmlO?= =?utf-8?B?NDZFVE1wVGQ2Sk1vZ1dHL3lZY1pBcWRFUXcxQkZLc1lDNEh0aytYRWNyYkpE?= =?utf-8?B?Vnk1OHVuZG51Tlk2bVJFOFFOUjNJMmRmUmdXWGpqN2VrUW1xU2pRNWplaGhm?= =?utf-8?B?SnFUUFc3blU0SjAvQWlna3JidUV6QUVWd1JaSXdmTjREUXRWQi8zbWR6enNk?= =?utf-8?B?YlVCNExzL3FZUjdSd2hMRzdtSW5zVUY1c1Q4Mkhrd25wWVBJM1RPM0NucWRz?= =?utf-8?B?ZWsxNVY1MWdDWGRpRXFKNTlOWFhGNlNsSWZOY21XR29MbmdLcUNmeTJYTVB6?= =?utf-8?B?aXlMdm9pTktRbWE5bC9NQzY2cFFJdjhpL05SQnF4K3paWVgybnFnTlNNRFBu?= =?utf-8?B?OE1ZekcxQ3hoZVNWYXQ4NlJMdGhQaDZXa3NzWDNHVUwyem00RHRXMGNOVlU5?= =?utf-8?Q?hvp/tCRcHwk2xP7AzzcQK3tctAFMJQjc=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 0968D37274 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(136003)(376002)(39860400002)(346002)(396003)(52314003)(189003)(199004)(81156014)(81166006)(446003)(15650500001)(93886005)(14454004)(10710500007)(790700001)(3846002)(6246003)(2906002)(106356001)(11346002)(478600001)(86362001)(2420400007)(4326008)(256004)(99286004)(14444005)(6116002)(486006)(105586002)(476003)(9686003)(68736007)(229853002)(53546011)(236005)(7736002)(76176011)(25786009)(54896002)(186003)(6506007)(55016002)(26005)(6306002)(6916009)(71200400001)(52536013)(6436002)(8936002)(97736004)(71190400001)(316002)(66066001)(53936002)(54906003)(74316002)(8676002)(102836004)(33656002)(5660300002)(7696005); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR0901MB2365; H:SN6PR0901MB2366.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: et7GRnwGHfIJhifPVqe+2uWBNhlL13T6xIhBxv+WYibCVmJQOC4KuTSa/ypsjJdrYk4ihSS4gOQz9MKCmHMZ5qEfKBlF7cxglAAZduPqdwHLo5Zhdp+2QXfszgURHY1RevRRaT12n9LnGXF/howL2dQq+WQSqlBz8uz2cLTNjSC2oomKrU0azvaDSdVrq6/ctjX43gvjRVksAO0pgh56b3VggN+D4eAx+vcFTU4iJ/26J7+VtdKWPOq0AELiBEIoVY2rcX4nOX1iT8xivLYJkzgy6UgS/ZQZYlcQIP/wZfsBw+hFHLqejzHSpHPVRdVFLJM8vBTsMChHSLK/y2Hm28+acsFS1JPcG9hlQTTNb1DgUmqwP6WAz2lcteAmoZ4OqdfxDyNU/JBgLCvdVeRqPfQw9huH+GdxxxtLKYmSV10= Content-Type: multipart/alternative; boundary="_000_SN6PR0901MB2366EEEA3E1B00695EBF81EF84730SN6PR0901MB2366_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 75c859e2-a696-4574-991e-08d6a1ca9063 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2019 00:27:49.5734 (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-Transport-CrossTenantHeadersStamped: SN6PR0901MB2365 Archived-At: Subject: Re: [Sidrops] WG Adoption call draft-azimov-sidrops-aspa-verification 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, 06 Mar 2019 00:28:01 -0000 --_000_SN6PR0901MB2366EEEA3E1B00695EBF81EF84730SN6PR0901MB2366_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SG9ub3JhYmxlIENoYWlyczogWW91IG1heSBjb3VudCBtZSBpbiBhcyDigJhzdXBwb3J04oCZLg0K DQpIaSBBbGV4LA0KDQpUaGFua3MgZm9yIGNsYXJpZnlpbmcgQVNQQTAgdXNlIGZvciBUaWVyMS4g SSBvdmVybG9va2VkIGJlZm9yZS4gSSBhbSBnb29kIG5vdy4NCg0KRm9yIHRoZSBCR1BzZWMgZG93 bmdyYWRlIHZ1bG5lcmFiaWxpdHkgKG9yIGxhY2sgdGhlcmVvZiksDQpsZXQgZGlzY3VzcyB0aGF0 IGluIFByYWd1ZSB3aXRoIHdoaXRlIGJvYXJkL3BhcGVyLg0KSWYgSSB3ZXJlIHlvdSwgSSB3b3Vs ZCByZW1vdmUgbmVnYXRpdmUgc3RhdGVtZW50cyBjb25jZXJuaW5nIHRoaXMgaW4gdGhlIGRyYWZ0 Lg0KSSBhbSBzdXJlIEkgY2FuIGNsYXJpZnkgYW5kIGhlbHAgd2l0aCB0aGlzLg0KDQpXZSBjYW4g ZnVydGhlciBkaXNjdXNzL2NsYXJpZnkgc29tZSBvZiB0aGUgb3RoZXIgcG9pbnRzIGFsc28gd2hl biB3ZSBtZWV0Lg0KDQpUaGFua3MuDQoNClNyaXJhbQ0KDQpGcm9tOiBBbGV4YW5kZXIgQXppbW92 IDxhLmUuYXppbW92QGdtYWlsLmNvbT4NClNlbnQ6IFR1ZXNkYXksIE1hcmNoIDUsIDIwMTkgMTI6 MzggUE0NClRvOiBTcmlyYW0sIEtvdGlrYWxhcHVkaSAoRmVkKSA8a290aWthbGFwdWRpLnNyaXJh bUBuaXN0Lmdvdj4NCkNjOiBzaWRyb3BzLWNoYWlyc0BpZXRmLm9yZzsgc2lkcm9wc0BpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFtTaWRyb3BzXSBXRyBBZG9wdGlvbiBjYWxsIGRyYWZ0LWF6aW1vdi1z aWRyb3BzLWFzcGEtdmVyaWZpY2F0aW9uDQoNCkRlYXIgU3JpcmFtLA0KDQpQbGVhc2Ugc2VlIG15 IGlubGluZSBjb21tZW50cy4NCg0K0LLRgSwgMyDQvNCw0YAuIDIwMTkg0LMuINCyIDA0OjM2LCBT cmlyYW0sIEtvdGlrYWxhcHVkaSAoRmVkKSA8a290aWthbGFwdWRpLnNyaXJhbUBuaXN0Lmdvdjxt YWlsdG86a290aWthbGFwdWRpLnNyaXJhbUBuaXN0Lmdvdj4+Og0KSGkgQWxleCwNCg0KU28sIHll cyB0aGVyZSBhcmUgdGhpbmdzIHdlIG5lZWQgdG8gY2FyZWZ1bCBhYm91dCBpbiB0aGUgZGVzaWdu Lg0KQWxzbywgZ290IHRvIGJlIGNhcmVmdWwgYWJvdXQgY2xhaW1pbmcsIOKAnHRoaXMgbWVjaGFu aXNtDQpndWFyYW50ZWVzIGRldGVjdGlvbiBvZiBib3RoIG1hbGljaW91cyBhbmQgYWNjaWRlbnRh bCByb3V0ZSBsZWFrc+KAnS4NCg0KVGhlcmUgaXMgYSBuZXcgQ29tbWVudCAjMCB0aGF0IEkgaGF2 ZSBhZGRlZCBoZXJlLg0KQW5kIEkgaGF2ZSBvdGhlciBjb21tZW50cyBpbmxpbmUgYmVsb3cuDQoN CkNvbW1lbnQjMDoNCk9uZSBtb3JlIHRoaW5nIG9jY3VycmVkIHRvIG1lLiBUaGlzIGlzIHZlcnkg YmFzaWMuDQpDb25zaWRlciB0aGVzZSBmcmVxdWVudGx5IG9jY3VycmluZyBleGFtcGxlcyBvZiBy b3V0ZSBsZWFrczoNCg0KQVMxIChUaWVyIDEpLS0tLVAyQy0tLS0+QVMyIChjdXN0b21lciktLS0t QzJQLS0tLS0+IEFTMw0KQVMxIChUaWVyIDEpLS0tLXAycC0tLS0+QVMyIChUaWVyIDEpLS0tLXAy cC0tLS0tPiBBUzMgKFRpZXIgMSkNCg0KQVMyIGxlYWtzIHRoZSByb3V0ZSBsZWFybmVkIGZyb20g QVMxIGluIGJvdGggY2FzZXMgYWJvdmUuDQpBUzEgYmVpbmcgYSBUaWVyIDEsIG5ldmVyIGhhcyB0 byBjcmVhdGUgYW4gQVNQQSAoaGFzIG5vIHByb3ZpZGVycykuDQpSZWdhcmRsZXNzIG9mIHdoZXRo ZXIgQVMyIGNyZWF0ZWQgYW4gQVNQQSBvciBub3QsDQpBUzMgaXMgbm90IGFibGUgdG8gZGV0ZWN0 IHRoZSBsZWFrcyBpbiBib3RoIGNhc2VzIGFib3ZlDQoocGVyIGFsZ29yaXRobSBpbiB0aGUgZHJh ZnQpLg0KVGhpcyBzYW1lIGlzc3VlIGFyaXNlcyBldmVuIGluIHRoZSBleGFtcGxlIG9mIENvbW1l bnQgIzINCmlmIEFTMyBpbiB0aGF0IGV4YW1wbGUgd2VyZSBhIFRpZXIgMS4NCllvdSBzZWVtIHRv IGJlIG1pc3JlYWRpbmcgaW4gc2VjdGlvbiA2LiBRdW90ZToNCg0KICAgQW4gQVNQQSB3aXRoIGEg cHJvdmlkZXIgQVMgb2YgMCBpcyBhIHN0YXRlbWVudCBieSB0aGUgY3VzdG9tZXIgQVMNCg0KICAg dGhhdCB0aGUgaXRzIHJvdXRlcyBzaG91bGQgbm90IGJlIHJlY2VpdmVkIGJ5IGFueSByZWx5aW5n IHBhcnR5IEFTDQoNCiAgIGZyb20gYW55IG9mIGl0cyBjdXN0b21lcnMgb3IgcGVlcnMuDQpTbywg VGllcjEvSVhlcyBzaG91bGQgY3JlYXRlIG9ubHkgQVNQQTAgLSBhbmQgaXQgd2lsbCBiZSBlbm91 Z2ggdG8gZGV0ZWN0IGFub21hbGllcyB3aXRoIGl0cyBwcmVmaXhlcyBieSBhbnkgb3RoZXIgSVNQ IGluIHRoZSB3b3JsZC4NCg0KPkNhbiB5b3UgcGxlYXNlIGNsYXJpZnkgdG8gbWUgbmV4dCBzY2Vu YXJpbyB3aXRoIHRocmVlIElTUHM6DQo+IC0gVmljdGltIGFkdmVydGlzZXMgLzIzIHRvIFVwc3Ry ZWFtLCBkb2VzIHVzZSBCR1BTZWMsDQo+ICAgIGhhcyBST0EgcmVjb3JkIHdpdGggbWF4bGVuZ3Ro IDI0DQo+IC0gVXBzdHJlYW0sIGRvZXMgdXNlIEJHUFNlYw0KPiAtIEF0dGFja2VyLCBhZHZlcnRp c2VzIC8yNCB0aGF0IGJlbG9uZ3MgdG8gVmljdGltLCBhZGRzIGl0cyBBU04gYXQNCj4gICAgdGhl IGJlZ2lubmluZyBvZiBBU1BhdGgsIGRvZXNuJ3QgdXNlIEJHUFNlYw0KPldpbGwgVXBzdHJlYW0s IGFjY29yZGluZyB0byBSRkM4MjA1LCBhY2NlcHQgdGhlIGhpamFja2VkIHJvdXRlIGZyb20gQXR0 YWNrZXI/DQo+QW55d2F5LCBJJ20gb3BlbiBmb3IgZGlzY3Vzc2lvbiBhYm91dCBwcm9wZXIgd29y ZGluZyBoZXJlLg0KDQpUaGUgaWRlYSBvZiBhIEJHUHNlYyBjbG91ZCAoc29tZSBjYWxsIGl0IGlz bGFuZCkgbmVlZHMgdG8gYmUgdW5kZXJzdG9vZC4NCkkgaG9wZSB5b3UgaGFkIGNoYW5jZSB0byBy ZWFkIFJGQyA4MjA1IFNlY3Rpb24gNy45IOKAkw0KdGhlIGlkZWEgb2YgY29udGlndW91cyBCR1Bz ZWMgQVNlcy4NCkEgZ3JvdXAgb2YgY29udGlndW91cyBCR1BzZWMgQVNlcyBkZWNpZGVzIHRoYXQg dGhleQ0KcmVxdWlyZSBzaWduZWQgdXBkYXRlcyAoaS5lLiwgQkdQc2VjKSBmcm9tIERheSBYICp3 aXRoaW4gdGhlaXIgY2xvdWQqLg0KV2hhdCB0aGF0IG1lYW5zIGlzIHRoYXQgdGhleSBoYXZlIGtu b3dsZWRnZSB0aGF0IHRoZXkgYXJlDQpjb250aWd1b3VzIChhbGwgY29ubmVjdGVkIHRvIGVhY2gg b3RoZXIgYnkgc29tZSAjIG9mIGhvcHMpLA0KYW5kIHRoZXkgYWxsIGRvIEJHUHNlYy4gQW5kIHRo ZXkgZGVjaWRlIHRoYXQgQkdQc2VjIG11c3QgYmUgZG9uZQ0KZW5kLXRvLWVuZCB3aXRoaW4gdGhl aXIgQkdQc2VjIGNsb3VkLg0KVGhlbiBmcm9tIERheSBYLCB0aGV5IHJlcXVpcmUgc2lnbmVkL3Zh bGlkIHBhdGhzIGZvciBwcmVmaXhlcw0KdGhhdCAqb3JpZ2luYXRlIHdpdGhpbiB0aGVpciBCR1Bz ZWMgY2xvdWQqLg0KKFByZWZpeGVzIG9yaWdpbmF0ZWQgZnJvbSBvdXRzaWRlIHRoZSBjbG91ZCBt YXkgYmUgdW5zaWduZWQNCmFuZCBtYXkgcG9zc2libHkgYmUgc3ViamVjdCB0byBzaWduYXR1cmUg c3RyaXBwaW5nLikNClRoZW4gaW4geW91ciBleGFtcGxlLCB0aGUgYXR0YWNrIGlzIG5vdCBwb3Nz aWJsZSB3aXRoaW4gdGhlIGNsb3VkDQooaS5lLiwgaWYgYXR0YWNrZXIgc3RyaXBzIHRoZSBzaWdu YXR1cmVzIGZvciBhbnkgcHJlZml4IHRoYXQgb3JpZ2luYXRlZA0KaW4gdGhhdCBCR1BzZWMgY2xv dWQsIGhpcyB1bnNpZ25lZCB1cGRhdGUgaXMgSW52YWxpZCBhbmQgbm90IGFjY2VwdGVkOw0KaXQg d291bGQgYmUgdGhlIHNhbWUgYXMgdGhlIGF0dGFja2VyIGhpbXNlbGYgc3VwcHJlc3NpbmcgdGhl IHVwZGF0ZS4pDQpJJ3ZlIHJlYWQgNy45IHNlY3Rpb24gbXVsdGlwbGUgdGltZXMsIGFuZCB0aGVy ZSB3YXNuJ3QgYWJsZSB0byBmaW5kIGFueXRoaW5nIHJlbGF0ZWQgdG8gJ2Nsb3Vkcycgb3IgY29u ZGl0aW9uYWwgYWNjZXB0YW5jZSBvZiB1bnNpZ25lZCByb3V0ZXMgaWYgdGhlcmUgYXJlIHNpZ25l ZCBsZXNzIHNwZWNpZmljcy4NCk1heSBiZSB5b3Ugd291bGQgbGlrZSB0byB3cml0ZSBhbm90aGVy IGRvY3VtZW50IHRoYXQgd2lsbCBjbGVhcmx5IGRlc2NyaWJlIHRoaXMgcHJvY2VkdXJlPw0KDQog ID4+Q29tbWVudCAjMjogSW1wcm92ZW1lbnQgb2YgdGhlIGFsZ29yaXRobSBmb3IgZGV0ZWN0aW9u DQotLS0tIHNuaXAgLS0tLS0NCg0KPiBUaGlzIHN1Z2dlc3Rpb24gc291bmRzIGdyZWF0IGJ1dCBp dCBoYXMgYW4gaXNzdWUuIEltYWdpbmUgdGhhdCBBUzMgYW5kIEFTNA0KPiBoYXZlIHdoYXQgaXMg Y29tbW9ubHkgbmFtZWQgJ2NvbXBsZXgnIHJlbGF0aW9uLiBTbyB0aGV5IGFyZSBib3RoDQo+IGN1 c3RvbWVyLXByb3ZpZGVyIHRvIG9uZSBhbm90aGVyLiBBbmQgaW4geW91ciBzY2VuYXJpbywgd2hl cmUgb25seSBBUzQNCj4gY3JlYXRlcyBBU1BBIGl0IG1heSByZXN1bHQgaW4gcmVqZWN0aW9uIG9m IHZhbGlkIHJvdXRlcywgd2hpY2ggd2lsbCBtYWtlDQo+IEFTNCBxdWl0ZSB1bmhhcHB5Li4uDQoN ClllcywgYWdyZWUuIEFTUEEgaGFzIGEgc2hvcnRjb21pbmcgbmV2ZXJ0aGVsZXNzLg0KWW91IGhh dmUgc3VnZ2VzdGVkIGFuIGltcHJvdmVtZW50IGFuZCBJIGV4cGxhaW5lZCB3aHkgaXQgaXMgbm90 IGFwcGxpY2FibGUuIEkndmUgbmV2ZXIgaGVhcmQgdGhhdCBjYXJlZnVsIGRlc2lnbiBpcyBhIHNo b3J0Y29taW5nLg0KDQo+PiBDb21tZW50ICM0OiBOb3QgYWxsIG1hbGljaW91cyBsZWFrcyAvIGhp amFja3MgYXJlIGRldGVjdGVkDQo+Pg0KPj4gSW4gdGhlIHRvcG9sb2d5IGJlbG93LCBBUzIgbGVh a3MgdGhlIHBhdGggaXQgbGVhcm5lZCBmcm9tIGl0cyBwZWVyIEFTNCB0bw0KPj4gaXRzIHByb3Zp ZGVyIEFTMyB3aXRoIHBhdGggbW9kaWZpY2F0aW9uIHRvIGF2b2lkIHJvdXRlIGxlYWsgZGV0ZWN0 aW9uLA0KPj4gb3Igb25lIG1heSB0aGluayBvZiBpdCBhcyBhIGhpamFjayB3aXRoIGZlYXNpYmxl IHBhdGggaW5zZXJ0aW9uLg0KPj4gSW4gZWl0aGVyIGNhc2UsIHRoZSBVcGRhdGU6IHAyIEFTMiBB UzEgZnJvbSBBUzIgdG8gQVMzIGlzDQo+PiBpbGxlZ2l0aW1hdGUgYnV0IGRlZmllcyBkZXRlY3Rp b24gZGVzcGl0ZSBhbGwgQVNlcyBwYXJ0aWNpcGF0aW5nIGluIEFTUEEuDQo+Pg0KPj4gICAgICAg ICAgQVMzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBBUzUNCj4+ICAgICAgICAgICAgICAgXCAgcDEgQVMyIEFTMSAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAvDQo+PiAgICAgICAgICAgICAgICAgXCBwMiBBUzIg QVMxICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLw0KPj4gICAgICAgICAgICAgICAg ICAgIFwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLw0K Pj4gICAgICAgICAgICAgICAgICAgICAgXCAgICAgICAgIDwtLS0tcDIgQVM0IEFTMS0tICAgIC8N Cj4+ICAgICAgICAgICAgICAgICAgICAgICAgQVMyIC0tLS0tLS1wMnAtLS0tLS0tLS0tQVM0DQo+ PiAgICAgICAgICAgICAgICAgICAgICAgICAgIFwgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAvDQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwgcDEgQVMxICAgICAgICAgICAv cDIgQVMxDQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcICAgICAgICAgICAg ICAgICAvDQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFTMQ0KPj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAocDEsIHAyKQ0KPj4NCg0KPiBUaGlu a2luZyBhYm91dCBpdCBhcyBoaWphY2sgYWRkcyBzaW1wbGljaXR5IHRvIHRoZSBwaWN0dXJlLiBD dXN0b21lcnMgbWF5DQo+IHN0aWxsIGJlIGhpamFja2VkIGJ5IGl0cyBkaXJlY3Qgb3IgaW5kaXJl Y3QgcHJvdmlkZXJzLiBXaGlsZSBpdA0KPiBzaWduaWZpY2FudGx5IGxpbWl0cyB0aGUgYXR0YWNr ZXIgdmVjdG9yIGFuZCBoaWdobHkgdW5saWtlbHkgdG8gaGFwcGVuIGluDQo+IHRoZSByZWFsIHdv cmxkLCBpdCBtdXN0IGJlIGNsZWFybHkgc3RhdGVkIGluIHRoZSBkcmFmdC4gUHVzaGVkIHRvIHN0 YWNrLg0KDQpJdCBpcyBib3RoLiBIYXJkIHRvIHJ1bGUgb3V0IG1hbGljaW91cyBsZWFrIHdpdGgg cGF0aCBtb2RpZmljYXRpb24uDQpXaGVuIGNvbnNpZGVyaW5nIG1hbGljaW91cyBzY2VuYXJpb3Ms IHRoZSBhYm92ZSB3b3VsZCBub3QgYmUgdW5saWtlbHkuDQpJIHRoaW5rIHRoaXMgaXMgdHlwaWNh bGx5IHdoYXQgdGhlIGRldGVybWluZWQgYXR0YWNrZXIgKEFTMikgbWlnaHQgZG8gdG8NCm1hbGlj aW91c2x5IGluY3JlYXNlIHRoZWlyIHJldmVudWUuDQpEbyB5b3UgdGhpbmsgdGhhdCBtYWxpY2lv dXMgYXR0YWNrIGZyb20gdGhlIHByb3ZpZGVyLCB0aGF0IGhhcyBjb250cmFjdGVkIGFncmVlbWVu dCB3aXRoIGl0cyBjdXN0b21lciAoYW5kIGFscmVhZHkgcHJvcGFnYXRlcyBjdXN0b21lcidzIHBy ZWZpeGVzKSBpcyBsaWtlbHkgdG8gaGFwcGVuPw0KRnJvbSB3aGF0IEkga25vdyBmcm9tIHJlYWwg aGlqYWNrIGlzc3VlcyAtIGl0J3Mgbm90Lg0KDQo+PiBDb21tZW50ICM1OiBQYXRoIHZlcmlmaWNh dGlvbiB2cy4gcGF0aCBmZWFzaWJpbGl0eQ0KPj4NCj4+IEJhc2VkIG9uIHRoZSBhYm92ZSBleGFt cGxlcywgaW4gdGhlIGRyYWZ0LCBwZXJoYXBzIGl0IGlzIGJldHRlciB0byBzYXkNCj4+DQo+PiB0 aGF0IHRoZSBwYXRoIGlzIGFzc2Vzc2VkIGZlYXNpYmxlIHJhdGhlciB0aGFuIHNheSB0aGF0IHRo ZSBwYXRoIGlzDQo+PiB2ZXJpZmllZC4NCj4+DQoNCj4gSSdtIG5vdCBhIG5hdGl2ZSBzcGVha2Vy IGJ1dCBmb3IgbWUgJ2ZlYXNpYmlsaXR5JyBzb3VuZHMgYSBiaXQgb2RkLiBJDQo+IHdvdWxkIGJl IGdsYWQgdG8gbGVhcm4gb3RoZXIgb3BpbmlvbnMgZnJvbSB0aGUgd2cgbWVtYmVycy4gQW55d2F5 LCB0aGlzDQo+IHF1ZXN0aW9uIHNob3VsZCBub3QgYmVjb21lIGEgc2hvd3N0b3BwZXIuDQoNCkJH UHNlYyBwcm92aWRlcyBoYXJkIGFzc3VyYW5jZSB0aGF0IHBhdGggc2VlbiBpbiB0aGUgdXBkYXRl IGlzIGNvcnJlY3QuDQpBU1BBIGNhbiBwcm92aWRlIGNvbmZpcm1hdGlvbiB0aGF0IHRoZSBwYXRo IGlzIHBvc3NpYmxlL2ZlYXNpYmxlLg0KSXQgY2Fubm90IGFzc3VyZSB0aGF0IHBhdGggc2VlbiBp biB0aGUgdXBkYXRlIGlzIHRoZSBhY3R1YWwgcGF0aA0KdGhhdCB0aGUgdXBkYXRlIHRyYXZlcnNl ZC4gVGhpcyBpcyBjbGVhciBmcm9tIHRoZSBhYm92ZSBleGFtcGxlIChDb21tLiAjNCkuDQoNCldl IGNhbiBtZWV0IGluIFByYWd1ZS4gSSdsbCBiZSBoYXBweSB0byBkaXNjdXNzDQphbmQgd2UgY2Fu IHRyeSB0byBoZWxwIHJlc29sdmUgdGhlc2UgKHRvIHRoZSBleHRlbnQgcG9zc2libGUpLg0KQXJn dWluZyBhYm91dCBCR1BTZWMgaXNuJ3QgbXkgZ29hbCBhdCB0aGlzIHBvaW50IGluIHRpbWUsIG5v ciBpdCBpcyB0aGUgcHVycG9zZSBvZiB0aGUgZHJhZnQuDQpJIGNhbid0IHNheSB5b3UgY29udmlu Y2VkIG1lIGFib3V0IG5hbWluZywgYnV0IGFzIHlvdSBrbm93LCBJJ20gYWx3YXlzIG9wZW4gdG8g Y29uc3RydWN0aXZlIGRpc2N1c3Npb25zLg0KDQotLQ0KQmVzdCByZWdhcmRzLA0KQWxleGFuZGVy IEF6aW1vdg0K --_000_SN6PR0901MB2366EEEA3E1B00695EBF81EF84730SN6PR0901MB2366_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAsIGxp Lm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsN Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uSFRNTFByZWZvcm1h dHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQi Ow0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAx LjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib25vcmFi bGUgQ2hhaXJzOiBZb3UgbWF5IGNvdW50IG1lIGluIGFzIOKAmHN1cHBvcnTigJkuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkhpIEFsZXgsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBm b3IgY2xhcmlmeWluZyBBU1BBMCB1c2UgZm9yIFRpZXIxLiBJIG92ZXJsb29rZWQgYmVmb3JlLiBJ IGFtIGdvb2Qgbm93Lg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZvciB0aGUgQkdQc2VjIGRv d25ncmFkZSB2dWxuZXJhYmlsaXR5IChvciBsYWNrIHRoZXJlb2YpLCA8bzpwPg0KPC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+bGV0IGRpc2N1c3MgdGhhdCBpbiBQcmFndWUgd2l0aCB3 aGl0ZSBib2FyZC9wYXBlci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklm IEkgd2VyZSB5b3UsIEkgd291bGQgcmVtb3ZlIG5lZ2F0aXZlIHN0YXRlbWVudHMgY29uY2Vybmlu ZyB0aGlzIGluIHRoZSBkcmFmdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkkgYW0gc3VyZSBJIGNhbiBjbGFyaWZ5IGFuZCBoZWxwIHdpdGggdGhpcy48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+V2UgY2FuIGZ1cnRoZXIgZGlzY3Vzcy9jbGFyaWZ5IHNvbWUgb2YgdGhlIG90 aGVyIHBvaW50cyBhbHNvIHdoZW4gd2UgbWVldC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhh bmtzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TcmlyYW0gJm5ic3A7Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow aW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IEFsZXhhbmRlciBBemltb3YgJmx0O2EuZS5h emltb3ZAZ21haWwuY29tJmd0OyA8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgTWFyY2ggNSwg MjAxOSAxMjozOCBQTTxicj4NCjxiPlRvOjwvYj4gU3JpcmFtLCBLb3Rpa2FsYXB1ZGkgKEZlZCkg Jmx0O2tvdGlrYWxhcHVkaS5zcmlyYW1AbmlzdC5nb3YmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBzaWRy b3BzLWNoYWlyc0BpZXRmLm9yZzsgc2lkcm9wc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW1NpZHJvcHNdIFdHIEFkb3B0aW9uIGNhbGwgZHJhZnQtYXppbW92LXNpZHJvcHMtYXNw YS12ZXJpZmljYXRpb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EZWFyIFNyaXJh bSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ UGxlYXNlIHNlZSBteSBpbmxpbmUgY29tbWVudHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPtCy0YEsIDMg0LzQsNGALiAyMDE5INCzLiDQsiAw NDozNiwgU3JpcmFtLCBLb3Rpa2FsYXB1ZGkgKEZlZCkgJmx0OzxhIGhyZWY9Im1haWx0bzprb3Rp a2FsYXB1ZGkuc3JpcmFtQG5pc3QuZ292Ij5rb3Rpa2FsYXB1ZGkuc3JpcmFtQG5pc3QuZ292PC9h PiZndDs6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5IaSBBbGV4LDxicj4NCjxicj4NClNvLCB5ZXMgdGhlcmUgYXJlIHRoaW5ncyB3ZSBu ZWVkIHRvIGNhcmVmdWwgYWJvdXQgaW4gdGhlIGRlc2lnbi48YnI+DQpBbHNvLCBnb3QgdG8gYmUg Y2FyZWZ1bCBhYm91dCBjbGFpbWluZywg4oCcdGhpcyBtZWNoYW5pc208YnI+DQpndWFyYW50ZWVz IGRldGVjdGlvbiBvZiBib3RoIG1hbGljaW91cyBhbmQgYWNjaWRlbnRhbCByb3V0ZSBsZWFrc+KA nS4gPGJyPg0KPGJyPg0KVGhlcmUgaXMgYSBuZXcgQ29tbWVudCAjMCB0aGF0IEkgaGF2ZSBhZGRl ZCBoZXJlLjxicj4NCkFuZCBJIGhhdmUgb3RoZXIgY29tbWVudHMgaW5saW5lIGJlbG93LiA8YnI+ DQo8YnI+DQpDb21tZW50IzA6PGJyPg0KT25lIG1vcmUgdGhpbmcgb2NjdXJyZWQgdG8gbWUuIFRo aXMgaXMgdmVyeSBiYXNpYy4gPGJyPg0KQ29uc2lkZXIgdGhlc2UgZnJlcXVlbnRseSBvY2N1cnJp bmcgZXhhbXBsZXMgb2Ygcm91dGUgbGVha3M6PGJyPg0KPGJyPg0KQVMxIChUaWVyIDEpLS0tLVAy Qy0tLS0mZ3Q7QVMyIChjdXN0b21lciktLS0tQzJQLS0tLS0mZ3Q7IEFTMzxicj4NCkFTMSAoVGll ciAxKS0tLS1wMnAtLS0tJmd0O0FTMiAoVGllciAxKS0tLS1wMnAtLS0tLSZndDsgQVMzIChUaWVy IDEpPGJyPg0KPGJyPg0KQVMyIGxlYWtzIHRoZSByb3V0ZSBsZWFybmVkIGZyb20gQVMxIGluIGJv dGggY2FzZXMgYWJvdmUuIDxicj4NCkFTMSBiZWluZyBhIFRpZXIgMSwgbmV2ZXIgaGFzIHRvIGNy ZWF0ZSBhbiBBU1BBIChoYXMgbm8gcHJvdmlkZXJzKS4mbmJzcDsgPGJyPg0KUmVnYXJkbGVzcyBv ZiB3aGV0aGVyIEFTMiBjcmVhdGVkIGFuIEFTUEEgb3Igbm90LDxicj4NCkFTMyBpcyBub3QgYWJs ZSB0byBkZXRlY3QgdGhlIGxlYWtzIGluIGJvdGggY2FzZXMgYWJvdmU8YnI+DQoocGVyIGFsZ29y aXRobSBpbiB0aGUgZHJhZnQpLjxicj4NClRoaXMgc2FtZSBpc3N1ZSBhcmlzZXMgZXZlbiBpbiB0 aGUgZXhhbXBsZSBvZiBDb21tZW50ICMyPGJyPg0KaWYgQVMzIGluIHRoYXQgZXhhbXBsZSB3ZXJl IGEgVGllciAxLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPllvdSBzZWVtIHRvIGJlIG1pc3JlYWRpbmcgaW4gc2VjdGlvbiA2LiBRdW90 ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmU+Jm5ic3A7Jm5ic3A7IEFuIEFT UEEgd2l0aCBhIHByb3ZpZGVyIEFTIG9mIDAgaXMgYSBzdGF0ZW1lbnQgYnkgdGhlIGN1c3RvbWVy IEFTPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHRoYXQgdGhlIGl0cyByb3V0 ZXMgc2hvdWxkIG5vdCBiZSByZWNlaXZlZCBieSBhbnkgcmVseWluZyBwYXJ0eSBBUzxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBmcm9tIGFueSBvZiBpdHMgY3VzdG9tZXJzIG9y IHBlZXJzLjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5TbywgVGllcjEvSVhlcyBzaG91bGQgY3JlYXRlIG9ubHkgQVNQQTAgLSBhbmQgaXQgd2ls bCBiZSBlbm91Z2ggdG8gZGV0ZWN0IGFub21hbGllcyB3aXRoIGl0cyBwcmVmaXhlcyBieSBhbnkg b3RoZXIgSVNQIGluIHRoZSB3b3JsZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0O0NhbiB5b3UgcGxlYXNlIGNsYXJpZnkgdG8g bWUgbmV4dCBzY2VuYXJpbyB3aXRoIHRocmVlIElTUHM6DQo8YnI+DQomZ3Q7IC0gVmljdGltIGFk dmVydGlzZXMgLzIzIHRvIFVwc3RyZWFtLCBkb2VzIHVzZSBCR1BTZWMsIDxicj4NCiZndDsmbmJz cDsgJm5ic3A7IGhhcyBST0EgcmVjb3JkIHdpdGggbWF4bGVuZ3RoIDI0PGJyPg0KJmd0OyAtIFVw c3RyZWFtLCBkb2VzIHVzZSBCR1BTZWM8YnI+DQomZ3Q7IC0gQXR0YWNrZXIsIGFkdmVydGlzZXMg LzI0IHRoYXQgYmVsb25ncyB0byBWaWN0aW0sIGFkZHMgaXRzIEFTTiBhdCA8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyB0aGUgYmVnaW5uaW5nIG9mIEFTUGF0aCwgZG9lc24ndCB1c2UgQkdQU2VjPGJy Pg0KJmd0O1dpbGwgVXBzdHJlYW0sIGFjY29yZGluZyB0byBSRkM4MjA1LCBhY2NlcHQgdGhlIGhp amFja2VkIHJvdXRlIGZyb20gQXR0YWNrZXI/PGJyPg0KJmd0O0FueXdheSwgSSdtIG9wZW4gZm9y IGRpc2N1c3Npb24gYWJvdXQgcHJvcGVyIHdvcmRpbmcgaGVyZS48YnI+DQo8YnI+DQpUaGUgaWRl YSBvZiBhIEJHUHNlYyBjbG91ZCAoc29tZSBjYWxsIGl0IGlzbGFuZCkgbmVlZHMgdG8gYmUgdW5k ZXJzdG9vZC48YnI+DQpJIGhvcGUgeW91IGhhZCBjaGFuY2UgdG8gcmVhZCBSRkMgODIwNSBTZWN0 aW9uIDcuOSDigJMgPGJyPg0KdGhlIGlkZWEgb2YgY29udGlndW91cyBCR1BzZWMgQVNlcy48YnI+ DQpBIGdyb3VwIG9mIGNvbnRpZ3VvdXMgQkdQc2VjIEFTZXMgZGVjaWRlcyB0aGF0IHRoZXkgPGJy Pg0KcmVxdWlyZSBzaWduZWQgdXBkYXRlcyAoaS5lLiwgQkdQc2VjKSBmcm9tIERheSBYICp3aXRo aW4gdGhlaXIgY2xvdWQqLiA8YnI+DQpXaGF0IHRoYXQgbWVhbnMgaXMgdGhhdCB0aGV5IGhhdmUg a25vd2xlZGdlIHRoYXQgdGhleSBhcmUgPGJyPg0KY29udGlndW91cyAoYWxsIGNvbm5lY3RlZCB0 byBlYWNoIG90aGVyIGJ5IHNvbWUgIyBvZiBob3BzKSw8YnI+DQphbmQgdGhleSBhbGwgZG8gQkdQ c2VjLiBBbmQgdGhleSBkZWNpZGUgdGhhdCBCR1BzZWMgbXVzdCBiZSBkb25lPGJyPg0KZW5kLXRv LWVuZCB3aXRoaW4gdGhlaXIgQkdQc2VjIGNsb3VkLiA8YnI+DQpUaGVuIGZyb20gRGF5IFgsIHRo ZXkgcmVxdWlyZSBzaWduZWQvdmFsaWQgcGF0aHMgZm9yIHByZWZpeGVzIDxicj4NCnRoYXQgKm9y aWdpbmF0ZSB3aXRoaW4gdGhlaXIgQkdQc2VjIGNsb3VkKi48YnI+DQooUHJlZml4ZXMgb3JpZ2lu YXRlZCBmcm9tIG91dHNpZGUgdGhlIGNsb3VkIG1heSBiZSB1bnNpZ25lZDxicj4NCmFuZCBtYXkg cG9zc2libHkgYmUgc3ViamVjdCB0byBzaWduYXR1cmUgc3RyaXBwaW5nLikgPGJyPg0KVGhlbiBp biB5b3VyIGV4YW1wbGUsIHRoZSBhdHRhY2sgaXMgbm90IHBvc3NpYmxlIHdpdGhpbiB0aGUgY2xv dWQ8YnI+DQooaS5lLiwgaWYgYXR0YWNrZXIgc3RyaXBzIHRoZSBzaWduYXR1cmVzIGZvciBhbnkg cHJlZml4IHRoYXQgb3JpZ2luYXRlZCA8YnI+DQppbiB0aGF0IEJHUHNlYyBjbG91ZCwgaGlzIHVu c2lnbmVkIHVwZGF0ZSBpcyBJbnZhbGlkIGFuZCBub3QgYWNjZXB0ZWQ7PGJyPg0KaXQgd291bGQg YmUgdGhlIHNhbWUgYXMgdGhlIGF0dGFja2VyIGhpbXNlbGYgc3VwcHJlc3NpbmcgdGhlIHVwZGF0 ZS4pPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J J3ZlIHJlYWQgNy45IHNlY3Rpb24gbXVsdGlwbGUgdGltZXMsIGFuZCB0aGVyZSB3YXNuJ3QgYWJs ZSB0byBmaW5kIGFueXRoaW5nIHJlbGF0ZWQgdG8gJ2Nsb3Vkcycgb3IgY29uZGl0aW9uYWwgYWNj ZXB0YW5jZSBvZiB1bnNpZ25lZCByb3V0ZXMgaWYgdGhlcmUgYXJlIHNpZ25lZCBsZXNzIHNwZWNp Zmljcy48YnI+DQpNYXkgYmUgeW91IHdvdWxkIGxpa2UgdG8gd3JpdGUgYW5vdGhlciBkb2N1bWVu dCB0aGF0IHdpbGwgY2xlYXJseSBkZXNjcmliZSB0aGlzIHByb2NlZHVyZT88bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmZ3Q7Jmd0O0Nv bW1lbnQgIzI6IEltcHJvdmVtZW50IG9mIHRoZSBhbGdvcml0aG0gZm9yIGRldGVjdGlvbjxicj4N Ci0tLS0gc25pcCAtLS0tLTxicj4NCjxicj4NCiZndDsgVGhpcyBzdWdnZXN0aW9uIHNvdW5kcyBn cmVhdCBidXQgaXQgaGFzIGFuIGlzc3VlLiBJbWFnaW5lIHRoYXQgQVMzIGFuZCBBUzQ8YnI+DQom Z3Q7IGhhdmUgd2hhdCBpcyBjb21tb25seSBuYW1lZCAnY29tcGxleCcgcmVsYXRpb24uIFNvIHRo ZXkgYXJlIGJvdGg8YnI+DQomZ3Q7IGN1c3RvbWVyLXByb3ZpZGVyIHRvIG9uZSBhbm90aGVyLiBB bmQgaW4geW91ciBzY2VuYXJpbywgd2hlcmUgb25seSBBUzQ8YnI+DQomZ3Q7IGNyZWF0ZXMgQVNQ QSBpdCBtYXkgcmVzdWx0IGluIHJlamVjdGlvbiBvZiB2YWxpZCByb3V0ZXMsIHdoaWNoIHdpbGwg bWFrZTxicj4NCiZndDsgQVM0IHF1aXRlIHVuaGFwcHkuLi48YnI+DQo8YnI+DQpZZXMsIGFncmVl LiBBU1BBIGhhcyBhIHNob3J0Y29taW5nIG5ldmVydGhlbGVzcy48bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb3UgaGF2ZSBzdWdnZXN0 ZWQgYW4gaW1wcm92ZW1lbnQgYW5kIEkgZXhwbGFpbmVkIHdoeSBpdCBpcyBub3QgYXBwbGljYWJs ZS4gSSd2ZSBuZXZlciBoZWFyZCB0aGF0IGNhcmVmdWwgZGVzaWduIGlzIGEgc2hvcnRjb21pbmcu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZndDsmZ3Q7IENvbW1lbnQgIzQ6IE5vdCBhbGwgbWFsaWNpb3VzIGxlYWtzIC8gaGlqYWNr cyBhcmUgZGV0ZWN0ZWQ8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEluIHRoZSB0b3BvbG9n eSBiZWxvdywgQVMyIGxlYWtzIHRoZSBwYXRoIGl0IGxlYXJuZWQgZnJvbSBpdHMgcGVlciBBUzQg dG88YnI+DQomZ3Q7Jmd0OyBpdHMgcHJvdmlkZXIgQVMzIHdpdGggcGF0aCBtb2RpZmljYXRpb24g dG8gYXZvaWQgcm91dGUgbGVhayBkZXRlY3Rpb24sPGJyPg0KJmd0OyZndDsgb3Igb25lIG1heSB0 aGluayBvZiBpdCBhcyBhIGhpamFjayB3aXRoIGZlYXNpYmxlIHBhdGggaW5zZXJ0aW9uLjxicj4N CiZndDsmZ3Q7IEluIGVpdGhlciBjYXNlLCB0aGUgVXBkYXRlOiBwMiBBUzIgQVMxIGZyb20gQVMy IHRvIEFTMyBpczxicj4NCiZndDsmZ3Q7IGlsbGVnaXRpbWF0ZSBidXQgZGVmaWVzIGRldGVjdGlv biBkZXNwaXRlIGFsbCBBU2VzIHBhcnRpY2lwYXRpbmcgaW4gQVNQQS48YnI+DQomZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBBUzMmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQVM1PGJyPg0KJmd0OyZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7XCZu YnNwOyBwMSBBUzIgQVMxJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Lzxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtcIHAy IEFTMiBBUzEmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7Lzxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFwmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsvPGJyPg0KJmd0OyZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFwmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 Jmx0Oy0tLS1wMiBBUzQgQVMxLS0mbmJzcDsgJm5ic3A7IC88YnI+DQomZ3Q7Jmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IEFTMiAtLS0tLS0tcDJwLS0tLS0tLS0tLUFTNDxicj4NCiZndDsm Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1wmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAvPGJyPg0KJmd0OyZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBcIHAxIEFTMSZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7L3AyIEFTMTxicj4NCiZndDsmZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBcJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsvPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7QVMxPGJyPg0K Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAocDEsIHAyKTxicj4NCiZndDsmZ3Q7PGJyPg0KPGJyPg0KJmd0 OyBUaGlua2luZyBhYm91dCBpdCBhcyBoaWphY2sgYWRkcyBzaW1wbGljaXR5IHRvIHRoZSBwaWN0 dXJlLiBDdXN0b21lcnMgbWF5PGJyPg0KJmd0OyBzdGlsbCBiZSBoaWphY2tlZCBieSBpdHMgZGly ZWN0IG9yIGluZGlyZWN0IHByb3ZpZGVycy4gV2hpbGUgaXQ8YnI+DQomZ3Q7IHNpZ25pZmljYW50 bHkgbGltaXRzIHRoZSBhdHRhY2tlciB2ZWN0b3IgYW5kIGhpZ2hseSB1bmxpa2VseSB0byBoYXBw ZW4gaW48YnI+DQomZ3Q7IHRoZSByZWFsIHdvcmxkLCBpdCBtdXN0IGJlIGNsZWFybHkgc3RhdGVk IGluIHRoZSBkcmFmdC4gUHVzaGVkIHRvIHN0YWNrLjxicj4NCjxicj4NCkl0IGlzIGJvdGguIEhh cmQgdG8gcnVsZSBvdXQgbWFsaWNpb3VzIGxlYWsgd2l0aCBwYXRoIG1vZGlmaWNhdGlvbi48YnI+ DQpXaGVuIGNvbnNpZGVyaW5nIG1hbGljaW91cyBzY2VuYXJpb3MsIHRoZSBhYm92ZSB3b3VsZCBu b3QgYmUgdW5saWtlbHkuPGJyPg0KSSB0aGluayB0aGlzIGlzIHR5cGljYWxseSB3aGF0IHRoZSBk ZXRlcm1pbmVkIGF0dGFja2VyIChBUzIpIG1pZ2h0IGRvIHRvPGJyPg0KbWFsaWNpb3VzbHkgaW5j cmVhc2UgdGhlaXIgcmV2ZW51ZS48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkRvIHlvdSB0aGluayB0aGF0IG1hbGljaW91cyBhdHRhY2sgZnJvbSB0 aGUgcHJvdmlkZXIsIHRoYXQgaGFzIGNvbnRyYWN0ZWQgYWdyZWVtZW50IHdpdGggaXRzIGN1c3Rv bWVyIChhbmQgYWxyZWFkeSBwcm9wYWdhdGVzIGN1c3RvbWVyJ3MgcHJlZml4ZXMpIGlzIGxpa2Vs eSB0byBoYXBwZW4/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5Gcm9tIHdoYXQgSSBrbm93IGZyb20gcmVhbCBoaWphY2sgaXNzdWVzIC0gaXQncyBu b3QuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mZ3Q7Jmd0OyBDb21tZW50ICM1OiBQYXRoIHZlcmlmaWNhdGlvbiB2cy4g cGF0aCBmZWFzaWJpbGl0eTxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgQmFzZWQgb24gdGhl IGFib3ZlIGV4YW1wbGVzLCBpbiB0aGUgZHJhZnQsIHBlcmhhcHMgaXQgaXMgYmV0dGVyIHRvIHNh eTxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgdGhhdCB0aGUgcGF0aCBpcyBhc3Nlc3NlZCBm ZWFzaWJsZSByYXRoZXIgdGhhbiBzYXkgdGhhdCB0aGUgcGF0aCBpczxicj4NCiZndDsmZ3Q7IHZl cmlmaWVkLjxicj4NCiZndDsmZ3Q7PGJyPg0KPGJyPg0KJmd0OyBJJ20gbm90IGEgbmF0aXZlIHNw ZWFrZXIgYnV0IGZvciBtZSAnZmVhc2liaWxpdHknIHNvdW5kcyBhIGJpdCBvZGQuIEk8YnI+DQom Z3Q7IHdvdWxkIGJlIGdsYWQgdG8gbGVhcm4gb3RoZXIgb3BpbmlvbnMgZnJvbSB0aGUgd2cgbWVt YmVycy4gQW55d2F5LCB0aGlzPGJyPg0KJmd0OyBxdWVzdGlvbiBzaG91bGQgbm90IGJlY29tZSBh IHNob3dzdG9wcGVyLjxicj4NCjxicj4NCkJHUHNlYyBwcm92aWRlcyBoYXJkIGFzc3VyYW5jZSB0 aGF0IHBhdGggc2VlbiBpbiB0aGUgdXBkYXRlIGlzIGNvcnJlY3QuPGJyPg0KQVNQQSBjYW4gcHJv dmlkZSBjb25maXJtYXRpb24gdGhhdCB0aGUgcGF0aCBpcyBwb3NzaWJsZS9mZWFzaWJsZS48YnI+ DQpJdCBjYW5ub3QgYXNzdXJlIHRoYXQgcGF0aCBzZWVuIGluIHRoZSB1cGRhdGUgaXMgdGhlIGFj dHVhbCBwYXRoPGJyPg0KdGhhdCB0aGUgdXBkYXRlIHRyYXZlcnNlZC4gVGhpcyBpcyBjbGVhciBm cm9tIHRoZSBhYm92ZSBleGFtcGxlIChDb21tLiAjNCkuPG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KV2UgY2FuIG1l ZXQgaW4gUHJhZ3VlLiBJJ2xsIGJlIGhhcHB5IHRvIGRpc2N1c3MgPGJyPg0KYW5kIHdlIGNhbiB0 cnkgdG8gaGVscCByZXNvbHZlIHRoZXNlICh0byB0aGUgZXh0ZW50IHBvc3NpYmxlKS4gPG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Bcmd1aW5nIGFi b3V0IEJHUFNlYyBpc24ndCBteSBnb2FsIGF0IHRoaXMgcG9pbnQgaW4gdGltZSwgbm9yIGl0IGlz IHRoZSBwdXJwb3NlIG9mIHRoZSBkcmFmdC48YnI+DQpJIGNhbid0IHNheSB5b3UgY29udmluY2Vk IG1lIGFib3V0IG5hbWluZywgYnV0IGFzIHlvdSBrbm93LCBJJ20gYWx3YXlzIG9wZW4gdG8gY29u c3RydWN0aXZlIGRpc2N1c3Npb25zLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+QWxleGFuZGVyIEF6aW1vdjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_SN6PR0901MB2366EEEA3E1B00695EBF81EF84730SN6PR0901MB2366_-- From nobody Wed Mar 6 09:46: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 A01F713122E; Wed, 6 Mar 2019 09:46:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.onmicrosoft.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 iXlNfnxgE3YC; Wed, 6 Mar 2019 09:46:02 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on061f.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe46::61f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A23A9131227; Wed, 6 Mar 2019 09:46:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector1-arrcus-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=y1nBbTK2+d4XcK1Hq1K1rvDmhAt1ZyZWpHen7LgmVls=; b=KYQ0cTeluM9V2Ml9QAN1OD64dzja5HxvpDelMRxxBHqxIS0hbk6ogiC9Mh6zuukI/SxIUHdofLN4GVWVG3NO/0ya1LKigsLTXAGKoSgU3xpt9qSaeXl84XPFzi2kcQ+GN6EolJuZGhbiuLX+rd0BAyfX7EeGYBSlogK+TRR9vbU= Received: from BYAPR18MB2856.namprd18.prod.outlook.com (20.179.58.82) by BYAPR18MB2631.namprd18.prod.outlook.com (20.179.94.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.16; Wed, 6 Mar 2019 17:45:59 +0000 Received: from BYAPR18MB2856.namprd18.prod.outlook.com ([fe80::c23:4a7:adaf:d2ec]) by BYAPR18MB2856.namprd18.prod.outlook.com ([fe80::c23:4a7:adaf:d2ec%3]) with mapi id 15.20.1686.018; Wed, 6 Mar 2019 17:45:59 +0000 From: Keyur Patel To: "sidrops@ietf.org" CC: "sidrops-chairs@ietf.org" Thread-Topic: Call for SIDROPS WG Agenda Items Thread-Index: AQHU1ER1+URVy/nSPEGWCmALfgT5jg== Date: Wed, 6 Mar 2019 17:45:58 +0000 Message-ID: <9CC45FA9-E0EA-4E7E-AEA6-C653D7BBAB99@arrcus.com> 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=keyur@arrcus.com; x-originating-ip: [70.234.233.188] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6b2ed982-9695-47e3-899e-08d6a25b97d1 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BYAPR18MB2631; x-ms-traffictypediagnostic: BYAPR18MB2631: x-microsoft-antispam-prvs: x-forefront-prvs: 0968D37274 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39830400003)(366004)(346002)(136003)(396003)(189003)(199004)(6306002)(6512007)(54896002)(2906002)(3846002)(6116002)(316002)(99286004)(6506007)(33656002)(5640700003)(6436002)(6486002)(8936002)(8676002)(1730700003)(81166006)(66066001)(81156014)(82746002)(508600001)(7736002)(14454004)(5660300002)(4744005)(2501003)(53936002)(2351001)(106356001)(105586002)(6916009)(36756003)(450100002)(476003)(186003)(26005)(2616005)(25786009)(256004)(486006)(97736004)(4326008)(86362001)(71190400001)(102836004)(71200400001)(83716004)(68736007); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR18MB2631; H:BYAPR18MB2856.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arrcus.com does not designate permitted sender hosts) x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCWUFQUjE4TUIyNjMxOzIzOjdVdmJBbFZSZ3ZQR05XbjRCbEtHYUwrNFda?= =?utf-8?B?RzU3SXFXL0prZEx1TWMrRFJjN09HNG4wV0tjMUlmUHhLNkk0amFqVEZLdU5k?= =?utf-8?B?WENRNy9qc2tPMTZ4aFIrQ2Z5bFV5SmZQZ0p1YXRkc0x3VWExMGJ1TDYyaG0v?= =?utf-8?B?MVVvYjJCbFRXUFozL2E2K2g3dDVzS09JU1NzZ0NadXdPNkY1OW9XVGxrNVdy?= =?utf-8?B?OFROSUJvYUtIUXE3bThhMnNkdFZ2ZDhTQVhSK1JIOW9xaXNnc1lVa2hIQ203?= =?utf-8?B?Q3lKRW5aSDVlblg4V0JWUWJYVWJ3blQ5Rk5CbjByUVV4S2srbmFQM2dMZkQ0?= =?utf-8?B?QjA1dFJpdHJaMUpIellpaUw3SGRTWW1IeWNLcUZlQlF2VG42WWRzM29jYnRw?= =?utf-8?B?NVl1L2JaYXhSTUF3YjR1anl2UXJLZ1VDdW1zTDh2UmZSOG41T0ZvWHZaUElz?= =?utf-8?B?bWcrWUxtdS9tcy9HSEJhdEpmMXJHSTEwbE9uOXUva1FYaExEeXJpNVliZ3A4?= =?utf-8?B?cU9wQUZCalhjNWpUQXpnOTYrSms4eEY2eDNWR1VuY0ZobHJlcDRTRGMwa243?= =?utf-8?B?N0JJcndPclR6aWVwTFYweUFmN1ZsVzBLOGJURDVIWFRrb1ZXbHdBTXphVHNR?= =?utf-8?B?dndqRWdvTzR1OU50eHAwaDcyMWJJQ2hXb0pNQklQRHFEaTF2Qy9halI2OUFM?= =?utf-8?B?M3ZoR0RVcXNnT2I2MkQxY3hhRHZqM3BTa2J4Rjc5MGt6dDdsTVVyS3EvY1Na?= =?utf-8?B?RVg4RWFFYkpJTGFwSUZLMDRiaUk0K1M4SVZZTEh5M2twdmQzYy9FaWU5ZEhl?= =?utf-8?B?UEhhb0kwWHZvRW1mVDBHOWFVc1BaVm9ZVU9KM0M5Q2dVOWM4em4wbkVOaWtv?= =?utf-8?B?dTQ5TlEveWpuK3J4RWNQNEhpY2kybjBFM0Fhb3BTTkV6RCtMc0lQT3hzL0tk?= =?utf-8?B?S0hKaHpiRGFhQVBzNXQwNXpaSXVPdlhLSkVSN3UwRmpMcjFvTEhpWURRc1li?= =?utf-8?B?Wnc3U1VEMy9oQkVIUDVCaXdNdmM2VEV6QzZ3UGVnVm1OaUhtUFB5UmE4cUpJ?= =?utf-8?B?UDlyd1NQeklvVlp0dmIvRFIxa3BhZWVkTTlPdnVWUzlSdXdNVkpDcTJSaW0y?= =?utf-8?B?eDhGRDRvT2N3RUlHTS9MQW5hTjIrSVhiUVVFWmd6K1FHR1U2YW10UXNFU3hC?= =?utf-8?B?ekllVHVOaWYwc3lVN2V6dnlBZVdmTkdxeU5nU0FsVDV0UHhQT1FwOTJUM29Y?= =?utf-8?B?V1JpanBqMGV1amlMSDlYSFU4ZDdhVEhVa2VkMU8rQUp6Q1VzanM3NVNQVEc3?= =?utf-8?B?SjA1WWNiL3BOTXhLVFBRMlhoWFlqR2ZyRWRRNnowMkhYRXVEWCtqQmttZ0V5?= =?utf-8?B?Rk9QZ3FmbTc0TExYQTdnRmlNektKTHRhNXpJeFJsRzdyWTJzWEFpVWdrbVIy?= =?utf-8?B?NWxyRGM3L3UvOUxtZVpTTWVJSHNoUWRLVzlhWjE0Q0hjYUh3cjdCNzUzRVVk?= =?utf-8?B?SkxDcWxOZTQ3M2gyMHRQMlY1M0E5M2dwT2lkTlRkbTVKOExueEFhZjFnTDNq?= =?utf-8?B?ZkFVS2JzdUduZ1NOaDhxQnQya1BFQzE2OHBGZXNkWkVqT2NuTmNjakpNUmhV?= =?utf-8?B?Y3FYY1BNbnBoa0MzMzIzd1h2Mjd3OHREL2JINTNBeURuSC9QbDhrMkZOeTZJ?= =?utf-8?Q?mgcUk/PzfxyJe+eAZAXSDAoswbXR6gNUxqccqcq?= x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: W0IBmz3ToJDa1nLLCGp1+/e9oRG+CblfC22HYN/8PJhkNWHmZlf9Y59srJfPqLpGvCbBr7/efP2Pt9FWOaH/jxQczaK+vd7bA++25AR2sCMflnqsGzsEZmgZ0bAB8iRdueaFslhoyZaSM5f+zRPpSJEdU0Jpqngt/0cCex8fPkdPM6+Whi+KOPpJ4aKpJ5VMc87QBTe9tNFXXyGVCdrrDmneWkVeEmKhIMql6XdFtBKvBkcnj39Z+pQJfxnVmWNpgEXEcZH1EAYoCsE3DVs3h1jnnYTmmeC5s1g4uQBchCBmVdcPoGf+bHoqKn9PWRT5bXPgtLp3WadM9+vsGu6r3QQ3YhH1qN4KMs3ORximSejvSefPulJzHTS5T7GCzuOYXsVwGWMpTrHMZwsAO7R7V41p/WYXcqopaq17DktYsNc= Content-Type: multipart/alternative; boundary="_000_9CC45FA9E0EA4E7EAEA6C653D7BBAB99arrcuscom_" MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6b2ed982-9695-47e3-899e-08d6a25b97d1 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2019 17:45:59.0778 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR18MB2631 Archived-At: Subject: [Sidrops] Call for SIDROPS WG 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, 06 Mar 2019 17:46:09 -0000 --_000_9CC45FA9E0EA4E7EAEA6C653D7BBAB99arrcuscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgZm9sa3MsDQoNClNJRFJPUFMgd2lsbCBtZWV0IGF0IElFVEYtMTA0IG9uIFR1ZXNkYXksIE1h cmNoIDI2dGggZnJvbSA5OjAwIGFtIOKAkyAxMTowMCBhbS4gUGxlYXNlIGZvcndhcmQgYW55IFNJ RFJPUFMgYWdlbmRhIGl0ZW1zIHlvdSBtYXkgaGF2ZSB0byBDaHJpcyBhbmQgbWUuIFBsZWFzZSBh bHNvIG1ha2Ugc3VyZSB0aGF0IHlvdXIgc2xpZGVzIGFyZSBhdmFpbGFibGUgdG8gdGhlIGNoYWly cyBieSBGcmlkYXkgbW9ybmluZyAoMy8yMi8yMDE5KS4gU2xpZGVzIHJlY2VpdmVkIGFmdGVyIHRo ZSBkZWFkbGluZSBtYXkgbm90IGJlIGF2YWlsYWJsZSBmb3IgdXNlIGR1cmluZyB0aGUgbWVldGlu Zy4NCg0KUmVnYXJkcywNCkNocmlzIGFuZCBLZXl1cg0KDQoNCg== --_000_9CC45FA9E0EA4E7EAEA6C653D7BBAB99arrcuscom_ Content-Type: text/html; charset="utf-8" Content-ID: <50B1C2CF7F0990408D95E29BDE507B7C@namprd18.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2NvbG9yOmJsYWNrIj5IaSBmb2xrcyw8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPlNJRFJP UFMmbmJzcDt3aWxsIG1lZXQgYXQgSUVURi0xMDQgb24gVHVlc2RheSwgTWFyY2ggMjZ0aCBmcm9t IDk6MDAgYW0g4oCTIDExOjAwIGFtLiBQbGVhc2UgZm9yd2FyZCBhbnkmbmJzcDtTSURST1BTJm5i c3A7YWdlbmRhIGl0ZW1zIHlvdSBtYXkgaGF2ZSB0byBDaHJpcyBhbmQgbWUuIFBsZWFzZSBhbHNv IG1ha2Ugc3VyZSB0aGF0IHlvdXIgc2xpZGVzIGFyZSBhdmFpbGFibGUNCiB0byB0aGUgY2hhaXJz IGJ5IEZyaWRheSBtb3JuaW5nICgzLzIyLzIwMTkpLiBTbGlkZXMgcmVjZWl2ZWQgYWZ0ZXIgdGhl IGRlYWRsaW5lIG1heSBub3QgYmUgYXZhaWxhYmxlIGZvciB1c2UgZHVyaW5nIHRoZSBtZWV0aW5n Ljwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9y OmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtjb2xvcjpibGFjayI+UmVnYXJkcyw8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+Q2hyaXMgYW5kJm5ic3A7S2V5dXIm bmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtj b2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_9CC45FA9E0EA4E7EAEA6C653D7BBAB99arrcuscom_-- From nobody Fri Mar 8 17:55: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 1E679126C15 for ; Fri, 8 Mar 2019 17:55:52 -0800 (PST) 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 uE9nsh62BwZu for ; Fri, 8 Mar 2019 17:55:50 -0800 (PST) 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 854DA1274D0 for ; Fri, 8 Mar 2019 17:55:50 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1h2RDI-0005nf-N8 for sidrops@ietf.org; Sat, 09 Mar 2019 01:55:49 +0000 Date: Fri, 08 Mar 2019 17:55:48 -0800 Message-ID: From: Randy Bush To: SIDR Operations WG References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 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] Fwd: draft-ymbk-sidrops-ov-signal-02.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: Sat, 09 Mar 2019 01:55:52 -0000 did not get a lot of feedback on list. but it may be worth a few minutes of discussion in praha if there is room on the agenda. maybe it will move things along if i ask to adopt; so i hereby do so. randy Date: Mon, 28 Jan 2019 14:05:17 -0800 Message-ID: From: Randy Bush To: SIDR Operations WG Subject: [Sidrops] draft-ymbk-sidrops-ov-signal-02.txt i would like to put draft-ymbk-sidrops-ov-signal-02.txt on the agenda for praha. discussion so far: there was one red herring; outsourcing security. as this was discussed in the draft, i can only assume actual reading helped. the substantial issues raised in the meeting (i found nothing in the mailing list archives) seems to be the signaling/transport. let's focus on this. these seem to be three general alternatives for signaling. in-band, as described in the draft, uses an extended community. alternatively it could use a new attribute or other hack. such alternative in-band mechanisms could be discussed/investigated. a new afi/safi, which did not get rousing support from router implementors who would have to create and support a whole new afi/safi for the task. of course, creative folk could undoubtedly find more things to do with the new afi/safi if they get bored with bgp-ls:) augment the rpki-rtr protocol to allow the router to signal back to the cache one or more invalid routes. but then what happens with those data? if the cache will signal those to router clients, then those router clients will have done the evaluation on their own. these are the thoughts which led us to in-band signaling. but this is certainly worth discussing, here, praha, or both. randy From nobody Sun Mar 10 14:32:49 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 1B9B2127287; Sun, 10 Mar 2019 14:32:41 -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.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <155225356107.31077.16960403617069962439@ietfa.amsl.com> Date: Sun, 10 Mar 2019 14:32:41 -0700 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-lta-use-cases-05.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: Sun, 10 Mar 2019 21:32: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 : Use Cases for Localized Versions of the RPKI Author : Randy Bush Filename : draft-ietf-sidrops-lta-use-cases-05.txt Pages : 6 Date : 2019-03-10 Abstract: There are a number of critical circumstances where a localized routing domain needs to augment or modify its view of the Global RPKI. This document attempts to outline a few of them. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-lta-use-cases/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-lta-use-cases-05 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-lta-use-cases-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-lta-use-cases-05 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 Sun Mar 10 15:22: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 F0D7412797A; Sun, 10 Mar 2019 15:21:55 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 AguQ1c6Qlpl5; Sun, 10 Mar 2019 15:21:52 -0700 (PDT) Received: from mail-it1-x12b.google.com (mail-it1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 5EEFA12D4EB; Sun, 10 Mar 2019 15:21:52 -0700 (PDT) Received: by mail-it1-x12b.google.com with SMTP id f186so11129921ita.0; Sun, 10 Mar 2019 15:21:52 -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=q2GrltMy7X9BSkghaji58GdDY4nW2HfJ3hrR3Dgfo6w=; b=ALJGUY8hYkFQ93OVPcHq08K0Iby821EDg6GurAjKJhYqOOYIqjqEWLlB6zAp3oHOFu XpkbhSze8L4ds3JMVAlLrVAT28abflCTSOoTr3eHX7mzIewfrKJ7y2a6j2Y96hAcZ9Eg Bgws5au0rc1E1l/wltnjmF/fLFJ5IW5VItQ0y09w10GF0Lz/SQmyjeiLmViCKUBYV/Cf +MC596hih6PDjwwp4bR5OTCQPieOQdCkBiipK53CIEEGZ+4bRniDykRrYsKPadS8rhTN mPFh95RygMo4ghpQK3Rm5i6T2n+3R4FJnry3falivEKiIgDZn/O4wAe32moskyME9mSE ftcg== 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=q2GrltMy7X9BSkghaji58GdDY4nW2HfJ3hrR3Dgfo6w=; b=spOSKyXjNvPPvV+EJP13A0PU5/pSFNhAj3QBHVEY1dvbyjO4O2bbfzcLUKCYdl4SV2 QCiHlsCYGpYPbhdP/Vli7hnz1shFW/pAv/S9uULZ+2S3WJSYYwOEW+sjv7Q0pD74pKXd vbHwmv97lL1g2LDvQ9QgjaT+vxpmrrZyXh5Qwq3OqQYAqhkcuqkCwdYy+P8PJslCJhnv IUm43EowdyP607ZTBRFWgAtiUpjBWlHeUfa1UwW+C8h7HfVpiT1Iwihg/wieCa0MOOry DdmC0gSuVREzXQzhvi+4mEm40YwBKkHbd86cn18MaY6nGfUwmucCo5GKN+Glq99Xd/Sm mBKw== X-Gm-Message-State: APjAAAWBg2PAGtgZkGaqe9YjsvdJlrVBfUEkp8DdPDhBfTvnRZXD+ndK be4kMoPTba44xlci/HloqOcEBMZtCkmyXR0CrNM= X-Google-Smtp-Source: APXvYqxY/fXggUpbHrS3HDv+3wTebLjSFL3TxhCbrATzYEcw+br8ltPXTnBrbe3SUH6dkpB+LuJUYMO7Dguni8pnM38= X-Received: by 2002:a24:79d1:: with SMTP id z200mr15476979itc.53.1552256511429; Sun, 10 Mar 2019 15:21:51 -0700 (PDT) MIME-Version: 1.0 References: <154656623575.29677.9867680687994360294.idtracker@ietfa.amsl.com> <3321b6de-ef69-5d3c-b4b0-31865ddca224@foobar.org> <096ED0B2-1FBC-4CDC-B73D-28D61F08AC24@rpstir.net> In-Reply-To: <096ED0B2-1FBC-4CDC-B73D-28D61F08AC24@rpstir.net> From: Christopher Morrow Date: Sun, 10 Mar 2019 18:21:40 -0400 Message-ID: To: Di Ma Cc: Nick Hilliard , Chris Morrow , SIDROps Chairs , SIDR Operations WG , IESG_Secretary , Warren Kumari Content-Type: multipart/alternative; boundary="000000000000f6d37c0583c4e131" Archived-At: Subject: Re: [Sidrops] Publication has been requested for draft-ietf-sidrops-lta-use-cases-04 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, 10 Mar 2019 22:22:06 -0000 --000000000000f6d37c0583c4e131 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable howdy! I think the authors/objectors reached a conclusion on their differences... That is reflected in today's draft update to drafting system= : https://tools.ietf.org/html/draft-ietf-sidrops-lta-use-cases - v05 Let's poke/poke the buttons and move this back into IESG hands (which I'm doing now). On Sat, Jan 12, 2019 at 5:44 PM Di Ma wrote: > Nick, > > > =E5=9C=A8 2019=E5=B9=B41=E6=9C=8813=E6=97=A5=EF=BC=8C06:20=EF=BC=8CNick= Hilliard =E5=86=99=E9=81=93=EF=BC=9A > > > > Warren Kumari wrote on 12/01/2019 18:49: > >> I'm returning this document to the Working Group because I do not see > sufficient evidence of consensus. > >> With no hats - I personally believe that documenting the use cases is > useful, and would like to see this / a document describe the operational > practices of having a local TA. > > > > this is likely to be useful from the point of view of dealing with long > term concerns about centralisation of control of the global routing > infrastructure, that have been aired from time to time in various fora, > both private and public. The three example cases are realistic (cf: RIPE > NCC court order regarding registration of resources in 2011). > > > > It would also be important to note that the local trust anchor mechanis= m > suggested here could also be created to override legitimate announcements= , > e.g. states who wish to control the routing tables of service providers i= n > their legal jurisdiction. Knives make no judgement about what they cut > through. > > > > I support publication of the draft. It may need more content, e.g. > description of methods to implement the ideas that it suggests. > > > There is a standardized way to do so, as specified by RFC 8416, called > SLURM, which by the way has been supported by some RP software such as > Routinator and RPSTIR. > > I agree with what Steve suggested, draft-ietf-sidrops-lta-use-cases shoul= d > cite SLURM. > > > Di > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > --000000000000f6d37c0583c4e131 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
howdy! I think the authors/objectors reac= hed a conclusion on their differences... That is reflected in today's d= raft update to drafting system:
=C2=A0 =C2=A0https://tools.ietf.org/html/d= raft-ietf-sidrops-lta-use-cases - v05

<= div>Let's poke/poke the buttons and move this back into IESG hands (whi= ch I'm doing now).

On Sat, Jan 12, 2019 at 5:44 PM Di Ma <madi@rpstir.net> wrote:
Nick,

> =E5=9C=A8 2019=E5=B9=B41=E6=9C=8813=E6=97=A5=EF=BC=8C06:20=EF=BC=8CNic= k Hilliard <nick@fo= obar.org> =E5=86=99=E9=81=93=EF=BC=9A
>
> Warren Kumari wrote on 12/01/2019 18:49:
>> I'm returning this document to the Working Group because I do = not see sufficient evidence of consensus.
>> With no hats - I personally believe that documenting the use cases= is useful, and would like to see this / a document describe the operationa= l practices of having a local TA.
>
> this is likely to be useful from the point of view of dealing with lon= g term concerns about centralisation of control of the global routing infra= structure, that have been aired from time to time in various fora, both pri= vate and public.=C2=A0 The three example cases are realistic (cf: RIPE NCC = court order regarding registration of resources in 2011).
>
> It would also be important to note that the local trust anchor mechani= sm suggested here could also be created to override legitimate announcement= s, e.g. states who wish to control the routing tables of service providers = in their legal jurisdiction.=C2=A0 Knives make no judgement about what they= cut through.
>
> I support publication of the draft.=C2=A0 It may need more content, e.= g. description of methods to implement the ideas that it suggests.


There is a standardized way to do so, as specified by RFC 8416, called SLUR= M, which by the way has been supported by some RP software such as Routinat= or and RPSTIR.

I agree with what Steve suggested, draft-ietf-sidrops-lta-use-cases should = cite SLURM.


Di
_______________________________________________
Sidrops mailing list
Sidrops@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sidrops
--000000000000f6d37c0583c4e131-- From nobody Tue Mar 12 06:17: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 24BE71310EA for ; Tue, 12 Mar 2019 06:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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=verizon.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 kHXRdqlFIbmz for ; Tue, 12 Mar 2019 06:17:06 -0700 (PDT) Received: from sonic309-13.consmr.mail.bf2.yahoo.com (sonic309-13.consmr.mail.bf2.yahoo.com [74.6.129.123]) (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 80CB61310C1 for ; Tue, 12 Mar 2019 06:17:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1552396624; bh=Qh/A0uQYDlILy/Bwuwu57yMZbxA5oCmhRALMegADLK8=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=MDAkn/rqWMhvpXo0bd8t5OQXUJIdR12sI7goS1AUlEuC1Gma2aOV+uOcjqnhegAp3ll6m7HiVQ/xciRC/LrlFHkvkKtdD0BM3aQ9gPHCvw1mAHzvdiqM7oJIVmi6O5EL4jff0wqaXrxObzV2gg9u/u+PHFx61y9f+ie/PCCEPI4ZleW/k/N4qrw3Yd8aeQgF76z/rH7IhhUkH2T1PpTYZDj4FXZuoPogDSwzDzeZ9CZ4Z0kM3+yfhJsrJ7nQ6JHwQGySM4wrtyVYKtq7Fj6VXDk1qL/0zq//lpHQGf3Ngwcn3608btCqdA16YV2E6BgPsnYWSey++XpDyk+scxvSDA== X-YMail-OSG: CsFsaxsVM1kZapcflerj.wp300CMJNY2uGO08nMu73Jr_ewnedZUV.eETe_v0CW a.6hqC7YK.5eaEq6TwDo5iwOG0SyHelK8HUA1WmvjFAHXQMZAGff.3dS61X6Ijab4GPDWruuJZM4 ASbe3FmlLPR20AR4dN.7PDY5ezkyeMgrn56gogSYunwDQlqrbedsgoTPH9LldgyfAV_hC4S4YpX1 yQjmcRushvUHv.IcNmz6852UJcKKw8G7zEvbHR.AhKhV7vH1w4hzyfpv4LxWgSKwRfB2RDcYR1Gk UA5NMs7KNm.U3ePHeLL9Pa5w.Bi9PgDqewA7S9x8CWH35ctB.lk9ef20oNH1JUQ9oZZNQP0otS_G AH_dJJ_rdzR_MyocMxN162drBXMi.lOEEC9LN6XeMn86cojxouM_MFSAhds8IrmtiXmiub8mhGf7 Bduhw9T6nYuSmP6CyFxUv3rofsQjqIuaXNupx17jUu0NC_ZxPpr4sHrJ5ZOOYvt1ax7Iw8HoqF5L LDDOkXvxdDPSme9J2BJxCXfyuQm_1Pcbse2jGtLZgC31W8Dl6m.QVgrBUWpsc1HrWDqOOiyYdOcp V5Hv84q28WpmGfaDmjW_FxVtpWPwp5RBlvKGBaBMn4mHHZcA_AnQ7iMNgtAZwd1zbQpYNM6G6JbF PgDSMqdMLnooYeTUonOzFeX__lZEkI1SfgK_6eCj_BvoDIwUY4959u8dibwPnd6w1lCzobQPmX_. 38Da0qyavZiVR4W6.KjmopWUqg_v1t_mMKFE9vIrVSxwMkdok0U27TN9gpgdU4zT8OXkJuIcxZFh HyQh1DI6vzeEjElV99rKGa85PHx5wQqxQzhuOUurkQLOYQzS0U15hI_QZejB82rEtgoUY9AGrN_D 4IBbeO1c6ldKqELGc8CcUzduRpUFU6qWpW4YWkNBzUtU8fl5jOtB0ANIeJdXAsY_vLixTkNVdFVU L0xS0lGT.E3lxSALsGgLhW7VHIeVaVYcSpAJ0ybsxEgnTpK5FmWgcZNUbDXvq3Os8fwL0h_i8d41 sAds8LG5AJidenIOruW1C.ZhcaXljIGdIHCcNHVDf.R.UcLEgwp8twy5uafPxTA6rjw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.bf2.yahoo.com with HTTP; Tue, 12 Mar 2019 13:17:04 +0000 Received: from pool-71-184-117-160.bstnma.fios.verizon.net (EHLO iMac-Study.local) ([71.184.117.160]) by smtp407.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID e1e8b5dfcda8f79f6fd5b17ceb70c595 for ; Tue, 12 Mar 2019 13:17:00 +0000 (UTC) To: sidrops@ietf.org References: <154656623575.29677.9867680687994360294.idtracker@ietfa.amsl.com> <3321b6de-ef69-5d3c-b4b0-31865ddca224@foobar.org> <096ED0B2-1FBC-4CDC-B73D-28D61F08AC24@rpstir.net> From: Stephen Kent Message-ID: Date: Tue, 12 Mar 2019 09:16:59 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------BAF2B6928D18A43A6ECFCCF7" Content-Language: en-US Archived-At: Subject: Re: [Sidrops] Publication has been requested for draft-ietf-sidrops-lta-use-cases-04 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, 12 Mar 2019 13:17:13 -0000 This is a multi-part message in MIME format. --------------BAF2B6928D18A43A6ECFCCF7 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Chris, I agree that this version is much better now that it cites SLURM and avoids statements about how one might have to deal with TAs, etc. It would be even better if the comment " ... addresses many, but not all, of these issues and approaches." specified what issues SLURM does and does not address. Steve > howdy! I think the authors/objectors reached a conclusion on their > differences... That is reflected in today's draft update to drafting > system: > https://tools.ietf.org/html/draft-ietf-sidrops-lta-use-cases - v05 > > Let's poke/poke the buttons and move this back into IESG hands (which > I'm doing now). --------------BAF2B6928D18A43A6ECFCCF7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Chris,


I agree that this version is much better now that it cites SLURM and avoids statements about how one might have to deal with TAs, etc. It would be even better if the comment " ... addresses many, but not all, of these issues and approaches." specified what issues SLURM does and does not address.


Steve

howdy! I think the authors/objectors reached a conclusion on their differences... That is reflected in today's draft update to drafting system:
   https://tools.ietf.org/html/draft-ietf-sidrops-lta-use-cases - v05

Let's poke/poke the buttons and move this back into IESG hands (which I'm doing now).

--------------BAF2B6928D18A43A6ECFCCF7-- From nobody Sat Mar 16 23:02:51 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 49744131154; Sat, 16 Mar 2019 23:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 QBIlu8Rx74UP; Sat, 16 Mar 2019 23:02:38 -0700 (PDT) Received: from out20-1.mail.aliyun.com (out20-1.mail.aliyun.com [115.124.20.1]) (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 1C2F712872C; Sat, 16 Mar 2019 23:02:36 -0700 (PDT) X-Alimail-AntiSpam: AC=CONTINUE; BC=0.4351929|-1; CH=green; DM=CONTINUE|CONTINUE|true|0.323792-0.0462232-0.629984; FP=4432649059179814557|1|1|4|0|-1|-1|-1; HT=e01l01425; MF=madi@rpstir.net; NM=1; PH=DS; RN=5; RT=5; SR=0; TI=SMTPD_---.E954MDF_1552802551; Received: from 192.168.3.18(mailfrom:madi@rpstir.net fp:SMTPD_---.E954MDF_1552802551) by smtp.aliyun-inc.com(10.147.42.16); Sun, 17 Mar 2019 14:02:33 +0800 From: Di Ma Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-Id: Date: Sun, 17 Mar 2019 14:02:30 +0800 Cc: SIDR Operations WG , Chris Morrow , Keyur Patel , Stephen Kent To: SIDROps Chairs X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: [Sidrops] WGLC request for draft-ietf-sidrops-rp 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, 17 Mar 2019 06:02:39 -0000 Chairs, We authors believe this document is ready for WGLC, going through sidr = and sidrops discussions since IETF 95.=20 Please consider this is a formal request for initiating WGLC, to = encourage additional review for this document. Di From nobody Sun Mar 17 01:26: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 58BF3128B33; Sun, 17 Mar 2019 01:26:38 -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_PASS=-0.001, URIBL_BLOCKED=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 dnEC_F06q7JL; Sun, 17 Mar 2019 01:26:36 -0700 (PDT) Received: from relay.kvm02.ops-netman.net (relay.kvm02.ops-netman.net [IPv6:2606:700:e:550:5c82:28ff:fe25:4960]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD4251287C2; Sun, 17 Mar 2019 01:26:36 -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 0FD6B3FE8A; Sun, 17 Mar 2019 08:26:35 +0000 (UTC) Received: from morrowc-glaptop2.ops-netman.net (unknown [62.168.35.69]) (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 40CB0348C7741; Sun, 17 Mar 2019 08:26:33 +0000 (UTC) Authentication-Results: mail.ops-netman.net; dkim=none reason="no signature"; dkim-adsp=fail (unprotected policy); dkim-atps=neutral Date: Sun, 17 Mar 2019 01:26:31 -0700 Message-ID: From: Chris Morrow To: Di Ma Cc: SIDROps Chairs , SIDR Operations WG , Chris Morrow , Keyur Patel , Stephen Kent In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.1 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: Re: [Sidrops] WGLC request for draft-ietf-sidrops-rp 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, 17 Mar 2019 08:26:38 -0000 On Sat, 16 Mar 2019 23:02:30 -0700, Di Ma wrote: > > Chairs, > > We authors believe this document is ready for WGLC, going through > sidr and sidrops discussions since IETF 95. > > Please consider this is a formal request for initiating WGLC, to > encourage additional review for this document. This seems reasonable to me... I'll attempt to send this today :) -chris (as always if this lags more than a day or so please yell) From nobody Sun Mar 17 01:42:23 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 46B541287C2; Sun, 17 Mar 2019 01:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, 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 ZMUOU4t7VefJ; Sun, 17 Mar 2019 01:42:20 -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 8CAA2128B33; Sun, 17 Mar 2019 01:42:20 -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 0B3623FE8A; Sun, 17 Mar 2019 08:42:19 +0000 (UTC) Received: from morrowc-glaptop2.ops-netman.net (unknown [62.168.35.69]) (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 1D3FB348D1A1F; Sun, 17 Mar 2019 08:42:18 +0000 (UTC) Authentication-Results: mail.ops-netman.net; dkim=none reason="no signature"; dkim-adsp=fail (unprotected policy); dkim-atps=neutral Date: Sun, 17 Mar 2019 01:42:15 -0700 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.1 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] [WGLC] draft-ietf-sidrops-rp - ENDS: Mar 7, 2019 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, 17 Mar 2019 08:42:22 -0000 Howdy WG Folken, The authors of: draft-ietf-sidrops-rp are interested in moving their document forward, the abstract of this document: "This document provides a single reference point for requirements for Relying Party (RP) software for use in the Resource Public Key Infrastructure (RPKI) in the context of securing Internet routing. It cites requirements that appear in several RPKI RFCs, making it easier for implementers to become aware of these requirements that are segmented with orthogonal functionalities." Please have a read through this document, comment/complain/etc as appropriate. The decision on forward progress or necessary edits ends Mar 07, 2019. Thanks! -chris (co-chair) From nobody Sun Mar 17 01:42: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 9F96B128B33; Sun, 17 Mar 2019 01:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, 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 woac0nzaQf-V; Sun, 17 Mar 2019 01:42:50 -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 900FE12716C; Sun, 17 Mar 2019 01:42:50 -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 B94C23FE8A; Sun, 17 Mar 2019 08:42:49 +0000 (UTC) Received: from morrowc-glaptop2.ops-netman.net (unknown [62.168.35.69]) (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 C2031348D1A51; Sun, 17 Mar 2019 08:42:48 +0000 (UTC) Authentication-Results: mail.ops-netman.net; dkim=none reason="no signature"; dkim-adsp=fail (unprotected policy); dkim-atps=neutral Date: Sun, 17 Mar 2019 01:42:46 -0700 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.1 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] [WGLC] draft-ietf-sidrops-rp - ENDS: Mar 7, 2019 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, 17 Mar 2019 08:42:52 -0000 Howdy WG Folken, The authors of: draft-ietf-sidrops-rp are interested in moving their document forward, the abstract of this document: "This document provides a single reference point for requirements for Relying Party (RP) software for use in the Resource Public Key Infrastructure (RPKI) in the context of securing Internet routing. It cites requirements that appear in several RPKI RFCs, making it easier for implementers to become aware of these requirements that are segmented with orthogonal functionalities." Please have a read through this document, comment/complain/etc as appropriate. The decision on forward progress or necessary edits ends Mar 07, 2019. Thanks! -chris (co-chair) From nobody Sun Mar 17 04:15: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 7FA36127978; Sun, 17 Mar 2019 04:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, 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 j8VeBl4vBLQc; Sun, 17 Mar 2019 04:15:48 -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 155BE1275E9; Sun, 17 Mar 2019 04:15:47 -0700 (PDT) X-Envelope-To: sidrops@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id x2HBFiA9088760 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Mar 2019 11:15:44 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local To: Chris Morrow Cc: sidrops@ietf.org, sidrops-chairs@ietf.org, sidrops-ads@ietf.org References: From: Nick Hilliard Message-ID: Date: Sun, 17 Mar 2019 11:15:42 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 PostboxApp/6.1.12 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Sidrops] [WGLC] draft-ietf-sidrops-rp - ENDS: Mar 7, 2019 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, 17 Mar 2019 11:15:51 -0000 Chris Morrow wrote on 17/03/2019 08:42: > Please have a read through this document, comment/complain/etc as > appropriate. The decision on forward progress or necessary edits ends > Mar 07, 2019. Mar 7? That doesn't leave much time. Overall this looks like a useful summary for RP implementers, but care will need to be taken in future to ensure that the doc is kept current. Is the draft missing a reference to rfc 8416? The document needs a multiple-pass edit for both style and grammar before it can be handed off to the RFC Editor. I had a look at this earlier today, but there's too much to handle in an email - it needs someone to sit down with the xml source and spend a couple of hours hacking at it. Nick From nobody Sun Mar 17 06:22: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 B793B130E94; Sun, 17 Mar 2019 06:22:42 -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_PASS=-0.001, URIBL_BLOCKED=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 hpBFMxtZprIx; Sun, 17 Mar 2019 06:22:41 -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 65996130DE9; Sun, 17 Mar 2019 06:22:41 -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 6FA763FE8A; Sun, 17 Mar 2019 13:22:39 +0000 (UTC) Received: from morrowc-glaptop2.ops-netman.net (unknown [62.168.35.66]) (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 BE7273498C607; Sun, 17 Mar 2019 13:22:37 +0000 (UTC) Authentication-Results: mail.ops-netman.net; dkim=none reason="no signature"; dkim-adsp=fail (unprotected policy); dkim-atps=neutral Date: Sun, 17 Mar 2019 06:22:30 -0700 Message-ID: From: Chris Morrow To: Nick Hilliard Cc: Chris Morrow , sidrops@ietf.org, sidrops-chairs@ietf.org, sidrops-ads@ietf.org In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.1 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: Re: [Sidrops] [WGLC] draft-ietf-sidrops-rp - ENDS: April 7, 2019 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, 17 Mar 2019 13:22:43 -0000 On Sun, 17 Mar 2019 04:15:42 -0700, Nick Hilliard wrote: > > Chris Morrow wrote on 17/03/2019 08:42: > > Please have a read through this document, comment/complain/etc as > > appropriate. The decision on forward progress or necessary edits ends > > Mar 07, 2019. > > Mar 7? That doesn't leave much time. darned calendars :( April 7 !! :) > > Overall this looks like a useful summary for RP implementers, but care > will need to be taken in future to ensure that the doc is kept > current. > > Is the draft missing a reference to rfc 8416? > > The document needs a multiple-pass edit for both style and grammar > before it can be handed off to the RFC Editor. I had a look at this > earlier today, but there's too much to handle in an email - it needs > someone to sit down with the xml source and spend a couple of hours > hacking at it. > > Nick From nobody Mon Mar 18 03:19:31 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 6FB721228B7; Sun, 10 Mar 2019 15:23:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Chris Morrow via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Cc: sidrops-chairs@ietf.org, morrowc@ops-netman.net, sidrops@ietf.org, iesg-secretary@ietf.org, Chris Morrow Message-ID: <155225660145.31123.1445357722621909307.idtracker@ietfa.amsl.com> Date: Sun, 10 Mar 2019 15:23:21 -0700 Archived-At: X-Mailman-Approved-At: Mon, 18 Mar 2019 03:19:29 -0700 Subject: [Sidrops] Publication has been requested for draft-ietf-sidrops-lta-use-cases-05 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: Sun, 10 Mar 2019 22:23:22 -0000 Chris Morrow has requested publication of draft-ietf-sidrops-lta-use-cases-05 as Informational on behalf of the SIDROPS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-sidrops-lta-use-cases/ From nobody Mon Mar 18 03:19:36 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 E5CC9131038; Wed, 13 Mar 2019 08:39:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Francesca Palombini via Datatracker To: Cc: sidrops@ietf.org, ietf@ietf.org, draft-ietf-sidrops-bgpsec-algs-rfc8208-bis.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155249156086.27887.17276454493405406028@ietfa.amsl.com> Date: Wed, 13 Mar 2019 08:39:20 -0700 Archived-At: X-Mailman-Approved-At: Mon, 18 Mar 2019 03:19:29 -0700 Subject: [Sidrops] Genart last call review of draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-04 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: Wed, 13 Mar 2019 15:39:28 -0000 Reviewer: Francesca Palombini Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-04 Reviewer: Francesca Palombini Review Date: 2019-03-13 IETF LC End Date: 2019-03-18 IESG Telechat date: Not scheduled for a telechat Summary: This draft is ready for publication as a Proposed Standard RFC. Major issues: -- Minor issues: -- Nits/editorial comments: -- From nobody Mon Mar 18 03:19:42 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 5E190130E16; Mon, 18 Mar 2019 03:07:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Mehmet Ersue via Datatracker To: Cc: sidrops@ietf.org, ietf@ietf.org, draft-ietf-sidrops-bgpsec-algs-rfc8208-bis.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Mehmet Ersue Message-ID: <155290366133.26147.15826331095937544086@ietfa.amsl.com> Date: Mon, 18 Mar 2019 03:07:41 -0700 Archived-At: X-Mailman-Approved-At: Mon, 18 Mar 2019 03:19:29 -0700 Subject: [Sidrops] Opsdir last call review of draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-04 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, 18 Mar 2019 10:07:42 -0000 Reviewer: Mehmet Ersue Review result: Has Nits I reviewed the document "BGPsec Algorithms, Key Formats, and Signature Formats" (draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-04.txt) as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the operational area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Intended status: Standards Track Current IESG state: Waiting for Writeup IANA State: IANA - Review Needed Summary: The document specifies the algorithms, algorithm parameters, asymmetric key formats, asymmetric key sizes, and signature formats used in BGPsec. The document updates RFC 8208 ("BGPsec Algorithms, Key Formats, and Signature Formats") by adding Special-Use Algorithm IDs and correcting the range of unassigned algorithms IDs to fill the complete range. There are some nits in the document like - Normative reference to an Informational RFCs and - Non-RFC (?) normative references See https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-04.txt As far as I can tell the document does not cause any issues related to operations and management. Mehmet From nobody Mon Mar 18 05:41: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 3D7FC12799B; Mon, 18 Mar 2019 05:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 Gg8-_IFDP08L; Mon, 18 Mar 2019 05:41:10 -0700 (PDT) Received: from out20-74.mail.aliyun.com (out20-74.mail.aliyun.com [115.124.20.74]) (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 E6A2F127916; Mon, 18 Mar 2019 05:41:07 -0700 (PDT) X-Alimail-AntiSpam: AC=CONTINUE; BC=0.1289531|-1; CH=green; DM=CONTINUE|CONTINUE|true|0.339914-0.0401567-0.619929; FP=0|0|0|0|0|-1|-1|-1; HT=e02c03275; MF=madi@rpstir.net; NM=1; PH=DS; RN=5; RT=5; SR=0; TI=SMTPD_---.E9dVuXm_1552912861; Received: from 192.168.3.18(mailfrom:madi@rpstir.net fp:SMTPD_---.E9dVuXm_1552912861) by smtp.aliyun-inc.com(10.147.44.145); Mon, 18 Mar 2019 20:41:02 +0800 Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Di Ma In-Reply-To: Date: Mon, 18 Mar 2019 20:41:00 +0800 Cc: Chris Morrow , sidrops-chairs@ietf.org, sidrops@ietf.org, sidrops-ads@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7ED51F22-99D5-43E2-A12D-744A4AF15165@rpstir.net> References: To: Nick Hilliard X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Sidrops] [WGLC] draft-ietf-sidrops-rp - ENDS: Mar 7, 2019 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, 18 Mar 2019 12:41:15 -0000 Nick, > =D4=DA 2019=C4=EA3=D4=C217=C8=D5=A3=AC19:15=A3=ACNick Hilliard = =D0=B4=B5=C0=A3=BA >=20 > Chris Morrow wrote on 17/03/2019 08:42: >> Please have a read through this document, comment/complain/etc as >> appropriate. The decision on forward progress or necessary edits ends >> Mar 07, 2019. >=20 > Mar 7? That doesn't leave much time. >=20 > Overall this looks like a useful summary for RP implementers, but care = will need to be taken in future to ensure that the doc is kept current. You are making sense here in terms of keeping it current. We authors don=A1=AFt think this will be a big issue for this draft is = an informational document intended to provide readers a single point of = learning about the =A1=AEfundamental' functions that an RP should have = in the context of routing.=20 Since SIDR WG has been concluded, we don=A1=AFt expect many/frequent = changes regarding =A1=AEprotocol' that an RP should handle will take = place.=20 Granted, if there is going to be a fundamental change, this document = will be updated by the RFC that brings about the change as we see many = RFCs are being updated today. >=20 > Is the draft missing a reference to rfc 8416? Good point. We don=A1=AFt see RFC 8416 is a necessary functionality that an RP MUST = support since we expect draft-ietf-sidrops-rp is to gather = basic/necessary functions.=20 Yet we might as well mentioned RFC 8416 in case the reader wants to = acquire local control by using RFC 8416.=20 I am one of the co-authors of RFC 8416, happy to add it in :-) >=20 > The document needs a multiple-pass edit for both style and grammar = before it can be handed off to the RFC Editor. I had a look at this = earlier today, but there's too much to handle in an email - it needs = someone to sit down with the xml source and spend a couple of hours = hacking at it. We authors would appreciate very much if you may bother to help polish = this draft.=20 Thanks. Di >=20 > Nick >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Mon Mar 18 14:37:49 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 C3228131094; Mon, 18 Mar 2019 14:37:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Linda Dunbar via Datatracker To: Cc: draft-ietf-sidrops-https-tal.all@ietf.org, sidrops@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Linda Dunbar Message-ID: <155294505475.26094.8605317163998406572@ietfa.amsl.com> Date: Mon, 18 Mar 2019 14:37:34 -0700 Archived-At: Subject: [Sidrops] Opsdir last call review of draft-ietf-sidrops-https-tal-07 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, 18 Mar 2019 21:37:35 -0000 Reviewer: Linda Dunbar Review result: Has Nits Reviewer: Linda Dunbar Review result: Ready with Comments & Nits I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines the syntax of Trust Anchor Locator (TAL) for Replying Parties to retrieve the Trust Anchor, to avoid repeating the distribution procedure when Trust Anchor changes. My question: if the Trust Anchor changes, does the URI in the TAL changes? Another questions: Section 2.4 Example: is the Public Key listed there for both URI? Typo: Section 2.1 second paragraph: "without needing to effect..", do you mean "without needing to affect ..?? Cheers, Linda Dunbar From nobody Mon Mar 18 20:40: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 F074D1279A2; Mon, 18 Mar 2019 20:40:36 -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 qtcMZrbh097Z; Mon, 18 Mar 2019 20:40:35 -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 1350F127990; Mon, 18 Mar 2019 20:40:35 -0700 (PDT) Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 1079A8F9E8A1654B1FB7; Tue, 19 Mar 2019 03:40:33 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 19 Mar 2019 03:40:32 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0415.000; Tue, 19 Mar 2019 11:40:20 +0800 From: Zhuangshunwan To: Chris Morrow , "sidrops@ietf.org" , "sidrops-chairs@ietf.org" , "sidrops-ads@ietf.org" Thread-Topic: [Sidrops] [WGLC] draft-ietf-sidrops-rp - ENDS: Mar 7, 2019 Thread-Index: AQHU3J1hmdOs/WXLGkSH88b/R4CbKaYSS45w Date: Tue, 19 Mar 2019 03:40:19 +0000 Message-ID: <19AB2A007F56DB4E8257F949A2FB9858DC59D8E0@NKGEML515-MBX.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.130.202.166] 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] [WGLC] draft-ietf-sidrops-rp - ENDS: Mar 7, 2019 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, 19 Mar 2019 03:40:37 -0000 Support. As a developer of the routing device using the data from RP,=20 I think this is a very useful reference document.=20 It lets us know how RP works. Thanks, Shunwan -----Original Message----- From: Sidrops [mailto:sidrops-bounces@ietf.org] On Behalf Of Chris Morrow Sent: Sunday, March 17, 2019 4:42 PM To: sidrops@ietf.org; sidrops-chairs@ietf.org; sidrops-ads@ietf.org Subject: [Sidrops] [WGLC] draft-ietf-sidrops-rp - ENDS: Mar 7, 2019 Howdy WG Folken, The authors of: draft-ietf-sidrops-rp are interested in moving their document forward, the abstract of this document: "This document provides a single reference point for requirements for Relying Party (RP) software for use in the Resource Public Key Infrastructure (RPKI) in the context of securing Internet routing. It cites requirements that appear in several RPKI RFCs, making it easier for implementers to become aware of these requirements that are segmented with orthogonal functionalities." Please have a read through this document, comment/complain/etc as appropria= te. The decision on forward progress or necessary edits ends Mar 07, 2019. Thanks! -chris (co-chair) _______________________________________________ Sidrops mailing list Sidrops@ietf.org https://www.ietf.org/mailman/listinfo/sidrops From nobody Thu Mar 21 08:12:10 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 467751311C1; Thu, 21 Mar 2019 08:11:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Sender: CC: sidrops-chairs@ietf.org, sidrops@ietf.org, draft-ietf-sidrops-lta-use-cases@ietf.org, Chris Morrow , warren@kumari.net, morrowc@ops-netman.net Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <155318111927.9942.10080998154291244646.idtracker@ietfa.amsl.com> Date: Thu, 21 Mar 2019 08:11:59 -0700 Archived-At: Subject: [Sidrops] Last Call: (Use Cases for Localized Versions of the RPKI) to Informational RFC 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: Thu, 21 Mar 2019 15:12:02 -0000 The IESG has received a request from the SIDR Operations WG (sidrops) to consider the following document: - 'Use Cases for Localized Versions of the RPKI' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-04-11. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract There are a number of critical circumstances where a localized routing domain needs to augment or modify its view of the Global RPKI. This document attempts to outline a few of them. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-sidrops-lta-use-cases/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-sidrops-lta-use-cases/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Mar 21 08:14:57 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 3F361131279; Thu, 21 Mar 2019 08:14:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Sender: CC: sidrops-chairs@ietf.org, sidrops@ietf.org, draft-ietf-sidrops-lta-use-cases@ietf.org, Chris Morrow , warren@kumari.net, morrowc@ops-netman.net Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <155318128824.9969.11777670669810167436.idtracker@ietfa.amsl.com> Date: Thu, 21 Mar 2019 08:14:48 -0700 Archived-At: Subject: [Sidrops] Last Call: (Use Cases for Localized Versions of the RPKI) to Informational RFC 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: Thu, 21 Mar 2019 15:14:56 -0000 The IESG has received a request from the SIDR Operations WG (sidrops) to consider the following document: - 'Use Cases for Localized Versions of the RPKI' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-04-11. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract There are a number of critical circumstances where a localized routing domain needs to augment or modify its view of the Global RPKI. This document attempts to outline a few of them. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-sidrops-lta-use-cases/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-sidrops-lta-use-cases/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Mar 22 03:24: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 6B1FE130EBF for ; Fri, 22 Mar 2019 03:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 TFjV8Gm9pttB for ; Fri, 22 Mar 2019 03:24:05 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 1D9D81310A2 for ; Fri, 22 Mar 2019 03:24:01 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id t13so1579304lji.2 for ; Fri, 22 Mar 2019 03:24:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=771zY9fT2VZuD0HwkYWxZ+nFi82TboORfbTII6GQ0Mg=; b=pJO9n2h2Gvhwi4hqg0KrIOI7jHgCYKLptl9NmI3hhynBcicwc48HE8KbZ3std/IzPo OrTQ1zHc9tvFGeOpOY96j4CkxrUJn4yAP2LFDaN+dd6bITej0iLp6XdeNrVUZkhqKcnH KvkSnlJWMIiWs43EXqCPM5J7FjGcIkuVGf1xs7TAFthfZm3atvVG3hXMvarpFAnnYX0Y YYnhzraryrInCUcVji21Q82R4JGrdPXSrZgmO//MazVH91RWf/Xpru3Fo9DjfQrssqJW J3pxo4mcRJhoP+l2aapymnc2TaeyrOGC26onACX3rPB+coWUE40S9jzFO+Bpgmh2GB/s gRmQ== 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=771zY9fT2VZuD0HwkYWxZ+nFi82TboORfbTII6GQ0Mg=; b=s9evndwRi7WRIY80ROiwOsrJw7q+FrFkVij1cChiWRNrmaWTvo/4PksmwUReqMiZWs 0VDY02eN34V838L7QZgJf2RxohDQDC0pFCuONpcjqRMVW8uPnkiJNQkwmbq0oMsHd1cd 7e4T8zh5XubnRPomzarJP4lFECq8X630EiwgEnJn26vLM2uQhLAl23v8S/0/nbv/3/ip LyyF8nr0JVFDdByyD0LUesMaISKlclvxDREUC6EKS9PEnDRP6ielsymk6HzzXVuNouPb EuzbHCb3Vy6zrkRPT9yDyWGYLQb14pB7bXmuJqREE/4kodpXoRflN2wkdbss22v2z6AK GBCg== X-Gm-Message-State: APjAAAXBqv4BxRUueGrJcjAl3fvRhIkEXNiXNw6cyHxfWjFIPWYnQNw0 /wH3koC8qk3Qek8u/MCLDKUloNz/3cV949ZUuKjKGw== X-Google-Smtp-Source: APXvYqwxDXmOwH4eZr4IwO31omGoYxQ4Ry4NayxIxMGrAZzmb/hYqm0H6WMZuCQPRHX/DzCIypM7WgabfazOFWsA778= X-Received: by 2002:a2e:8050:: with SMTP id p16mr4943072ljg.160.1553250239054; Fri, 22 Mar 2019 03:23:59 -0700 (PDT) MIME-Version: 1.0 References: <154830586386.7517.12515642346949342885.idtracker@ietfa.amsl.com> <587443F2-D022-4109-AFF7-E6C06091E151@sn3rd.com> In-Reply-To: <587443F2-D022-4109-AFF7-E6C06091E151@sn3rd.com> From: Eric Rescorla Date: Fri, 22 Mar 2019 03:23:22 -0700 Message-ID: To: Sean Turner Cc: Alissa Cooper , The IESG , SIDROps Chairs , Chris Morrow , SIDR Operations WG , draft-ietf-sidrops-rtr-keying@ietf.org Content-Type: multipart/alternative; boundary="000000000000bf198c0584ac40c3" Archived-At: Subject: Re: [Sidrops] Eric Rescorla's Discuss on draft-ietf-sidrops-rtr-keying-03: (with DISCUSS and COMMENT) 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, 22 Mar 2019 10:24:18 -0000 --000000000000bf198c0584ac40c3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 12, 2019 at 6:25 PM Sean Turner wrote: > > > > On Jan 23, 2019, at 23:57, Eric Rescorla wrote: > > > > Eric Rescorla has entered the following ballot position for > > draft-ietf-sidrops-rtr-keying-03: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > Rich version of this review at: > > https://mozphab-ietf.devsvcdev.mozaws.net/D13996 > > > > > > > > DETAIL > > S 2. > >> > >> Operators are free to use either the router-driven or > operator-driven > >> method as supported by the platform. Regardless of the method > >> chosen, operators first establish a protected channel between the > >> management system and the router. How this protected channel is > >> established is router-specific and is beyond scope of this documen= t. > > > > This seems rather under-specified. Given that we know that people are > > not careful about this, I think you need to specify some sort of > > minimum requirements for this channel. That need not be a particular > > protocol, but it needs to specify the security properties it provides. > > I see you have some SHOULD-level language later, but I think you need > > MUST level, and as noted below, I think the guidance is wrong. > > Alissa had a comment in the same vein so I hope to address both here. > > In the future, routers may come with key material burned into them that > the router can then use to securely communicate with the operator (e.g., > brewski or something akin to what=E2=80=99s in s8), but the reality is th= at the > routers arrive with nada on them. So, s2 is about how the operator gets > keying material into the router that it can then later use to secure > communications with the operator. There=E2=80=99s two ways to get this d= one and > there=E2=80=99s an initial leap of faith that has to happen (i.e., there= =E2=80=99s -no- > security on first connect): > > - the operator connects directly through the =E2=80=9Ccraft=E2=80=9D port= and =E2=80=9Csquirts=E2=80=9D > the keying material in and configures the router to use SSH (or whatever) > for future connections. It=E2=80=99s also going to set up it=E2=80=99s A= S number and > whatever else goes in the config file to make the protocol run. > > - the operator connects over a network port and squirts the keying > material in and configures the router to use SSH (or whatever) for future > connections. But, chances are very high that the operator connects to th= e > router via SSH, and probably with some generic lame pwd. > > So while I agree we want to better specify what kind of protections this > channel should provide I am unsure what to write if the router has no > keying material whatsoever when the operator gets first it. > OK. I think you need to lay this out in the text in more detail, but I'll trust you to do it. > > S 5.2. > >> the BGP Identifier when it sends the CSR to the CA. > >> > >> Even if the operator cannot extract the private key from the route= r, > >> this signature still provides a linkage between a private key and = a > >> router. That is, the operator can verify the proof of possession > >> (POP), as required by [RFC6484]. > > > > It's not clear to me what is being claimed in terms of PoP here. As I > > understand it, the certificate is a binding between the AS number/BGP > > identifier pair and the public key, but if neither of those is in the > > PKCS#10 request, then they're not signed over by the private key, and > > so PoP isn't really operative. The relevant question is whether if I > > obtain the PKCS#10 request I can obtain a certificate for an identity > > other than the intended one. > > 1st baed on somebody else=E2=80=99s comment we=E2=80=99re moving that par= agraph to s5.1. > It=E2=80=99s out of place in s5.2 because If the operator can generate th= e key well > they certainly have access to it. > > The POP we=E2=80=99re getting is that the router has the key. If there= =E2=80=99s nothing > in the CSR but the operator is the middle-man then the operator can tell > the CA this CSR goes with this name though some other means. > But this *isn't* PoP because you can transplant the CSR into another context. >> the CA prior to operator initiating the router's CSR. CAs use > >> authentication material to determine whether the router is > >> eligible to receive a certificate. Authentication material at = a > >> minimum includes the router's AS number and BGP Identifier as > >> well as the router's key material, but can also include > >> additional information. Authentication material can be > > > > Surely it also includes some information that allows the router to > > prove it is entitled to a key with that AS and BGP identifier, but I'm > > not seeing this here. > > I guess maybe I am confused because I thought that=E2=80=99s what the ent= ire > bullet was about. The operator is priming the CA with information that > will allow the router to begin contacting the CA without the operator in > the middle. > Yes, but my point is what ties this to the identity? Some account entry on the CA? > > S 1. > >> operator-driven method. Routers are required to support at least > one > >> of the methods in order to work in various deployment environments= . > >> Some routers may not allow the private key to be off-loaded while > >> others may. While off-loading private keys would ease swapping of > >> routing engines, exposure of private keys is a well known security > >> risk. > > > > This is a somewhat shallow treatment of this. Specifically: > > > > 1. There are multiple ways in which a device might allow a key not to > > be exported. For instance, there might not be a command, but it might > > be in unencrypted NVRAM. Or, it might be in an HSM. These have very > > different security properties. > > > > 2. There are designs which allow a key to be moved from device to > > device without exposure, e.g.,, a hardware token. > > I agree it=E2=80=99s a little/lot shallow, but I am not sure what digging= deeper > is going to accomplish here especially in the intro. > Well, my point is that it misrepresents the situation. OULD be commensurate with the strength of the BGPsec > > > > I'm not sure "commensurate" is what's needed here. For instance, the > > transport channel might be much more secure than the router key (e.g., > > P-521 and AES-256 with a RSA-2048 router key). > > > > More generally, it's not clear to me that these are really connected > > at all, as the threat environments are totally different. As noted > > above, I believe you should just specify a minimal level. > > Commensurate is probably the wrong word, I was shooting for "at least as > good as." > Yes. My point is that that is a bad requirement for the reasons above. -Ekr --000000000000bf198c0584ac40c3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Feb 12, 2019 at 6:25 PM Sean = Turner <sean@sn3rd.c= om> wrote:
ekr@rtfm.com> wrote:
>
> Eric Rescorla has entered the following ballot position for
> draft-ietf-sidrops-rtr-keying-03: Discuss
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc= /draft-ietf-sidrops-rtr-keying/
>
>
>
> ----------------------------------------------------------------------=
> DISCUSS:
> ----------------------------------------------------------------------=
>
> Rich version of this review at:
> https://mozphab-ietf.devsvcdev.mozaws.net/D1399= 6
>
>
>
> DETAIL
> S 2.
>>
>>=C2=A0 =C2=A0 =C2=A0Operators are free to use either the router-dri= ven or operator-driven
>>=C2=A0 =C2=A0 =C2=A0method as supported by the platform.=C2=A0 Rega= rdless of the method
>>=C2=A0 =C2=A0 =C2=A0chosen, operators first establish a protected c= hannel between the
>>=C2=A0 =C2=A0 =C2=A0management system and the router.=C2=A0 How thi= s protected channel is
>>=C2=A0 =C2=A0 =C2=A0established is router-specific and is beyond sc= ope of this document.
>
> This seems rather under-specified. Given that we know that people are<= br> > not careful about this, I think you need to specify some sort of
> minimum requirements for this channel. That need not be a particular > protocol, but it needs to specify the security properties it provides.=
> I see you have some SHOULD-level language later, but I think you need<= br> > MUST level, and as noted below, I think the guidance is wrong.

Alissa had a comment in the same vein so I hope to address both here.

In the future, routers may come with key material burned into them that the= router can then use to securely communicate with the operator (e.g., brews= ki or something akin to what=E2=80=99s in s8), but the reality is that the = routers arrive with nada on them.=C2=A0 So, s2 is about how the operator ge= ts keying material into the router that it can then later use to secure com= munications with the operator.=C2=A0 There=E2=80=99s two ways to get this d= one and there=E2=80=99s an initial leap of faith that has to happen (i.e., = there=E2=80=99s -no- security on first connect):

- the operator connects directly through the =E2=80=9Ccraft=E2=80=9D port a= nd =E2=80=9Csquirts=E2=80=9D the keying material in and configures the rout= er to use SSH (or whatever) for future connections.=C2=A0 It=E2=80=99s also= going to set up it=E2=80=99s AS number and whatever else goes in the confi= g file to make the protocol run.

- the operator connects over a network port and squirts the keying material= in and configures the router to use SSH (or whatever) for future connectio= ns.=C2=A0 But, chances are very high that the operator connects to the rout= er via SSH, and probably with some generic lame pwd.

So while I agree we want to better specify what kind of protections this ch= annel should provide I am unsure what to write if the router has no keying = material whatsoever when the operator gets first it.
<= br>
OK. I think you need to lay this out in the text in more deta= il, but I'll trust you to do it.


> S 5.2.
>>=C2=A0 =C2=A0 =C2=A0the BGP Identifier when it sends the CSR to the= CA.
>>
>>=C2=A0 =C2=A0 =C2=A0Even if the operator cannot extract the private= key from the router,
>>=C2=A0 =C2=A0 =C2=A0this signature still provides a linkage between= a private key and a
>>=C2=A0 =C2=A0 =C2=A0router.=C2=A0 That is, the operator can verify = the proof of possession
>>=C2=A0 =C2=A0 =C2=A0(POP), as required by [RFC6484].
>
> It's not clear to me what is being claimed in terms of PoP here. A= s I
> understand it, the certificate is a binding between the AS number/BGP<= br> > identifier pair and the public key, but if neither of those is in the<= br> > PKCS#10 request, then they're not signed over by the private key, = and
> so PoP isn't really operative. The relevant question is whether if= I
> obtain the PKCS#10 request I can obtain a certificate for an identity<= br> > other than the intended one.

1st baed on somebody else=E2=80=99s comment we=E2=80=99re moving that parag= raph to s5.1.=C2=A0 It=E2=80=99s out of place in s5.2 because If the operat= or can generate the key well they certainly have access to it.

The POP we=E2=80=99re getting is that the router has the key.=C2=A0 =C2=A0I= f there=E2=80=99s nothing in the CSR but the operator is the middle-man the= n the operator can tell the CA this CSR goes with this name though some oth= er means.

But this *isn't* PoP beca= use you can transplant the CSR into another context.

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the CA prior to operator initiati= ng the router's CSR.=C2=A0 CAs use
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0authentication material to determ= ine whether the router is
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0eligible to receive a certificate= . Authentication material at a
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0minimum includes the router's= AS number and BGP Identifier as
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0well as the router's key mate= rial, but can also include
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0additional information. Authentic= ation material can be
>
> Surely it also includes some information that allows the router to
> prove it is entitled to a key with that AS and BGP identifier, but I&#= 39;m
> not seeing this here.

I guess maybe I am confused because I thought that=E2=80=99s what the entir= e bullet was about.=C2=A0 The operator is priming the CA with information t= hat will allow the router to begin contacting the CA without the operator i= n the middle.

=C2=A0Yes, but my point i= s what ties this to the identity? Some account entry on the CA?
<= br>

> S 1.
>>=C2=A0 =C2=A0 =C2=A0operator-driven method.=C2=A0 Routers are requi= red to support at least one
>>=C2=A0 =C2=A0 =C2=A0of the methods in order to work in various depl= oyment environments.
>>=C2=A0 =C2=A0 =C2=A0Some routers may not allow the private key to b= e off-loaded while
>>=C2=A0 =C2=A0 =C2=A0others may.=C2=A0 While off-loading private key= s would ease swapping of
>>=C2=A0 =C2=A0 =C2=A0routing engines, exposure of private keys is a = well known security
>>=C2=A0 =C2=A0 =C2=A0risk.
>
> This is a somewhat shallow treatment of this. Specifically:
>
> 1. There are multiple ways in which a device might allow a key not to<= br> > be exported. For instance, there might not be a command, but it might<= br> > be in unencrypted NVRAM. Or, it might be in an HSM. These have very > different security properties.
>
> 2. There are designs which allow a key to be moved from device to
> device without exposure, e.g.,, a hardware token.

I agree it=E2=80=99s a little/lot shallow, but I am not sure what digging d= eeper is going to accomplish here especially in the intro.
=

Well, my point is that it misrepresents the situation. =

OULD be commensurate with the strength of the BGPsec
>
> I'm not sure "commensurate" is what's needed here. F= or instance, the
> transport channel might be much more secure than the router key (e.g.,=
> P-521 and AES-256 with a RSA-2048 router key).
>
> More generally, it's not clear to me that these are really connect= ed
> at all, as the threat environments are totally different. As noted
> above, I believe you should just specify a minimal level.

Commensurate is probably the wrong word, I was shooting for "at least = as good as."

Yes. My point is that= that is a bad requirement for the reasons above.

-Ekr<= /div>

--000000000000bf198c0584ac40c3-- From nobody Fri Mar 22 11:38:03 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 917B0131451; Fri, 22 Mar 2019 11:37:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Pete Resnick via Datatracker To: Cc: draft-ietf-sidrops-https-tal.all@ietf.org, sidrops@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Pete Resnick Message-ID: <155327986751.23063.11928780401443919371@ietfa.amsl.com> Date: Fri, 22 Mar 2019 11:37:47 -0700 Archived-At: Subject: [Sidrops] Genart last call review of draft-ietf-sidrops-https-tal-07 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: Fri, 22 Mar 2019 18:37:48 -0000 Reviewer: Pete Resnick Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-sidrops-https-tal-07 Reviewer: Pete Resnick Review Date: 2019-03-22 IETF LC End Date: 2019-03-18 IESG Telechat date: 2019-04-11 Summary: I MUST say that this document is quite MUSTy. I only noted those that caused me confusion or seemed useless. All of these are either minor issues or nits. Either way, the document is generally ready. Major issues: None. Minor issues (or might be nits): In 2.3: The validity interval of this trust anchor SHOULD reflect the anticipated period of stability... Are there cases where it wouldn't reflect the period of stability? If so, it would be good to give an example. If not, then s/SHOULD reflect/reflects. Similarly for: Thus, the entity that issues the trust anchor SHOULD issue a subordinate CA certificate that contains... In this case, that SHOULD might even be a MUST. In section 4, in the last full paragraph and the bullets, I'm not at all clear why these are RECOMMENDEDs and SHOULD [NOT]s. If they're not MUSTs, it seems like you should explain circumstances (at least in general terms) where an implementation would choose to do deviate from these. Nits/editorial comments: In the introduction, the "SHOULD" seems superfluous; it doesn't indicate some important implementation advice that someone wouldn't otherwise notice in the protocol. But it's a nit if ever there was one. From nobody Sun Mar 24 10:12:26 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 A6D611200D7; Sun, 24 Mar 2019 10:12:24 -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 fn08nWGC7NQb; Sun, 24 Mar 2019 10:12:22 -0700 (PDT) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (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 0A2DF127988; Sun, 24 Mar 2019 10:12:16 -0700 (PDT) Received: from [193.0.23.13] (helo=bufobufo.ripe.net) by molamola.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1h86fO-0000ot-NC; Sun, 24 Mar 2019 18:12:14 +0100 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:5009::e3]) by bufobufo.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1h86et-0005gO-Cr; Sun, 24 Mar 2019 18:11:43 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Oleg Muravskiy In-Reply-To: Date: Sun, 24 Mar 2019 18:11:42 +0100 Cc: sidrops-chairs@ietf.org, sidrops-ads@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: sidrops@ietf.org X-Mailer: Apple Mail (2.3445.102.3) X-ACL-Warn: Delaying message X-RIPE-Signature: c408758d4ce2e8eb06762a65a3365b74c1c43f0409e58a4ccb3d5195702f716d Archived-At: Subject: Re: [Sidrops] [WGLC] draft-ietf-sidrops-rp - ENDS: Mar 7, 2019 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, 24 Mar 2019 17:12:25 -0000 Here are my comments on this document. Most of them I already submitted = back in 2016 = (https://mailarchive.ietf.org/arch/msg/sidr/ThyvBuWdCnv2t9u86sOjwdV4xKc), = and authors seem to agreed to update the document, but that didn=E2=80=99t= happen: > 3.2. Certificate Path Validation >=20 > In the RPKI, issuer can only assign and/or allocate public INRs > belong to it, Assignment / allocation of INRs does not happen in RPKI. > 3.3. CRL Processing >=20 > The CRL processing requirements imposed on CAs and RP are described > in Section 5 of [RFC6487]. CRLs in the RPKI are tightly = constrained; > only the AuthorityKeyIndetifier and CRLNumber extensions are = allowed, > and they MUST be present. No other CRL extensions are allowed, and > no CRLEntry extensions are permitted. RPs are required to verify > that these constraints have been met. Each CRL in the RPKI MUST be > verified using the public key from the certificate of the CA that > issued the CRL. The normative language is used in an Informational document. > 4.2.2. ROA >=20 > To validate a ROA, the RP is required perform all the checks > specified in [RFC6488] as well as the additional ROA-specific > validation steps. The IP address delegation extension [RFC3779] > present in the end-entity (EE) certificate (contained within the > ROA), must encompass each of the IP address prefix(es) in the ROA. >=20 > More details for ROA validation are specified in Section 2 of > [RFC6482]. Section 2 of RFC6482 defines the ROA content-type, not the validation. > 4.2.3. Ghostbusters >=20 >=20 > The Ghostbusters Record is optional; a publication point in the = RPKI > can have zero or more associated Ghostbuster Records. Since no other CMS object description in this document mentions = object=E2=80=99s optionality, this sentence may be understood as that = the Ghostbusters Record is the only type of object which is optional. = This is not the case. > 4.3. How to Make Use of Manifest Data >=20 > For a given publication point, the RP ought to perform tests, as > specified in Section 6.1 of [RFC6486], to determine the state of = the > Manifest at the publication point. A Manifest can be classified as > either valid or invalid, and a valid Manifest is either current and > stale. An RP decides how to make use of a Manifest based on its > state, according to local (RP) policy. >=20 > If there are valid objects in a publication point that are not > present on a Manifest, [RFC6486] does not mandate specific RP > behavior with respect to such objects. However, most RP software > ignores such objects and this document recommends that this = behavior > be adopted uniformly. To my knowledge, most RP software notifies operator about presence of = such objects, not just ignores them. Also, I=E2=80=99m not sure how to treat =E2=80=9Crecommends=E2=80=9D in = an informational document. > In the absence of a Manifest, an RP is expected to accept all valid > signed objects present in the publication point. =20 RFC6486 says that all such objects "SHOULD be viewed as suspect, but MAY = be used by the RP, as per local policy=E2=80=9D. This is quite different = to =E2=80=9CRP is expected to accept=E2=80=9D. And again, in general, I do not quite understand how authors chose to = describe in detail some validation steps, and completely omit other = steps, which makes the overall value of this document unclear to me. Oleg From nobody Mon Mar 25 04:48: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 26E84120403; Mon, 25 Mar 2019 04:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 hXTnL0267OWa; Mon, 25 Mar 2019 04:48:41 -0700 (PDT) Received: from out20-51.mail.aliyun.com (out20-51.mail.aliyun.com [115.124.20.51]) (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 8DEC2120401; Mon, 25 Mar 2019 04:48:37 -0700 (PDT) X-Alimail-AntiSpam: AC=CONTINUE; BC=0.0745794|-1; CH=green; DM=||false|; FP=0|0|0|0|0|-1|-1|-1; HT=e02c03307; MF=madi@rpstir.net; NM=1; PH=DS; RN=4; RT=4; SR=0; TI=SMTPD_---.ECVqTi2_1553514507; Received: from dhcp-89aa.meeting.ietf.org(mailfrom:madi@rpstir.net fp:SMTPD_---.ECVqTi2_1553514507) by smtp.aliyun-inc.com(10.147.37.28); Mon, 25 Mar 2019 19:48:32 +0800 Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Di Ma In-Reply-To: Date: Mon, 25 Mar 2019 12:48:18 +0100 Cc: sidrops@ietf.org, sidrops-chairs@ietf.org, sidrops-ads@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <760F2043-C7DD-4CAF-8BA0-027769BA90D7@rpstir.net> References: To: Oleg Muravskiy X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Sidrops] [WGLC] draft-ietf-sidrops-rp - ENDS: Mar 7, 2019 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, 25 Mar 2019 11:48:45 -0000 Oleg, > =D4=DA 2019=C4=EA3=D4=C224=C8=D5=A3=AC18:11=A3=ACOleg Muravskiy = =D0=B4=B5=C0=A3=BA >=20 > Here are my comments on this document. Most of them I already = submitted back in 2016 = (https://mailarchive.ietf.org/arch/msg/sidr/ThyvBuWdCnv2t9u86sOjwdV4xKc), = and authors seem to agreed to update the document, but that didn=A1=AFt = happen: Thanks very much for your detailed review.=20 And sorry for forgetting taking your feedback into updating.=20 =20 >=20 >=20 >> 3.2. Certificate Path Validation >>=20 >> In the RPKI, issuer can only assign and/or allocate public INRs >> belong to it, >=20 >=20 > Assignment / allocation of INRs does not happen in RPKI. Yes, it is not an accurate description, which I see an unnecessary = statement by far. I will cross it out.=20 >=20 >=20 >> 3.3. CRL Processing >>=20 >> The CRL processing requirements imposed on CAs and RP are described >> in Section 5 of [RFC6487]. CRLs in the RPKI are tightly = constrained; >> only the AuthorityKeyIndetifier and CRLNumber extensions are = allowed, >> and they MUST be present. No other CRL extensions are allowed, and >> no CRLEntry extensions are permitted. RPs are required to verify >> that these constraints have been met. Each CRL in the RPKI MUST be >> verified using the public key from the certificate of the CA that >> issued the CRL. >=20 >=20 > The normative language is used in an Informational document. Good catch. We authors were eliminating normative language in this document, this is = a missed one:-) >=20 >=20 >> 4.2.2. ROA >>=20 >> To validate a ROA, the RP is required perform all the checks >> specified in [RFC6488] as well as the additional ROA-specific >> validation steps. The IP address delegation extension [RFC3779] >> present in the end-entity (EE) certificate (contained within the >> ROA), must encompass each of the IP address prefix(es) in the ROA. >>=20 >> More details for ROA validation are specified in Section 2 of >> [RFC6482]. >=20 >=20 > Section 2 of RFC6482 defines the ROA content-type, not the validation. Yes. It might be a typo.=20 We should have referred to Section 4 of [RFC6482] >=20 >=20 >> 4.2.3. Ghostbusters >>=20 >>=20 >> The Ghostbusters Record is optional; a publication point in the = RPKI >> can have zero or more associated Ghostbuster Records. >=20 >=20 > Since no other CMS object description in this document mentions = object=A1=AFs optionality, this sentence may be understood as that the = Ghostbusters Record is the only type of object which is optional. This = is not the case. We haven=A1=AFt thought of this implication.=20 Thanks for your consideration.=20 >=20 >=20 >> 4.3. How to Make Use of Manifest Data >>=20 >> For a given publication point, the RP ought to perform tests, as >> specified in Section 6.1 of [RFC6486], to determine the state of = the >> Manifest at the publication point. A Manifest can be classified as >> either valid or invalid, and a valid Manifest is either current and >> stale. An RP decides how to make use of a Manifest based on its >> state, according to local (RP) policy. >>=20 >> If there are valid objects in a publication point that are not >> present on a Manifest, [RFC6486] does not mandate specific RP >> behavior with respect to such objects. However, most RP software >> ignores such objects and this document recommends that this = behavior >> be adopted uniformly. >=20 >=20 > To my knowledge, most RP software notifies operator about presence of = such objects, not just ignores them. >=20 > Also, I=A1=AFm not sure how to treat =A1=B0recommends=A1=B1 in an = informational document. Since you and I can neither know how other RP software would behave in = terms of this issue. How about crossing out 'However, most RP software ignores such objects = and this document recommends that this behavior be adopted uniformly.=A1=AF= >=20 >=20 >> In the absence of a Manifest, an RP is expected to accept all valid >> signed objects present in the publication point. =20 >=20 >=20 > RFC6486 says that all such objects "SHOULD be viewed as suspect, but = MAY be used by the RP, as per local policy=A1=B1. This is quite = different to =A1=B0RP is expected to accept=A1=B1. >=20 >=20 >=20 > And again, in general, I do not quite understand how authors chose to = describe in detail some validation steps, and completely omit other = steps, which makes the overall value of this document unclear to me. You are touching the key point.=20 We authors were bothered by RFC 6486 which is squishy in how RPs would = use Manifest, but find it hard to improve it. That=A1=AFs why we tried to go into detail of this issue instead of just = referring to Section 6 of RFC 6486 but leave TBD in early version.=20 If the WG has no more better idea, we authors will consider to adjust = this section regarding 'How to Make Use of Manifest Data=A1=AF . Di= From nobody Mon Mar 25 05:21:03 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 25EDC1203EF for ; Mon, 25 Mar 2019 05:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=algebras-org.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 ZqVmh1sJ0ABJ for ; Mon, 25 Mar 2019 05:20:53 -0700 (PDT) Received: from mail-it1-x135.google.com (mail-it1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 89FF21203E3 for ; Mon, 25 Mar 2019 05:20:53 -0700 (PDT) Received: by mail-it1-x135.google.com with SMTP id l4so7061783ite.1 for ; Mon, 25 Mar 2019 05:20:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=PGu/KU+W9m9W+l7QLgT57WDOyfShfvLiF1Of9H2P2XQ=; b=rI1a/WXVT1nTw/JejU5r1DMKBm/bleZNFncm9yo6vl26hLHYRfAn8wBtShVGEMlwr3 ubK09zeFIMqyxrTngC2ZT7uLuUloyWCIbWgbeMdW6QHTRl3b96rtgdBz+KwpbklK3or5 Th09gYXi/8nDX9v9gOM8KeCopYvrWJnYY4xv8/bwjt+XS8Ko0JjrxjZ2hVCmJUFEfiET N/7kGClqSucd/p54LJXo9nlS6fueNPn9BVwigCfWk5aW8IWqct9gauQ28XGbcjQqt2S8 rZ6mJeKjxLQSGHDuAHInG8hqr2KFlPemnwFkkOgA3jV3jB+J/awovZjn+DxPP0LofoTA HUQg== 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=PGu/KU+W9m9W+l7QLgT57WDOyfShfvLiF1Of9H2P2XQ=; b=e5On3Ku0TW7D8t9tWjpR/gjCltTiA4HG4VXfjjb9eTKjOeCMgRFKwlWyZs+e201MKO pvOn2BuyuZekEpgjFvqufOu3mDXKGJh2c1YFC7L+eEvY3Wjen1k7C2t9JbJxt9ldXfAG Qvcmlqv1Gl/Z4iFYQa94tWkJLMx59Q2EcgPQLBwG8T0GhR/JLigmnxy0eEu1Q1Pv5VdR hy4EYVR6cQQz5OVUXxS6G/hr1hMnMieg8P+I2yY93vWyRUAcQgC1JGWBG57S6T5EVUOH WLkFLyzvBumCWOnjJk+mrj0iXXsFotYqnUBXl+FI0IXdvoCnI1yqAIx4FbzBKw/rzimB +ulw== X-Gm-Message-State: APjAAAWdUZae4U8QHrf7x9M085tEyvlzYtB9dRkE5Cdq1TaAKqs17j68 wWWkvRD41A/M2lMh4uElSHDF7smoe8NMthztQSprT/w2Mks= X-Google-Smtp-Source: APXvYqzziYXcd007XAUyMHIk+crAQ+4K/tGpul4ptiEKT2m/KwLXJApRk0EcWRDOlmEPis6lQMV6sSIFz9666VWHLEM= X-Received: by 2002:a24:d245:: with SMTP id z66mr12028905itf.47.1553516451766; Mon, 25 Mar 2019 05:20:51 -0700 (PDT) MIME-Version: 1.0 References: <760F2043-C7DD-4CAF-8BA0-027769BA90D7@rpstir.net> In-Reply-To: <760F2043-C7DD-4CAF-8BA0-027769BA90D7@rpstir.net> From: George Michaelson Date: Mon, 25 Mar 2019 13:20:35 +0100 Message-ID: To: Di Ma Cc: SIDR Operations WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] [WGLC] draft-ietf-sidrops-rp - ENDS: Mar 7, 2019 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, 25 Mar 2019 12:20:59 -0000 I don't think rfc6846 Section 6.5 is overly informal. it says its a matter of local policy, and you should issue a warning. I don't think this needs refinement. If you want this document to change that, I think thats something we'd want to discuss more widely. I think adopting the RP document is a good idea so we *can* discuss these things. This specific point I would tend to argue doesn't need work, but the general sense is that people need guidance. It is useful to have a document which issues some guidance for RPs. -G On Mon, Mar 25, 2019 at 12:48 PM Di Ma wrote: > > Oleg, > > > > =E5=9C=A8 2019=E5=B9=B43=E6=9C=8824=E6=97=A5=EF=BC=8C18:11=EF=BC=8COleg= Muravskiy =E5=86=99=E9=81=93=EF=BC=9A > > > > Here are my comments on this document. Most of them I already submitted= back in 2016 (https://mailarchive.ietf.org/arch/msg/sidr/ThyvBuWdCnv2t9u86= sOjwdV4xKc), and authors seem to agreed to update the document, but that di= dn=E2=80=99t happen: > > Thanks very much for your detailed review. > > And sorry for forgetting taking your feedback into updating. > > > > > > >> 3.2. Certificate Path Validation > >> > >> In the RPKI, issuer can only assign and/or allocate public INRs > >> belong to it, > > > > > > Assignment / allocation of INRs does not happen in RPKI. > > > Yes, it is not an accurate description, which I see an unnecessary statem= ent by far. > > I will cross it out. > > > > > > >> 3.3. CRL Processing > >> > >> The CRL processing requirements imposed on CAs and RP are described > >> in Section 5 of [RFC6487]. CRLs in the RPKI are tightly constrained; > >> only the AuthorityKeyIndetifier and CRLNumber extensions are allowed= , > >> and they MUST be present. No other CRL extensions are allowed, and > >> no CRLEntry extensions are permitted. RPs are required to verify > >> that these constraints have been met. Each CRL in the RPKI MUST be > >> verified using the public key from the certificate of the CA that > >> issued the CRL. > > > > > > The normative language is used in an Informational document. > > > Good catch. > > We authors were eliminating normative language in this document, this is = a missed one:-) > > > > > > > >> 4.2.2. ROA > >> > >> To validate a ROA, the RP is required perform all the checks > >> specified in [RFC6488] as well as the additional ROA-specific > >> validation steps. The IP address delegation extension [RFC3779] > >> present in the end-entity (EE) certificate (contained within the > >> ROA), must encompass each of the IP address prefix(es) in the ROA. > >> > >> More details for ROA validation are specified in Section 2 of > >> [RFC6482]. > > > > > > Section 2 of RFC6482 defines the ROA content-type, not the validation. > > Yes. It might be a typo. > > We should have referred to Section 4 of [RFC6482] > > > > > > >> 4.2.3. Ghostbusters > >> > >> > >> The Ghostbusters Record is optional; a publication point in the RPKI > >> can have zero or more associated Ghostbuster Records. > > > > > > Since no other CMS object description in this document mentions object= =E2=80=99s optionality, this sentence may be understood as that the Ghostbu= sters Record is the only type of object which is optional. This is not the = case. > > We haven=E2=80=99t thought of this implication. > > Thanks for your consideration. > > > > > > >> 4.3. How to Make Use of Manifest Data > >> > >> For a given publication point, the RP ought to perform tests, as > >> specified in Section 6.1 of [RFC6486], to determine the state of the > >> Manifest at the publication point. A Manifest can be classified as > >> either valid or invalid, and a valid Manifest is either current and > >> stale. An RP decides how to make use of a Manifest based on its > >> state, according to local (RP) policy. > >> > >> If there are valid objects in a publication point that are not > >> present on a Manifest, [RFC6486] does not mandate specific RP > >> behavior with respect to such objects. However, most RP software > >> ignores such objects and this document recommends that this behavior > >> be adopted uniformly. > > > > > > To my knowledge, most RP software notifies operator about presence of s= uch objects, not just ignores them. > > > > Also, I=E2=80=99m not sure how to treat =E2=80=9Crecommends=E2=80=9D in= an informational document. > > > Since you and I can neither know how other RP software would behave in t= erms of this issue. > > How about crossing out 'However, most RP software ignores such objects an= d this document recommends that this behavior be adopted uniformly.=E2=80= =99 > > > > > > > >> In the absence of a Manifest, an RP is expected to accept all valid > >> signed objects present in the publication point. > > > > > > RFC6486 says that all such objects "SHOULD be viewed as suspect, but MA= Y be used by the RP, as per local policy=E2=80=9D. This is quite different = to =E2=80=9CRP is expected to accept=E2=80=9D. > > > > > > > > And again, in general, I do not quite understand how authors chose to d= escribe in detail some validation steps, and completely omit other steps, w= hich makes the overall value of this document unclear to me. > > > You are touching the key point. > > We authors were bothered by RFC 6486 which is squishy in how RPs would u= se Manifest, but find it hard to improve it. > > That=E2=80=99s why we tried to go into detail of this issue instead of ju= st referring to Section 6 of RFC 6486 but leave TBD in early version. > > If the WG has no more better idea, we authors will consider to adjust thi= s section regarding 'How to Make Use of Manifest Data=E2=80=99 . > > > Di > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Mon Mar 25 06:07: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 8D7F112042D for ; Mon, 25 Mar 2019 06:07:35 -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_MED=-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 (2048-bit key) header.d=verizon.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 zbHm8uF0lvTq for ; Mon, 25 Mar 2019 06:07:33 -0700 (PDT) Received: from sonic317-26.consmr.mail.bf2.yahoo.com (sonic317-26.consmr.mail.bf2.yahoo.com [74.6.129.81]) (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 3FA1812046B for ; Mon, 25 Mar 2019 06:07:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1553519251; bh=2H22VoR0mbYgMAQE6pSehY9D+Z7ignwlfWQVBjp8yDE=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=sNmdHv9wJStV7O0u3wp7W+tmfXv9L9JH6pJw8H+eT8pwI9OzBbcxIXq/eed1bzGvNqf3szpqn+L4ClQAvDYHZ/6b61kA4QUUn3pAsjF14+t/VmYQaqtLPUxSJ7xyHWhJj+E3I4M2baZXZyC7xOvqHLk1YtlE8ifBHQHgQmKto9Au3LV4heFCJ0B250SwP8lWlO1GtmhTn+6pW4BEYiCu6smUHK3mm53obwmtlrwd24wqjcC5Se/C3ZVGc5xfQOIZk6UgW0I0RTRBc6wd6CtMFwijvJX5IuJV78eHTfcQbKHoPuWMZ8gyD7LCjN4aO3GBExKJSFlwEOsT0O6oCHTSbw== X-YMail-OSG: 1dBB.QwVM1kYVGStnCdRncTBnKckdxZZY1j.ykx.D31tcEJBAQugHJGTyerjsDa byYW.3pmWOvtxQXhdGB4_onWPpBtMPiiBafSuS2k377PwUXWw2jK_RI1.sorDbooVDHBx51kltRG 9EPF5Hf3NdEYn2Nu0LayWgP1Q8XV_Hpg1bx6COzwQyQzsh9B7N3MxBdmWDpHAVbUpVOx4T5C1OvN 8B0oSlXJis_DFyJuApX_GMkc7h95TtGFhtpC0z8XSrf8hiYPVCCOnOv4TXu5Q6sowpaffDM4FlhR 9xhha39.SNapZDj8e.WiYXB8n_7ptuMDyP8FtXJrv9KhAGDvZ3bsNOqx0fmZ7lDuRiXaFSGJgypv Ju5qjXAC1AkXg.Riq1rveQyw2YcX1PmNs_.HeWcG8jDMcJWbdAl7neRITHp.PNfOEumPnnoNFsx9 _wT8lz5Wf1eHhf_fUXr7YxqH8Dw3B8Ps8tEMtiIf44NDc3LHI75PmERPm_akE3uUT8Ar9CFxru6t HKjSdz8lP71VN7jEhgQGPSde4ylggjx2vSlM7z3GnWbR954Ec9LQYjvZ6FoYR4KYSGLpW6wZu1pp jobLQEdacaHA7Lz3E8aqbx98q3BOQCStPLB8vZlkXpQX6WGKfCVgLQ_CW3.a7hUhjwVHxI2yJUTr RxMo5al2s8_WOqZHMuJiveRxcKkb9JmVVNNZzEAz8fxvEqBDeOsVvJJJKFTr086l77qp_WheYOAP bv5aKyCgoaujXm1IOfLLLzUoRsoyEdLjTXWXbCF..FOyVtiVpDb.9QTeg_tA3bgy439s.qv25L7H aDDQ7TarsCdhVE8MKdSWnnaLuZ.wEBmeP.OLczF7m0bOfQ38Dky40RLmUQ9QcCOWi7jxetVVma7n rVIcWLZtH8YKao4TlbyTEAHuv4AKe6FE2mCNrHb0MZC5NOFpEQGb5G.pkEtZjR5ksSB_UR_zwQKu wHUF7a8g_7Lde2eMW4SDvwZYd6eLlclRBWgtqAeQX4rZrKHSFaq2TSuYkOnMv709ABaQIzsOITaM R82luxDynWs9IcxjB2kD8fq6cPcmXhqD_kf97KqKDqXCRRrUKdedD5wnP1VQkUa5z9yuZV7zv9WM Q Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.bf2.yahoo.com with HTTP; Mon, 25 Mar 2019 13:07:31 +0000 Received: from pool-71-184-117-160.bstnma.fios.verizon.net (EHLO iMac-Study.fios-router.home) ([71.184.117.160]) by smtp405.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID e57df9b4d1c364df576f1c172637270b for ; Mon, 25 Mar 2019 13:07:29 +0000 (UTC) To: sidrops@ietf.org References: <760F2043-C7DD-4CAF-8BA0-027769BA90D7@rpstir.net> From: Stephen Kent Message-ID: Date: Mon, 25 Mar 2019 09:07:29 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <760F2043-C7DD-4CAF-8BA0-027769BA90D7@rpstir.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Sidrops] [WGLC] draft-ietf-sidrops-rp - ENDS: Mar 7, 2019 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, 25 Mar 2019 13:07:38 -0000 Oleg & Di Ma, Sorry I missed the use of normative language in my earlier review of this doc. > >>> 4.2.3. Ghostbusters >>> >>> >>> The Ghostbusters Record is optional; a publication point in the RPKI >>> can have zero or more associated Ghostbuster Records. >> >> Since no other CMS object description in this document mentions object’s optionality, this sentence may be understood as that the Ghostbusters Record is the only type of object which is optional. This is not the case. > We haven’t thought of this implication. > > Thanks for your consideration. I believe that all of the other RPKI signed objects are intended as mandatory for applicable entities (e.g., TAs, CAs, or EEs).  There are some fields in those objects that are optional, but not the objects themselves. The GB object is purely optional, so the cited statement seems apporpriate. > Since you and I can neither know how other RP software would behave in > terms of this issue. > How about crossing out 'However, most RP software ignores such objects and this document recommends that this behavior be adopted uniformly.’ To avoid what might be construed as standards-like language, how about: "... this document recommends that..." -> "... the authors of this document suggest that ..." > You are touching the key point. > > We authors were bothered by RFC 6486 which is squishy in how RPs would use Manifest, but find it hard to improve it. > > That’s why we tried to go into detail of this issue instead of just referring to Section 6 of RFC 6486 but leave TBD in early version. > > If the WG has no more better idea, we authors will consider to adjust this section regarding 'How to Make Use of Manifest Data’ . As Di notes, the language in 6486 is thus very squishy, because it's hard to decide, in general, whether a hard-line approach to Mainfest info may be more helpful than harmful. I think a discussion of the pros and cons of using Manifest data can be useful, but it also must be carefully worded. Steve From nobody Mon Mar 25 09:02: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 1E95E120411; Mon, 25 Mar 2019 09:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, 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 fH93wSNVIOd4; Mon, 25 Mar 2019 09:02:40 -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 945611203E3; Mon, 25 Mar 2019 09:02:40 -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 822363FDFA; Mon, 25 Mar 2019 16:02:38 +0000 (UTC) Received: from morrowc-glaptop2.ops-netman.net (unknown [IPv6:2001:67c:370:128:1faf:aabd:6fd9:3545]) (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 CB7F136A584D5; Mon, 25 Mar 2019 16:02:37 +0000 (UTC) Authentication-Results: mail.ops-netman.net; dkim=none reason="no signature"; dkim-adsp=fail (unprotected policy); dkim-atps=neutral Date: Mon, 25 Mar 2019 09:02:34 -0700 Message-ID: From: Chris Morrow To: sidrops@ietf.org, sidrops-chairs@ietf.org User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.1 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] Call for Presentations for IETF104 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, 25 Mar 2019 16:02:42 -0000 Howdy folks! If you are on the agenda for 104, please send your presentation materials 'now'. I don't want to be fumbling at the mic table tomorrow trying to import your wonky ppt file into a pdf and then to the laptop for display :) As with all previous meetings: "If you send me ppt, you get to live with my interpretive dance into "pdf" form" therefore, if you don't want less optimal performance of your presntation please send proper format. Alternately, I can interpretive dance your preso... no guarantees on efficacy of that of course. thanks! -chris (co-chair) From nobody Tue Mar 26 00:26: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 DD96812028C; Tue, 26 Mar 2019 00:26:02 -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_PASS=-0.001, URIBL_BLOCKED=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 p9s3b1Xf7P1f; Tue, 26 Mar 2019 00:26:01 -0700 (PDT) Received: from relay.kvm02.ops-netman.net (relay.kvm02.ops-netman.net [IPv6:2606:700:e:550:5c82:28ff:fe25:4960]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3156E120284; Tue, 26 Mar 2019 00:26:00 -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 711E23FC28; Tue, 26 Mar 2019 07:25:59 +0000 (UTC) Received: from morrowc-glaptop2.ops-netman.net (unknown [IPv6:2001:67c:370:128:1faf:aabd:6fd9:3545]) (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 AA56436CAB646; Tue, 26 Mar 2019 07:25:58 +0000 (UTC) Authentication-Results: mail.ops-netman.net; dkim=none reason="no signature"; dkim-adsp=fail (unprotected policy); dkim-atps=neutral Date: Tue, 26 Mar 2019 00:25:56 -0700 Message-ID: From: Chris Morrow To: sidrops@ietf.org, sidrops-chairs@ietf.org In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.1 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: Re: [Sidrops] Call for Presentations for IETF104 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, 26 Mar 2019 07:26:03 -0000 Helo! I've gotten slides from 1 person on schedule, two people not (on the published schedule), one person's said "real soon now". I'm limbering up for interpretive dance moves... I didn't bring my stretchy-pants though :( -chris On Mon, 25 Mar 2019 09:02:34 -0700, Chris Morrow wrote: > > > Howdy folks! > > If you are on the agenda for 104, please send your presentation > materials 'now'. I don't want to be fumbling at the mic table > tomorrow trying to import your wonky ppt file into a pdf and then to > the laptop for display :) > > As with all previous meetings: > "If you send me ppt, you get to live with my interpretive dance into "pdf" form" > > therefore, if you don't want less optimal performance of your presntation please > send proper format. Alternately, I can interpretive dance your preso... no guarantees > on efficacy of that of course. > > thanks! > -chris > > (co-chair) From nobody Tue Mar 26 00: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 AD5C712029E; Tue, 26 Mar 2019 00:52:15 -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_PASS=-0.001, URIBL_BLOCKED=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 c4ao1PwyZ3WA; Tue, 26 Mar 2019 00:52:14 -0700 (PDT) Received: from relay.kvm02.ops-netman.net (relay.kvm02.ops-netman.net [IPv6:2606:700:e:550:5c82:28ff:fe25:4960]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 576D6120295; Tue, 26 Mar 2019 00:52:14 -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 7A8EC3FC28; Tue, 26 Mar 2019 07:52:13 +0000 (UTC) Received: from morrowc-glaptop2.ops-netman.net (unknown [IPv6:2001:67c:370:128:1faf:aabd:6fd9:3545]) (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 E434236CBC397; Tue, 26 Mar 2019 07:52:12 +0000 (UTC) Authentication-Results: mail.ops-netman.net; dkim=none reason="no signature"; dkim-adsp=fail (unprotected policy); dkim-atps=neutral Date: Tue, 26 Mar 2019 00:52:09 -0700 Message-ID: From: Chris Morrow To: sidrops@ietf.org, sidrops-chairs@ietf.org In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.1 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: Re: [Sidrops] Call for Presentations for IETF104 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, 26 Mar 2019 07:52:27 -0000 Now we are pending a single presentation... On Tue, 26 Mar 2019 00:25:56 -0700, Chris Morrow wrote: > > Helo! > I've gotten slides from 1 person on schedule, > two people not (on the published schedule), > > one person's said "real soon now". > > I'm limbering up for interpretive dance moves... I didn't bring my > stretchy-pants though :( > > -chris > > On Mon, 25 Mar 2019 09:02:34 -0700, > Chris Morrow wrote: > > > > > > Howdy folks! > > > > If you are on the agenda for 104, please send your presentation > > materials 'now'. I don't want to be fumbling at the mic table > > tomorrow trying to import your wonky ppt file into a pdf and then to > > the laptop for display :) > > > > As with all previous meetings: > > "If you send me ppt, you get to live with my interpretive dance into "pdf" form" > > > > therefore, if you don't want less optimal performance of your presntation please > > send proper format. Alternately, I can interpretive dance your preso... no guarantees > > on efficacy of that of course. > > > > thanks! > > -chris > > > > (co-chair) From nobody Tue Mar 26 02:48: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 64D04120282 for ; Tue, 26 Mar 2019 02:48:40 -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 4xwyUbfHqdWS for ; Tue, 26 Mar 2019 02:48:38 -0700 (PDT) Received: from GCC01-CY1-obe.outbound.protection.outlook.com (mail-eopbgr830114.outbound.protection.outlook.com [40.107.83.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF7271202F2 for ; Tue, 26 Mar 2019 02:48:30 -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=a+Ds4u9UvWZNMAR01XrqwIr0dYNYm6r9ki6pg5dNXvI=; b=EzT/m36FJql0KKfG5qeqIReDA/G3OWweMvk5v63I96i4RuXBFSC+WygsKBIhR+cEsSuyVLMeEyNl1liH7bRiWjQzrN99ED86xoP4d3LKJJ55ocSNKGfF2GDwKl+ne9oWmh8PHGq3qDZT77SSyccIjf2lhg4T5Q86vHzaU+7l6ns= Received: from BN6PR09MB1171.namprd09.prod.outlook.com (10.172.19.17) by BN6PR09MB1169.namprd09.prod.outlook.com (10.172.17.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.15; Tue, 26 Mar 2019 09:48:28 +0000 Received: from BN6PR09MB1171.namprd09.prod.outlook.com ([fe80::f0f8:3e55:84af:9d9c]) by BN6PR09MB1171.namprd09.prod.outlook.com ([fe80::f0f8:3e55:84af:9d9c%8]) with mapi id 15.20.1750.014; Tue, 26 Mar 2019 09:48:27 +0000 From: "Montgomery, Douglas (Fed)" To: "sidrops@ietf.org" Thread-Topic: A few quick comments / suggestions about Origin Validation Signaling Thread-Index: AQHU47kP56hwOncUGE67UWghbrtpGw== Date: Tue, 26 Mar 2019 09:48:27 +0000 Message-ID: <6FA78F28-8D0A-451D-B7D4-EEC9EE493303@nist.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.8.190312 authentication-results: spf=none (sender IP is ) smtp.mailfrom=dougm@nist.gov; x-originating-ip: [31.133.147.167] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bf91e25e-6bae-473a-a43b-08d6b1d0329a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BN6PR09MB1169; x-ms-traffictypediagnostic: BN6PR09MB1169: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 09888BC01D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(346002)(396003)(376002)(136003)(199004)(189003)(256004)(6436002)(6512007)(6306002)(8936002)(476003)(2616005)(99286004)(8676002)(1730700003)(81156014)(81166006)(36756003)(5640700003)(83716004)(66066001)(6916009)(71190400001)(71200400001)(486006)(186003)(478600001)(6506007)(6486002)(966005)(53936002)(102836004)(26005)(14454004)(105586002)(5660300002)(58126008)(106356001)(25786009)(68736007)(33656002)(2351001)(6116002)(97736004)(7736002)(305945005)(82746002)(2501003)(3846002)(316002)(86362001)(2906002)(66574012); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR09MB1169; H:BN6PR09MB1171.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: QwAJ/apkiE8+PUAMaGeTRpMeoWpdp85Oq40xpgLkQ3IFUCZ9vgL/DWLguhVDuXgvogg7rxFFmI7gio/LnSXHDhT5CJ4kqTWwNkkuNL5K+6sIfdRXg8SLAwD+wNBRqwDzkAwQS8QQ8yekW2kqMr3cRdec4LBxtW+BCmbEW29r5ONwBOfNlXvg0FSrGmpnbYdsVGD5C+vvWiqP8Z8gY/mjm193DImmJG4OkefxlQLDbbRhNB+OrRaMxMbvcF+bbZNAkRt3r3B4wAm5bjod3T3YUiFhOvKwPq3q1VY7YXe3HNqaLEL8awXInJp+Qq9usEybpL/oDZMeBkQ7D0mO+7S0gxnYvLfYmMRR1ZyH2lhI5+pOcUX5YKcyJVFbqmh0bbioGNQX8OntAMzIybXBJiH2xYDdqe96VM/uyvZuDEqaMn0= Content-Type: text/plain; charset="utf-8" Content-ID: <98161EAEBEA5E84BA7CE51D438AC82F3@namprd09.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: bf91e25e-6bae-473a-a43b-08d6b1d0329a X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2019 09:48:27.7571 (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-Transport-CrossTenantHeadersStamped: BN6PR09MB1169 Archived-At: Subject: [Sidrops] A few quick comments / suggestions about Origin Validation Signaling 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, 26 Mar 2019 09:48:40 -0000 aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQteW1iay1zaWRyb3BzLW92LXNp Z25hbC8NCg0KMS4gIE1ha2UgdGl0bGUgbW9yZSBkZXNjcmlwdGl2ZSAtIHdlIGFscmVhZHkgaGF2 ZSBhIGZldyBzcGVjcyBhYm91dCB3aGF0IG1vc3QgZm9sa3Mgd291bGQgY2FsbCAiT3JpZ2luIFZh bGlkYXRpb24gU2lnbmFsaW5nIi4gICBNYXliZSAiT3V0c291cmNlZCBPcmlnaW4gVmFsaWRhdGlv biIuICAiRGlzdHJpYnV0ZWQiIGlmIHRoYXQgaXMgb3VyIGV1cGhlbWlzbSBmb3Igb3V0c291cmNl ZC4NCg0KQXQgdGhlIGxhc3QgTkFOT0cgYSBmZXcgbmV3IGNvbWVycyB0byB0aGUgdGVjaG5vbG9n eSBwb2ludGVkIG91dCB3aGF0IGEgY29uZnVzaW5nIHN3YW1wIG9mIHNwZWNzIHdlIGhhdmUgLSBh bmQgdGhhdCBuYXZpZ2F0aW5nIHRoYXQgc3dhbXAgaXMgbm9uLXRyaXZpYWwuICBNb3JlIGRlc2Ny aXB0aXZlIHRpdGxlcyB3b3VsZCBiZSBhIHNtYWxsIHN0ZXAgaW4gdGhlIHJpZ2h0IGRpcmVjdGlv bi4NCg0KMi4gU2VjdGlvbiAzIFRydXN0IEJvdW5kYXJ5DQoNCiAgICJBbiBbUkZDNDQ1Nl0gUm91 dGUgUmVmbGVjdG9yIENsdXN0ZXIgaXMgYW4gb2J2aW91cyBjYW5kaWRhdGUgZm9yIHRoaXMNCiAg IGFwcHJvYWNoLiAgVGhlIHJvdXRlIHJlZmxlY3RvcihzKSB3b3VsZCBwZXJmb3JtIE9yaWdpbiBW YWxpZGF0aW9uIGFuZA0KICAgc2lnbmFsIGFuIEludmFsaWQgcm91dGUgYmFjayB0byB0aGUgc2Vu ZGluZyBjbGllbnQuIg0KDQpXaGlsZSBJIGFncmVlIHRoYXQgYW4gUlAgaXMgdGhlIG9idmlvdXMg cGxhY2UgdG8gZG8gdGhpcywgdGhlIGRyYWZ0IHdvdWxkIGdpdmUgb25lIHRoZSBpbXByZXNzaW9u IHRoYXQgdGhlcmUgYXJlIG90aGVycy4gICANCg0KSSB3b3VsZCBzdWdnZXN0IHRoYXQgcHJvdmlk aW5nIGEgZmV3IG1vcmUgZGV0YWlscyBhYm91dCBob3cgdGhpcyB3b3VsZCBtb2RpZnkgUkZDNDQ1 NiBiZWhhdmlvciB3b3VsZCBiZSB1c2VmdWwuICBUaGF0IGlzIG9uZSBmdWxseSBkZXNjcmliZWQg ZXhhbXBsZSBvZiBob3cgdGhpcyB3b3VsZCB3b3JrLg0KDQpJZiB0aGUgUlIgbW9kZWwgaXMgdGhl IG9ubHkgbW9kZWwgaW4gd2hpY2ggd2UgdGhpbmsgdGhpcyB3b3Jrcywgd2Ugc2hvdWxkIHNheSBz by4gICBPciBtb3JlIHRvIHRoZSBwb2ludCwgaWYgSSB3ZXJlIHRvIG1vZGlmeSBteSBnZW5lcmFs IGlCR1AgYmVoYXZpb3IgYXMgZGVzY3JpYmVkIGluIHRoaXMgZHJhZnQsIGRvIHdlIHNlZSBhbnkg cHJvYmxlbXMgd2l0aCBkb2luZyB0aGF0Pw0KDQoyLiAgU2VjdGlvbiA1IEFjdGlvbnMNCg0KICAg IkEgc2VuZGVyIHJlY2VpdmluZyB0aGUgcmV0dXJuZWQgcHJlZml4IGFubm91bmNlbWVudCBzbyBt YXJrZWQgTVVTVA0KICAgdHJlYXQgaXQgdGhlIHdheSBpdCB3b3VsZCB0cmVhdCBhbiBJbnZhbGlk IG9yaWdpbiB0aGF0IGl0IGl0c2VsZg0KICAgZGV0ZWN0ZWQuICBJdCBzaG91bGQgd2l0aGRyYXcg YWxsIHJvdXRlcyBpdCBoYWQgYW5ub3VuY2VkIHRvIHRoYXQNCiAgIHByZWZpeCB3aXRoIHRoZSBJ bnZhbGlkIG9yaWdpbiBBUy4gIFRoaXMgaW5jbHVkZXMgd2l0aGRyYXdpbmcgYW55DQogICBpbnN0 YW5jZXMgb2YgYWRkaXRpb25hbCBwYXRocyB3aXRoIHRoYXQgb3JpZ2luIEFTIGFkdmVydGlzZWQg dW5kZXINCiAgIFtSRkM3OTExXS4iDQoNCkRvZXMgdGhlIGFib3ZlIGFwcGx5IHRvIGJvdGggZS1C R1AgYW5kIGktQkdQIGFkdmVydGlzZWQgcm91dGVzPyAgIA0KDQpEb2VzIGl0IG5lZWQgdGhlIGNh dmVhdCBvZiAib24gcGVlcmluZyBzZXNzaW9ucyBvbiB3aGljaCBPViBpcyBiZWluZyBwZXJmb3Jt ZWQiPw0KDQpkb3VnbQ0KLS0gIA0KRG91ZyBNb250Z29tZXJ5LCBNYW5hZ2VyIEludGVybmV0ICYg U2NhbGFibGUgU3lzdGVtcyBSZXNlYXJjaCBAIE5JU1QNCiANCg0K From nobody Tue Mar 26 08:35: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 1126012042E for ; Tue, 26 Mar 2019 08:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 V7cpt3Zl7xuj for ; Tue, 26 Mar 2019 08:35:06 -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 BEEFA12043C for ; Tue, 26 Mar 2019 08:35:06 -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 1h8o6S-0006iD-Kh; Tue, 26 Mar 2019 15:35:04 +0000 Date: Tue, 26 Mar 2019 16:35:04 +0100 Message-ID: From: Randy Bush To: "Montgomery, Douglas (Fed)" Cc: "sidrops@ietf.org" In-Reply-To: <6FA78F28-8D0A-451D-B7D4-EEC9EE493303@nist.gov> References: <6FA78F28-8D0A-451D-B7D4-EEC9EE493303@nist.gov> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 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: Re: [Sidrops] A few quick comments / suggestions about Origin Validation Signaling 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, 26 Mar 2019 15:35:08 -0000 thanks doug. will get to this after prag and i get sleep. randy From nobody Tue Mar 26 12:33:03 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 D95381209CB; Tue, 26 Mar 2019 12:32:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Carlos Pignataro via Datatracker To: Cc: sidrops@ietf.org, ietf@ietf.org, draft-ietf-sidrops-bgpsec-algs-rfc8208-bis.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Carlos Pignataro Message-ID: <155362877270.7408.1659232059641306508@ietfa.amsl.com> Date: Tue, 26 Mar 2019 12:32:52 -0700 Archived-At: Subject: [Sidrops] Rtgdir telechat review of draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-04 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, 26 Mar 2019 19:32:54 -0000 Reviewer: Carlos Pignataro Review result: Has Issues Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-04 Reviewer: Carlos Pignataro Intended Status: Proposed Standard Summary: This document specifies the algorithms and parameters for BGPsec (Border Gateway Protocol Security). Comments: This is a clear, comprehensive, and well written document. It states it updates (if approved) RFC 8208, and I particularly appreciate Section 1.2, "Changes from RFC 8208", in explicitly showing how. However, it is unclear to me if the right relationship is to "update" or to "obsolete" RFC 8208. Should this document be approved and published, would RFC 8208 still be active and relevant, only updated, or re-written? Minor Issues: 1. Introduction This document updates [RFC7935] to add support for a) a different algorithm for BGPsec certificate requests, which are issued only by BGPsec speakers; b) a different Subject Public Key Info format for CMP: Does this document update RFC7935 or RFC8208 on these issues? Meaning, if it really updates RFC7935, then it would obsolete RFC 8208. If it does not obsolete RFC 8208, then it would update RFC 8208 and RFC 7935, perhaps? CMP: I believe the right metadata would be: Updates: 7935 Obsoletes: 8208 CMP: Also, an editorial: this is a very thick paragraph to parse containing an enumerated list embedded in it. Should clarity be improved if turned into an actual list? (a), (b), etc. Appendix A contains example BGPsec UPDATE messages as well as the private keys used to generate the messages and the certificates necessary to validate the signatures. CMP: Maybe overkill, but might be useful to explicitly say that the Appendix is non-normative. Just a thought for your consideration. 2.1. Algorithm ID Types o Special-Use Algorithm ID Special-Use algorithm IDs span from 0xFA (250) to 0xFE (254). To allow documentation and experimentation to accurately describe CMP: I was wondering if it is appropriate to use a common block for both documentation (paper) and experimentation (wire in labs). CMP: In this, I note that RFC 4727 says: " It is not appropriate to use addresses in the documentation prefix [RFC3849] for experimentation." CMP: So, while I have no strong position (I think), it might be useful to consider separating these two semantics with different allocations. 8. References CMP: Lastly, I am sure ADs are checking downrefs and the such. Also Nits: Found possible IPv6 address '2001:0010:0000:0000:0000:0000:c633:6464' in position 783 in the paragraph; this doesn't match RFC 3849's suggested 2001:DB8::/32 address range or RFC 4193's Unique Local Address range FC00::/7. CMP: I hope these are useful. Thank you, Carlos Pignataro. From nobody Sun Mar 31 12:16: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 CA826120021 for ; Sun, 31 Mar 2019 12:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=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 Sj_ljowVYMmF for ; Sun, 31 Mar 2019 12:16:11 -0700 (PDT) Received: from hrabosky.cbbtier3.att.net (braeburn.org [12.0.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8EB120026 for ; Sun, 31 Mar 2019 12:16:11 -0700 (PDT) Received: from oz.mt.att.com (zoe.cbbtier3.att.net [12.0.1.45]) by hrabosky.cbbtier3.att.net (Postfix) with ESMTP id A1F8121F2D for ; Sun, 31 Mar 2019 19:16:10 +0000 (UTC) Received: by oz.mt.att.com (Postfix, from userid 1000) id 7CC90A40771; Sun, 31 Mar 2019 15:16:10 -0400 (EDT) X-Mailer: emacs 24.3.1 (via feedmail 11-beta-1 I); VM 8.2.0b under 24.3.1 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23713.4600.388005.282115@oz.mt.att.com> Date: Sun, 31 Mar 2019 15:16:08 -0400 From: Jay Borkenhagen To: Ruediger Volk , sidrops@ietf.org Reply-To: Jay Borkenhagen X-GPG-Fingerprint: DDDB 542E D988 94D0 82D3 D198 7DED 6648 2308 D3C0 Archived-At: Subject: [Sidrops] as23456 in ROAs 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, 31 Mar 2019 19:16:13 -0000 Hi Ruediger, Hi SIDROps, With respect to Ruediger's second presentation at IETF104 last week, in which he mentioned (among other things) finding as23456 as the authorized ASN in some published ROAs: I checked those ROAs (well, actually their VRPs) and found that in each current case, the same prefix has been authorized also to originate in an autonomous system number greater than 65535. Details below. Interestingly, each of these instances comes from the LACNIC region. Perhaps there exists some documentation or folklore in that region that has led some operators there to publish an additional ROA authorizing AS23456 if they hold an ASN > 65535. Maybe SIDROps friends at lacnic.net can investigate and report back? [ FWIW, I can imagine some tortuous logic that might lead someone to publish such a ROA: Resource Holder: Hey ISP, if you look here (some RPKI vantage point) you'll see that my prefix is to originate only in [huge ASN]. ISP: Sure, but when I look in the routing tables in my [ancient] kit, I see your prefix originating in as23456. So I blocked it manually. Resource Holder: Umm, wait just a sec, and you'll soon see my new ROA authorizing as23456, too. Then please accept it. Not saying I like it or would recommend taking steps to work around networks that still do not grok 4B-ASNs in 2019, but perhaps an as23456 ROA is not totally without motivation. ] === 138.185.76.0/22 === AS23456,138.185.76.0/22,24,lacnic AS263824,138.185.76.0/22,24,lacnic === 170.84.108.0/22 === AS23456,170.84.108.0/22,24,lacnic AS263248,170.84.108.0/22,24,lacnic === 170.254.16.0/22 === AS23456,170.254.16.0/22,24,lacnic AS263824,170.254.16.0/22,24,lacnic === 190.2.17.0/24 === AS23456,190.2.17.0/24,24,lacnic AS264638,190.2.17.0/24,24,lacnic === 190.210.206.0/24 === AS23456,190.210.206.0/24,24,lacnic AS262264,190.210.206.0/24,24,lacnic AS264638,190.210.206.0/24,24,lacnic === 191.102.48.0/21 === AS23456,191.102.48.0/21,21,lacnic AS263177,191.102.48.0/21,21,lacnic === 200.68.114.0/24 === AS23456,200.68.114.0/24,24,lacnic AS265807,200.68.114.0/24,24,lacnic AS264638,200.68.114.0/24,24,lacnic === 200.192.236.0/22 === AS23456,200.192.236.0/22,24,lacnic AS263248,200.192.236.0/22,22,lacnic AS263248,200.192.236.0/22,24,lacnic === 2803:980::/32 === AS23456,2803:980::/32,32,lacnic AS263248,2803:980::/32,48,lacnic AS263248,2803:980::/32,32,lacnic Thanks. Jay B. From nobody Sun Mar 31 18:55:25 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 4CCD31200EC for ; Sun, 31 Mar 2019 18:55:24 -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_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 SbdqkKG_XrfW for ; Sun, 31 Mar 2019 18:55:22 -0700 (PDT) Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com [IPv6:2607:f8b0:4864:20::92d]) (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 907FE12006F for ; Sun, 31 Mar 2019 18:55:22 -0700 (PDT) Received: by mail-ua1-x92d.google.com with SMTP id l17so2373386uar.4 for ; Sun, 31 Mar 2019 18:55:22 -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=xtpgoT5rFRj3/re/lPlMhQbkgzWuoyMQRkSHTVHQ50k=; b=c/wama4ib4kzV581ABW6CHu/so+x/DPhCVTeR7aA783nKehsEYqmDz2iKMC74X77bG Rd0rv9sc6xe60izU3LxTYlSPw0y9rkpzgCzrp6HGIghi05G/MAB+UUaL/7B1CEFKyBec Y7dat1LetX4OMx8cSR8kwIC/+d9gE3E+iB6gSD2dCK1IEbxg5gaNLDVFsJ3u1Qf5hSp3 P6LmOUb/wf71kQKzkdw9UFdfOcgglWQISsGTOgYbzzX1rFwwXlI1HghHH7fQGnkmzOPN KnFlY6xigbro4AcpYYl/HortPaDimPgRr5fyyZFNyq4QYOJUPNpjfgBP+Xew+Zwm05yf 4o8A== 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=xtpgoT5rFRj3/re/lPlMhQbkgzWuoyMQRkSHTVHQ50k=; b=XYeKfG32hh8EtjQwe1eDmGL4HWvdpcJlCecfPKd3Xs8mQPNeMRtEm3N0/zndWoevyr Ei0OuBzWmDyjZ2aeQWRBVPtN9ulkNHDxgHrd3mkWGPB8w0C5wipWydTapcTCbItoI3Qh cdQQmZHhdAU3gNgj6Nz/JRaHAqbZHdnHGsY75GEhaLvc5WtMqyDC2IItlnztgyzPo/ee r3z/OUAOiwF2DwoN9W6pPZRttMIWSSOfqHxjgoss28052QDdnhL5ODnW1SEwKht4pXNA KUkSW1wFfyguSE8vtuI3Z2f6tNVFTaZ6t2cFtG4BSvc3ieDkK+SR9QFtKrkE/cTjIaoL IFog== X-Gm-Message-State: APjAAAXzJYnpoOXTbnwygfpDZdYDeced7Pb+df/sKZDoilCkAWEODdWe q6gM3JnT4oZQ98Avl/Xl6PBVwO9D6on/OrrsO2s= X-Google-Smtp-Source: APXvYqza//omXpJucX7zaAhdzqTF1vHR3TbL/Smm/6Qk731z2KTUzGzHxzo0hcCvY752kr7DXvks2H7X/jVmX/aZ6qo= X-Received: by 2002:ab0:185a:: with SMTP id j26mr18686573uag.132.1554083721347; Sun, 31 Mar 2019 18:55:21 -0700 (PDT) MIME-Version: 1.0 References: <23713.4600.388005.282115@oz.mt.att.com> In-Reply-To: <23713.4600.388005.282115@oz.mt.att.com> From: Christopher Morrow Date: Sun, 31 Mar 2019 18:55:10 -0700 Message-ID: To: Jay Borkenhagen Cc: Ruediger Volk , SIDR Operations WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Sidrops] as23456 in ROAs 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 Apr 2019 01:55:25 -0000 On Sun, Mar 31, 2019 at 12:16 PM Jay Borkenhagen wrote: > > Hi Ruediger, > Hi SIDROps, > > With respect to Ruediger's second presentation at IETF104 last week, > in which he mentioned (among other things) finding as23456 as the > authorized ASN in some published ROAs: > > I checked those ROAs (well, actually their VRPs) and found that in > each current case, the same prefix has been authorized also to > originate in an autonomous system number greater than 65535. Details > below. > > Not saying I like it or would recommend taking steps to work around > networks that still do not grok 4B-ASNs in 2019, but perhaps an > as23456 ROA is not totally without motivation. > ] So, I thought one of the requirements for doing BGPSEC (maybe not OV though?) was: "must have 4-byte capability" clearly signing a ROA for: "shared asn" is a poor plan :( but really you shouldn't ever see 23456 in a secure path... (again, sure that's BGPSEC not OV) funny though. -chris > > > === 138.185.76.0/22 === > AS23456,138.185.76.0/22,24,lacnic > AS263824,138.185.76.0/22,24,lacnic From nobody Sun Mar 31 20:26:26 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 AA1D512004A for ; Sun, 31 Mar 2019 20:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 SR4b76Z0emw3 for ; Sun, 31 Mar 2019 20:26:23 -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 DC61F12003F for ; Sun, 31 Mar 2019 20:26:22 -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 1hAnaV-0000rp-ST; Mon, 01 Apr 2019 03:26:20 +0000 Date: Sun, 31 Mar 2019 20:26:19 -0700 Message-ID: From: Randy Bush To: Christopher Morrow Cc: Jay Borkenhagen , SIDR Operations WG , Ruediger Volk In-Reply-To: References: <23713.4600.388005.282115@oz.mt.att.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 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: Re: [Sidrops] as23456 in ROAs 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 Apr 2019 03:26:25 -0000 > > Not saying I like it or would recommend taking steps to work around > > networks that still do not grok 4B-ASNs in 2019, but perhaps an > > as23456 ROA is not totally without motivation. > > ] > > So, I thought one of the requirements for doing BGPSEC (maybe not OV > though?) was: "must have 4-byte capability" > clearly signing a ROA for: "shared asn" is a poor plan :( but really > you shouldn't ever see 23456 in a secure path... (again, sure that's > BGPSEC not OV) do routers which do not support 4-byte asns support rpki policy to say "mark announcements where the origin is as23456 as notfound?" randy