Subject: [Sidrops] WG Adoption call for draft-borchert-sidrops-bgpsec-validation-signaling-01 (9/16-9/30)

From: Keyur Patel <[email-masked]>
Date: Mon, 16 Sep 2019 19:12:08 +0000

Hi Folks,

The authors have requested SIDROPS working group adoption call of “BGPsec Validation State Signaling”, https://tools.ietf.org/html/draft-borchert-sidrops-bgpsec-validation-signaling-01.

Please send your comments to the list. This adoption call will conclude on Sep 30 2019.

Regards,

Chris & Keyur

---

From: Randy Bush <[email-masked]>
Date: Mon, 16 Sep 2019 14:13:36 -0700

"This document defines a new BGP non-transitive extended community to
carry the BGPsec path validation state inside an autonomous system."

given the one in RFC 8097, we need a new one because?

randy

---

From: Randy Bush <[email-masked]>
Date: Mon, 16 Sep 2019 14:28:11 -0700

> given the one in RFC 8097, we need a new one because?

i have the same issue with draft-ietf-sidrops-validating-bgp-speaker-03

can we settle for one community?  though i am not particularly enamoured
with the extended one in 8097, at least we have it.

randy

---

From: "Montgomery, Douglas (Fed)" <[email-masked]>
Date: Mon, 16 Sep 2019 23:02:05 +0000

Randy,

Are you suggesting keeping the 0x43 0x00 code point, but redefining its validation state byte with additional values and meanings for path validation?

Or carving off another byte from reserved?

Either of those sounds fine and save bits.   

Clearly there would need to be a new spec that that adds the words to do that.

dougm
--
Doug Montgomery, Manager Internet  & Scalable Systems Research @ NIST

On 9/16/19, 5:13 PM, "Sidrops on behalf of Randy Bush" <[email-masked] on behalf of [email-masked]> wrote:

    
    randy
    
    _______________________________________________

---

From: "Borchert, Oliver (Fed)" <[email-masked]>
Date: Tue, 17 Sep 2019 19:52:49 +0000

Randy Bush <[email-masked]> Keyur Patel <[email-masked]>
[email-masked] <[email-masked]>

>    randy 
 
RFC 8097 clearly deals with RPKI only and has a different set of validation states than BGPsec. (e.g. not-found does not exist in BGPsec.)
As RFC 8097 is currently written, we cannot communicate two independent validation results and BGPsec and RPKI can have different validation results - they do not rely on each other. 

So yes, we are in the need of a new one.

Oliver

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 24 Sep 2019 19:32:22 +0000

I would be in favor of carving off another byte from the reserved field.
Redefining the validation state to add the new information instead would confuse older receivers that do not understand the new code points.

In addition, I would add another point to the BGPSec validation state: BGPSec attribute not present or in error.

   +-------+------------------------------+
   | Value | Meaning                      |
   +-------+------------------------------+
   |   0   | Lookup result = "Unverified" |
   |   1   | Lookup result = "Valid"      |
   |   2   | Lookup result = "Not valid"  |
   |   3   | Lookup result = "BGPSec attribute not present or in error"
   +-------+------------------------------+

If it were to use a reserved byte of the RFC8097 community, 0 for unverified would work, I think.

Regards,
Jakob.

-----Original Message-----
From: Sidrops <[email-masked]> On Behalf Of Montgomery, Douglas (Fed)
Sent: Monday, September 16, 2019 4:02 PM
To: Randy Bush <[email-masked]>; Keyur Patel <[email-masked]>
Cc: [email-masked]
Subject: Re: [Sidrops] WG Adoption call for draft-borchert-sidrops-bgpsec-validation-signaling-01 (9/16-9/30)

Randy,

dougm

    
    
    randy

_______________________________________________
Sidrops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidrops

---

From: "Borchert, Oliver (Fed)" <[email-masked]>
Date: Wed, 25 Sep 2019 15:01:00 +0000

Jakob, 

I agree, adding the BGPsec information into the RFC 8097 communities "reserved" field 
seems definitely be a good solution and I can easily modify the proposed draft to do that.  

Oliver

-----Original Message-----
From: Sidrops <[email-masked]> On Behalf Of Jakob Heitz (jheitz)
Sent: Tuesday, September 24, 2019 3:32 PM
To: Montgomery, Douglas (Fed) <dougm=[email-masked]>; Randy Bush <[email-masked]>; Keyur Patel <[email-masked]>
Cc: [email-masked]
Subject: Re: [Sidrops] WG Adoption call for draft-borchert-sidrops-bgpsec-validation-signaling-01 (9/16-9/30)

Regards,
Jakob.

-----Original Message-----
From: Sidrops <[email-masked]> On Behalf Of Montgomery, Douglas (Fed)
Sent: Monday, September 16, 2019 4:02 PM
To: Randy Bush <[email-masked]>; Keyur Patel <[email-masked]>
Cc: [email-masked]
Subject: Re: [Sidrops] WG Adoption call for draft-borchert-sidrops-bgpsec-validation-signaling-01 (9/16-9/30)

Randy,

dougm

    
    
    randy

