Subject: Re: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 17/September/2020

From: Keyur Patel <[email-masked]>
Date: Thu, 10 Sep 2020 17:27:34 +0000

Hi Folks,

The wg chairs extended the call for a week in hopes that we would have a consensus. Seems like more discussion is needed and so we plan extend the call for 1 more week. The WGLC will now end on September 17, 2020

Best Regards,
Keyur

From: Keyur Patel <[email-masked]>
Date: Tuesday, August 11, 2020 at 11:45 AM
To: "[email-masked]" <[email-masked]>
Subject: [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 25/August/2020

Hi Folks:

A working group last call has been requested for draft-sidrops-bgpsec-validation-signaling-03, “BGPsec Validation State Signaling”. Please reply to the list with your comments. The WGLC will end on August 25, 2020.

The draft can be found at:  https://tools.ietf.org/html/draft-sidrops-bgpsec-validation-signaling-03.  Authors, please reply indicating whether you're aware of any relevant IPR that hasn't been disclosed.

Regards,
Keyur

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 21 Sep 2020 21:42:38 +0100

Keyur Patel wrote on 10/09/2020 18:27:
> The wg chairs extended the call for a week in hopes that we would have a 
> consensus. Seems like more discussion is needed and so we plan extend 
> the call for 1 more week. TheWGLCwill now end on September 17, 2020

this comment is coming a bit late in the day, but I think it would be an 
idea to clarify the behaviour of the receiving bgp side a little better.

>    A receiving BGPsec enabled router SHOULD use the received BGPsec path
>    validation state in situations where a locally computed BGPsec
>    validation result is not currently available.  In the absence of the
>    extended community, the receiving BGPsec enabled router MUST NOT make
>    any assumption about the validation sate of the UPDATE.

The second sentence is a no-op, so it would probably be better to remove it.

The draft intends that the bgp receiver treats routes with this extcomm 
as if they were locally validated by bgpsec.  The simplified state 
outcome is:

1. the receiving bgp implementation has bgpsec enabled, and has computed 
a local validation result for the incoming prefix

2. the receiving bgp implementation supports bgpsec, but has not 
computed a local validation result for the incoming prefix

3. the receiving bgp implementation does not support bgpsec.

At the moment, the text deals with case #2.  Probably what you want to 
do here is state that local validation takes preference over the 
community value.

Here's some suggested text as a replacement for the paragraph above, 
which deals with #1 and #2:

>    A receiving BGPsec enabled router SHOULD use the received BGPsec path
>    validation state in situations where a locally computed BGPsec
>    validation result is not currently available.  If a locally computed BGPsec
>    validation result is available, then the received BGPsec path validation
>    state MUST be ignored.
I'm not sure what you intend with state #3. The choices here are: SHOULD 
implement alternative policy handling mechanism, SHOULD NOT implement 
alternative policy handling mechanism, or no advice.

Some of this behaviour could be synthesised using normal policy hooks in 
the bgp stack's configuration grammar, but that would need coding and 
could be messy if there were ever future plans to support bgpsec because 
then there would be two frameworks, probably incompatible with each 
other.  It would certainly be easier for implementers to state that the 
draft is not intended for bgp stacks which don't already implement 
bgpsec.  Do the authors have any thoughts on this one?

Nick

---

From: Keyur Patel <[email-masked]>
Date: Mon, 21 Sep 2020 20:56:55 +0000

Thanks for the comments/clarifications Nick. __

On 9/21/20, 1:42 PM, "Nick Hilliard" <[email-masked]> wrote:

    Nick

---

From: "Borchert, Oliver (Fed)" <[email-masked]>
Date: Mon, 21 Sep 2020 21:51:00 +0000

Hi Nick,
Please see inline, I added an [ob] in front of my answers. 

On 9/21/20, 4:43 PM, "Sidrops on behalf of Nick Hilliard" <[email-masked] on behalf of [email-masked]> wrote:

[ob] We added that exact wording because during 108, concerns were voiced that 
[ob] implementations could interpret the absence of the community string as a 
[ob] particular validation result. To prevent this from happening this addition 
[ob] was specifically requested. 

[ob] RFC 8205 clearly states that a router can differ local validation. A good
[ob] reason for that could be a temporary resource shortage. In both cases #1 and
[ob] #2, I would assume that the implementation follows RFC 8205.

[ob] My understanding was always that local validation takes precedence over 
[ob] the community value. The community value can be used until local validation
[ob] is performed. The community attribute serves two purposes. Signaling 
[ob] the validation state within the boundaries of RFC4360 to (1) allow using
[ob] a validation state until the router can perform the validation and (2) for 
[ob] operators to have a tool for diagnosis.

[ob] I am not really concerned with case #3 because even without the community,
[ob] operators can create an ext. comm. to signal the validation state to non 
[ob] BGPsec speakers. 

[ob] I believe that this community string serves multiple purposes as explained 
[ob] above and if someone really wants to use community strings to send a 
[ob] BGPsec validation state to a non BGPsec speaker, they can do so already by
[ob] hand crafting their own community. Again as it was mentioned during some 
[ob] email exchange on the list some time ago, the absence of the ext. com. does 
[ob] not prevent operators of sending validation results. 

    Nick

Oliver

---

From: "Borchert, Oliver (Fed)" <[email-masked]>
Date: Tue, 22 Sep 2020 20:37:12 +0000

I just uploaded the new version of the document including modifications
Made in the following areas.

I had discussions around extended community, eBGP, and RFC4360 including the 
last discussion, Nick has brought to the list. 

Today we modified the draft text and uploaded the newest version. The new version 
does address the issues that were raised during the WLC. Below I try to explain 
a bit the changes and the motivation. 

Of course the regular diff version does the same job.
https://tools.ietf.org/html/draft-sidrops-bgpsec-validation-signaling-04

Thanks to all for the discussion and input,
Oliver

Modification 1:
=================
This addresses the issue with RFC4360 and eBGP

Original Text:
   ...
   If the router supports the extension as defined in this document, it 
   SHOULD attach the BGPsec path validation state extended community to 
   BGPsec UPDATE messages sent to BGP peers by mapping the locally 
   computed validation state into the last octet of the extended community.  
   This SHOULD be done automatically for iBGP peers and configurable for 
   eBGP peers (see below).

The last Sentence:
  This SHOULD be done automatically for iBGP peers and
   configurable for eBGP peers (see below).

Is replaced with:
   Operational behavior is governed by Section 6 of [RFC4360].

Modification 2:
=================
This modification addresses Nicks comment regarding the absence of the 
ext comm attribute and what that meant regarding the validation state 
of the UPDATE 

 Original Text:
   In the absence of the extended community, the receiving BGPsec enabled 
   router MUST NOT make any assumption about the validation sate of the 
   UPDATE.

 We added the word "peer's" in front of validation:
   In the absence of the extended community, the receiving BGPsec enabled 
   router MUST NOT make any assumption about the peer's validation state 
   of the UPDATE.

Modification 3:
=================
This addresses Nicks comment regarding the local validation vs. received 
validation. We added the following sentence to the paragraph of Modification 2

Added sentence:
   A locally computed validation state for an UPDATE takes precedence over
   the received validation state.

Modification 4:
=================
This modification removed the mention of eBGP and other handlings of the 
ext com. It is generally handled in RFC4360. We also addressed case #3 of Nick
where a non-BGPsec speaker is involved.

Original Text: 
   By default, routers SHOULD enable use of this community on all iBGP sessions 
   and routers SHOULD disable the use of this community on all eBGP sessions.
   Implementations MUST NOT send more than one instance of the origin validation 
   state extended community and MUST drop (without processing) the BGPsec path 
   validation state extended community if received over an External BGP (eBGP) 
   peering session that has not be explicitly configured to enable processing.

New Text:
  By default, routers SHOULD enable use of this community 
  on all iBGP sessions.  Implementations MUST NOT send more than one instance 
  of the BGPsec validation state extended community. Implementations MUST NOT 
  send the extended community if not in a BGPsec UPDATE. 

  Implementations MUST drop (without processing) the BGPsec path validation 
  state extended community if received over a peering session where either 
  the usage is not enabled or it is not part of a BGPsec UPDATE.

Oliver
-----------------------------------------------
Oliver Borchert, Computer Scientist
National Institute of Standards and Technology

On 9/21/20, 5:51 PM, "Borchert, Oliver (Fed)" <[email-masked]> wrote:

    Hi Nick,

        Nick

    Oliver

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 25 Sep 2020 13:06:41 +0100

> [ob] was specifically requested.

right, noted.  I missed the discussion about this in the ietf 108 
sidrops session.

> [ob] the community value.

Ben Maddison brought up implementation differences at the ietf108 
session. You're right that it's probably obvious to anyone on the 
SIDROPS WG that native BGPsec evaluation should take precedence, but 
developers or other people reading the specs may make different 
decisions because they're going to approach the document from a 
different point of view.  It would be clearer to make this explicit, 
e.g. to add a single sentence in the Deployment Considerations section 
to say:

"If the received validation state of a route differs from a BGPsec 
validation state locally computed according to [RFC8205], then the 
locally computed BGPsec validation state MUST be used and the received 
validation state MUST be ignored".

On a separate thing, getting back to ebgp stuff, the Deployment 
Considerations section says:

>    Furthermore, one can envision that the operator of a BGPsec router
>    decides to defer local BGPsec validation when a validation state
>    value is learned via iBGP or a trusted eBGP peer.

This needs to be reworded because there is no concept of "trusted eBGP" 
in rfc4360.  Maybe reword as "... when a validation state value is 
learned via BGP", and just revert to the default behaviour from 4360?

also nit:

>    Implementations MUST drop (without processing) the BGPsec path
>    validation state extended community if received over a peering
>    session where either the usage is not enabled or it is not part of a
>    BGPsec UPDATE.

s/peering session/BGP session/

Nick

---

From: "Borchert, Oliver (Fed)" <[email-masked]>
Date: Fri, 25 Sep 2020 18:15:19 +0000

Hi Nick,

I'll go inline again, I'll post an update later today,

Oliver

(Office) +1.301.975.4856
(GVoice) +1.240.668.4117

On 9/25/20, 8:07 AM, "Nick Hilliard" <[email-masked]> wrote:

[ob]
[ob] Sounds good, I'll add that to the end of the "deployment consideration"
[ob]

[ob]
[ob] Agreed. It now will read:
[ob]
[ob]  Furthermore, one can envision that the operator of a BGPsec router decides 
[ob]  to defer local BGPsec validation when a validation state value is learned 
[pb]  via BGP.
[ob]

[ob]
[ob] Agreed.
[ob]

    Nick