_______________________________________________
Sidrops mailing list
[email-masked]
https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsidrops&amp;data=02%7C01%7Coliver.borchert%40nist.gov%7C43f29b9643dc4705595508d74125f6d5%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637049503640406944&amp;sdata=N1%2ByCkKcQD4zf6sbr9%2B7e5QnwB6wq%2BRIcaHUvYhSLW4%3D&amp;reserved=0
_______________________________________________
Sidrops mailing list
[email-masked]
https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsidrops&amp;data=02%7C01%7Coliver.borchert%40nist.gov%7C43f29b9643dc4705595508d74125f6d5%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637049503640406944&amp;sdata=N1%2ByCkKcQD4zf6sbr9%2B7e5QnwB6wq%2BRIcaHUvYhSLW4%3D&amp;reserved=0

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Wed, 25 Sep 2019 15:11:13 +0000

Hi,

I do not believe your proposal of a new state is adequate:
   |   3   | Lookup result = "BGPSec attribute not present or in error"

Looks to me that you want to add more context on the reasons for invalidating an update but that should not be in the "validation state":
	- You could be in "unverified" state because the attribute was not present. 
	- Independently if there was an "error" (whatever it means), the state will still be "invalid" as validation was tried and failed.

Regards,
Roque

On 25.09.19, 17:01, "Sidrops on behalf of Borchert, Oliver (Fed)" <[email-masked] on behalf of oliver.borchert=[email-masked]> wrote:

    Jakob, 

    Oliver
    
    -----Original Message-----
    From: Sidrops <[email-masked]> On Behalf Of Jakob Heitz (jheitz)
    Sent: Tuesday, September 24, 2019 3:32 PM
    To: Montgomery, Douglas (Fed) <dougm=[email-masked]>; Randy Bush <[email-masked]>; Keyur Patel <[email-masked]>
    Cc: [email-masked]
    Subject: Re: [Sidrops] WG Adoption call for draft-borchert-sidrops-bgpsec-validation-signaling-01 (9/16-9/30)

    

    Regards,
    Jakob.
    
    -----Original Message-----
    From: Sidrops <[email-masked]> On Behalf Of Montgomery, Douglas (Fed)
    Sent: Monday, September 16, 2019 4:02 PM
    To: Randy Bush <[email-masked]>; Keyur Patel <[email-masked]>
    Cc: [email-masked]
    Subject: Re: [Sidrops] WG Adoption call for draft-borchert-sidrops-bgpsec-validation-signaling-01 (9/16-9/30)
    
    Randy,

    

    dougm

        
        
        randy

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 25 Sep 2019 15:57:23 +0000

To solve your problem with too much information, I advise you to treat it the same as unverified in your route-policy.

Thanks,
Jakob.

> On Sep 25, 2019, at 8:11 AM, Roque Gagliano (rogaglia) <[email-masked]> wrote:
> 
> Hi,
>

---

From: "Montgomery, Douglas (Fed)" <[email-masked]>
Date: Wed, 25 Sep 2019 16:16:00 +0000

While I support Jakob's idea of taking a reserved byte from RFC8097 for signaling path validation state, I am unclear what the proposed use of the value 3 is.   I will note, that explaining this proposed use in the context of the error handling rules of RFC8205 (https://tools.ietf.org/html/rfc8205#section-5.2) would be useful.

Having said that - getting agreement on how/where to encode the signal first - then hashing out any other code points other than the obvious ones would seem like the way to proceed.

dougm

On 9/25/19, 11:11 AM, "Roque Gagliano (rogaglia)" <[email-masked]> wrote:

    Hi,

    
    Regards,
    Roque

        Jakob, 

        Oliver
        
        -----Original Message-----
        From: Sidrops <[email-masked]> On Behalf Of Jakob Heitz (jheitz)
        Sent: Tuesday, September 24, 2019 3:32 PM
        To: Montgomery, Douglas (Fed) <dougm=[email-masked]>; Randy Bush <[email-masked]>; Keyur Patel <[email-masked]>
        Cc: [email-masked]
        Subject: Re: [Sidrops] WG Adoption call for draft-borchert-sidrops-bgpsec-validation-signaling-01 (9/16-9/30)

        

        Regards,
        Jakob.
        
        -----Original Message-----
        From: Sidrops <[email-masked]> On Behalf Of Montgomery, Douglas (Fed)
        Sent: Monday, September 16, 2019 4:02 PM
        To: Randy Bush <[email-masked]>; Keyur Patel <[email-masked]>
        Cc: [email-masked]
        Subject: Re: [Sidrops] WG Adoption call for draft-borchert-sidrops-bgpsec-validation-signaling-01 (9/16-9/30)
        
        Randy,

        

        dougm

            
            
            randy

        _______________________________________________
        Sidrops mailing list
        [email-masked]
        https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsidrops&amp;data=02%7C01%7Cdougm%40nist.gov%7Cb719ffb86d1c4bbae1d408d741caa222%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637050210864138120&amp;sdata=TL%2FHxcVgC2OY5c7PtSAcH%2FffM3Upy98O0qCoFyhuIL8%3D&amp;reserved=0
        _______________________________________________
        Sidrops mailing list
        [email-masked]
        https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsidrops&amp;data=02%7C01%7Cdougm%40nist.gov%7Cb719ffb86d1c4bbae1d408d741caa222%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637050210864138120&amp;sdata=TL%2FHxcVgC2OY5c7PtSAcH%2FffM3Upy98O0qCoFyhuIL8%3D&amp;reserved=0
        _______________________________________________
        Sidrops mailing list
        [email-masked]
        https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsidrops&amp;data=02%7C01%7Cdougm%40nist.gov%7Cb719ffb86d1c4bbae1d408d741caa222%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637050210864138120&amp;sdata=TL%2FHxcVgC2OY5c7PtSAcH%2FffM3Upy98O0qCoFyhuIL8%3D&amp;reserved=0