Subject: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes

From: "Susan Hares" <[email-masked]>
Date: Tue, 10 Jun 2014 10:31:38 -0400

IDR: 

The SIDR WG has asked for cross review of the
draft-ietf-sidr-origin-validation-signaling-04.  This draft changes the RFC
4271 decision process in the following manner: 

If a BGP router supports prefix origin validation and is configured for the
extensions defined in this document, the validation step SHOULD be performed
prior to any of the steps defined in the decision process of [RFC4271
<http://tools.ietf.org/html/rfc4271> ].  The validation step is stated as
follows:
 
      When comparing a pair of routes for a BGP destination, the route
      with the lowest "validation state" value is preferred.
 
In all other respects, the decision process remains unchanged.

The draft is at: 

http://tools.ietf.org/html/draft-ietf-sidr-origin-validation-signaling-04

John and I would like to hear your comments regarding the RFC 4271 revision.
Please send comments that include "support"  or "no support". 

Sue and John

---

From: <[email-masked]>
Date: Tue, 10 Jun 2014 15:40:05 +0000

Hi,

Thanks for the cross WG review. Please find below some proposed comments.

1)      For people not following SIDR, could you please elaborate on why http://tools.ietf.org/html/draft-ietf-idr-custom-decision-04 has not been used? (via the registration of a new Point of Insertion specific to origin validation) (as I though draft-ietf-idr-custom-decision was intended to be the last time BGP decision process would be modified)

2)      Could the document specify the action to be taken when multiple "Origin validation state extended" community are present with different validation state? And how are handled validation state value > 2. (from current text, it would not be considered an error, just lower priority. But I would prefer an explicit statement to avoid surprising error handling behavior)

3)      Rfc 6811 is referenced twice in important sections. What about moving it to "normative reference"?

4)      Following discussion triggered by http://tools.ietf.org/html/draft-decraene-idr-rfc4360-clarification-00 I understood that the IDR conclusion was that a non-transitive community may be attached on the outbound policy of an eBGP session; hence may received over an eBGP session. Given this, IMO the security consideration needs more text. (assuming that the ability for a neighboring AS to influence/force the origin validation state is considered acceptable, which would probably need to be discussed in SIDR)

Thanks,
Regards,
Bruno

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Tuesday, June 10, 2014 4:32 PM
To: idr wg
Cc: Murphy, Sandra; 'John G. Scudder'
Subject: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes

IDR:

The SIDR WG has asked for cross review of the draft-ietf-sidr-origin-validation-signaling-04.  This draft changes the RFC 4271 decision process in the following manner:

If a BGP router supports prefix origin validation and is configured for the extensions defined in this document, the validation step SHOULD be performed prior to any of the steps defined in the decision process of [RFC4271<http://tools.ietf.org/html/rfc4271>].  The validation step is stated as follows:

The draft is at:

John and I would like to hear your comments regarding the RFC 4271 revision.  Please send comments that include "support"  or "no support".

Sue and John

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: <[email-masked]>
Date: Tue, 10 Jun 2014 15:49:05 +0000

5) The text in < deployment consideration > seems a bit weak.
I would say that: "In deployment scenarios where not all the speakers in an autonomous
   system are upgraded to support the extensions defined in this  document, in order to avoid routing loops, it is REQUIRED to define policies" ...

6) For the same purpose, IMO:
OLD: The default SHOULD be for the validation step to be disabled.
NEW: The default MUST be for the validation step to be disabled.

Thanks,
Regards,
Bruno

From: DECRAENE Bruno IMT/OLN
Sent: Tuesday, June 10, 2014 5:40 PM
To: 'Susan Hares'; idr wg
Cc: Murphy, Sandra; 'John G. Scudder'
Subject: RE: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes

Hi,

Thanks,
Regards,
Bruno

IDR:

The draft is at:

Sue and John

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 10 Jun 2014 11:55:08 -0400

It would be useful to include sidr on this discussion.  I've added the wg to the cc list.

--Sandy

On Jun 10, 2014, at 11:49 AM, <[email-masked]> wrote:

> 5) The text in « deployment consideration » seems a bit weak.
> I would say that: “In deployment scenarios where not all the speakers in an autonomous
>    system are upgraded to support the extensions defined in this  document, in order to avoid routing loops, it is REQUIRED to define policies” …
>  
> 2)      Could the document specify the action to be taken when multiple “Origin validation state extended” community are present with different validation state? And how are handled validation state value > 2. (from current text, it would not be considered an error, just lower priority. But I would prefer an explicit statement to avoid surprising error handling behavior)
>  
> 3)      Rfc 6811 is referenced twice in important sections. What about moving it to “normative reference”?
>  
> If a BGP router supports prefix origin validation and is configured for the extensions defined in this document, the validation step SHOULD be performed prior to any of the steps defined in the decision process of [RFC4271].  The validation step is stated as follows:
>  
> John and I would like to hear your comments regarding the RFC 4271 revision.  Please send comments that include “support”  or “no support”.
>  
> Sue and John
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 11 Jun 2014 22:25:31 +0200

Hi Bruno & all,

Just focusing on Q1:

> 1)  For people not following SIDR, could you please elaborate
> on why http://tools.ietf.org/html/draft-ietf-idr-custom-decision-04
> has not been used? (via the registration of a new Point of
> Insertion specific to origin validation) (as I though draft-ietf-idr-
> custom-decision was intended to be the last time BGP decision
> process would be modified)

Few observations:

A. draft-ietf-sidr-origin-validation-signaling does not really modify
a BGP best path selection .. it adds a check before BGP best path
selection algorithm kicks in.

B. Adding new POI is not needed as we already have a POI = 128 which
is to be executed before any step in BGP best path selection hence at
exactly the same point as this draft recommends.

therefor one obvious question comes in:

C. Based on A & B there is clear conflict not addresses in the draft.
Assume both custom decision with POI = 128 "ABSOLUTE_VALUE" as well as
origin validation are enabled. Moreover assume they result in opposite
decisions. So the question of the day is: "Which of those two is the
one to win the pre best path check ?" Effectively - which of those two
is more important ?

The answer to this question should be included in the draft. And I do
suspect authors of both drafts will answer: mine !

Thx,
R.

---

From: <[email-masked]>
Date: Thu, 12 Jun 2014 07:45:38 +0000

Hi Robert, all

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert  Raszuk > Sent: Wednesday, June 11, 2014 10:26 PM
> 
> Hi Bruno & all,
> 
> Just focusing on Q1:
> 
> > 1)  For people not following SIDR, could you please elaborate on why
> > http://tools.ietf.org/html/draft-ietf-idr-custom-decision-04
> > has not been used? (via the registration of a new Point of Insertion
> > specific to origin validation) (as I though draft-ietf-idr-
> > custom-decision was intended to be the last time BGP decision process
> > would be modified)
> 
> Few observations:
> 
> A. draft-ietf-sidr-origin-validation-signaling does not really modify a BGP best
> path selection .. it adds a check before BGP best path selection algorithm
> kicks in.

"3. Changes to the BGP Decision Process"
[...]
"When comparing a pair of routes for a BGP destination, the route with the lowest "validation state" value is preferred."

My reading is that it does change the BGP decision process and the relative priority of the routes.

> B. Adding new POI is not needed as we already have a POI = 128 which is to
> be executed before any step in BGP best path selection hence at exactly the
> same point as this draft recommends.

Using POI=128 is indeed an option. However in theory there could already be existing usage of POI=128, hence possible conflict. In such case, the sub-field "Community-ID" define the priority. It's a priori not possible to define whether origin-validation shoud have a low or high value compared to another possible existing usage.

> decisions. So the question of the day is: "Which of those two is the one to
> win the pre best path check ?" Effectively - which of those two is more
> important ?

You are reading my mind :-).
I assumed that the first document becoming RFC freely define its behavior and then the second will need to adapt (i.e. position itself with regard to the first one). However, given that both documents are worked in different WG, there is a risk that this is missed.
 
> The answer to this question should be included in the draft. And I do suspect
> authors of both drafts will answer: mine !

:-)
Indeed it's up to the authors/WG, but to me "Absolute" seems above any other criteria.

Thanks,
Bruno

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 12 Jun 2014 10:06:14 +0200

Hi Bruno,

Glad we are in sync ;-)

> It's a priori not possible to define whether origin-validation shoud have
> a low or high value compared to another possible existing usage.

Well I do not think it can be left as such.

The entire point of adding the new extended community for propagation
of origin validation result (valid, nf, invalid) is to accomplish
consistency in IBGP.

If you leave it open (ie not specified a priori) there is risk of
different selections of best path in your domain for a given net
(possibly with different exit points) .

Frankly since this ext community is non transitive one could also
depref the routes via local pref .. yes yes I can hear already voices
.. don't touch it - my local pref is for customers ! Except what this
draft defines will easily ignore all those customer local preferences
anyway ... IMO it is all about wisely choosing local pref values.

Cheers,
R.

> On Thu, Jun 12, 2014 at 9:45 AM,  <[email-masked]> wrote:
>
> Hi Robert, all
>

---

From: "Keyur Patel (keyupate)" <[email-masked]>
Date: Thu, 12 Jun 2014 16:52:03 +0000

Hi Bruno,

Thanks for the draft review. Comments inlined #Keyur

From: <[email-masked]<mailto:[email-masked]>>
Date: Tue, 10 Jun 2014 15:40:05 +0000
To: Susan Hares <[email-masked]<mailto:[email-masked]>>, idr wg <[email-masked]<mailto:[email-masked]>>
Cc: "'John G. Scudder'" <[email-masked]<mailto:[email-masked]>>, "Murphy, Sandra" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes

Hi,

#Keyur: The draft don't suggest modifications to the BGP best path algorithm. Infact the next rev of the draft should fix and remove section 3 as well.  The extended community used in draft is use to signal BGP best path validation state within an IBGP network.

#Keyur: There SHOULD not be multiple such extended communities for a given BGP path. We can add the necessary text.

#Keyur: Sure.

#Keyur:  Ideally, the usage of this community should NOT be encouraged across inter-as boundaries.  We can add necessary text to reflect that part.

Regards,
Keyur

Thanks,
Regards,
Bruno

IDR:

The draft is at:

Sue and John

_______________________________________________ Idr mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/idr

---

From: Sandra Murphy <[email-masked]>
Date: Thu, 12 Jun 2014 12:58:43 -0400

Forwarded to sidr to keep them in this discussion.

--Sandy

On Jun 12, 2014, at 12:52 PM, "Keyur Patel (keyupate)" <[email-masked]> wrote:

> From: <[email-masked]>
> To: Susan Hares <[email-masked]>, idr wg <[email-masked]>
> Cc: "'John G. Scudder'" <[email-masked]>, "Murphy, Sandra" <[email-masked]>
> _______________________________________________ Idr mailing list [email-masked] https://www.ietf.org/mailman/listinfo/idr

---

From: Randy Bush <[email-masked]>
Date: Thu, 12 Jun 2014 19:12:57 -0700

> #Keyur: Ideally, the usage of this community should NOT be encouraged
> #across inter-as boundaries.  We can add necessary text to reflect
> #that part.

from rfc 7115, end of sec 5

   Validity state signaling SHOULD NOT be accepted from a neighbor AS.
   The validity state of a received announcement has only local scope
   due to issues such as scope of trust, RPKI synchrony, and management
   of local trust anchors [LTA-USE].

randy

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 13 Jun 2014 10:11:07 +0200

> Validity state signaling SHOULD NOT be accepted from a neighbor AS.

I would agree + also add that setting this extended community by
manual EBGP policy should NOT be supported.

The above along with the fact that this is already non-transitive in
the AS scope should solve that worry completely.

r.

---

From: <[email-masked]>
Date: Fri, 13 Jun 2014 09:02:28 +0000

> I would agree

I agree on the goal.
Now the question is how do you protect from this, if you're unstrusted neighbor AS send this community over eBGP session.

> + also add that setting this extended community by manual
> EBGP policy should NOT be supported.

IMO adding the text "The sender should not do that" is not a very strong protection. Otherwise, we would not need any crypto signature. (e.g. you should not originate a BGP route if you are not the true originator).
You can add the check on the receiver side, but this would now require that all ASBR be upgraded to support this new community, before it could be used. If this is the chosen path, it should be written in the draft in the deployment consideration section
 
> The above along with the fact that this is already non-transitive in the AS
> scope should solve that worry completely.

Not yet.

---

From: <[email-masked]>
Date: Fri, 13 Jun 2014 09:07:11 +0000

> From: Randy Bush [mailto:[email-masked]] > Sent: Friday, June 13, 2014 4:13 AM
> 

Fine.
If this is the choosen way, draft-ietf-sidr-origin-validation-signaling should also say that:
- ASBR should remove such community from routes received over eBGP sessions (possibly modulo confederation, 2 AS from the same organization/trusted...)
- this community must not be used in the AS until all ASBR are upgraded to support draft-ietf-sidr-origin-validation-signaling

---

From: <[email-masked]>
Date: Fri, 13 Jun 2014 09:18:22 +0000

Hi Keyur,

Many thanks for the answers. Comments inline #Bruno
Adding sidr in copy

From: Keyur Patel (keyupate) [mailto:[email-masked]]
Sent: Thursday, June 12, 2014 6:52 PM
To: DECRAENE Bruno IMT/OLN; Susan Hares; idr wg
Cc: 'John G. Scudder'; Murphy, Sandra
Subject: Re: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes

Hi Bruno,

Hi,

#Keyur: The draft don't suggest modifications to the BGP best path algorithm. Infact the next rev of the draft should fix and remove section 3 as well.  The extended community used in draft is use to signal BGP best path validation state within an IBGP network.
#Bruno: current version (04) of the  draft do change the BGP decision process. cf section 3.
If you remove section 3 in the next revision, this is indeed a different story.

#Keyur: There SHOULD not be multiple such extended communities for a given BGP path. We can add the necessary text.
#Bruno: I agree on the goal. The question is how do you handle the case/error when there is more than one.
I guess that this is less important if you remove section 3 and this community is purely informative with no impact on BGP decision process.

#Keyur: Sure.

4)      Following discussion triggered by http://tools.ietf.org/html/draft-decraene-idr-rfc4360-clarification-00 I understood that the IDR conclusion was that a non-transitive community may be attached on the outbound policy of an eBGP session; hence may received over an eBGP session. Given this, IMO the security consideration needs more text. (assuming that the ability for a neighboring AS to influence/force the origin validation state is considered acceptable, which would probably need to be discussed in SIDR)
#Keyur:  Ideally, the usage of this community should NOT be encouraged across inter-as boundaries.  We can add necessary text to reflect that part.
#Bruno: I agree on the goal. The question is how do you handle the case (error/attack) where your untrusted neighbor sends you this community over an eBGP session.

Regards,
Keyur

Thanks,
Regards,
Bruno

IDR:

The draft is at:

Sue and John

Thank you.

---

From: <[email-masked]>
Date: Fri, 13 Jun 2014 09:26:12 +0000

Randy,

> From: DECRAENE Bruno IMT/OLN > Sent: Friday, June 13, 2014 11:07 AM
> 
> 
> 
> > > #Keyur: Ideally, the usage of this community should NOT be
> > > encouraged #across inter-as boundaries.  We can add necessary text
> > > to reflect #that part.
> >
> - ASBR should remove such community from routes received over eBGP
> sessions (possibly modulo confederation, 2 AS from the same
> organization/trusted...)
> - this community must not be used in the AS until all ASBR are upgraded to
> support draft-ietf-sidr-origin-validation-signaling

Just to clarify, my goal was to clarify that "non-transitive" community are accepted over eBGP and hence is not a guaranty that this information was originated by the local AS hence assumed to be trusted.
I don't feel this is self-obvious from the name, hence my comment for information.

Regards,
Bruno

---

From: "Keyur Patel (keyupate)" <[email-masked]>
Date: Sat, 14 Jun 2014 07:07:04 +0000

Hi Bruno,

On 6/13/14 2:02 AM, "[email-masked]"
<[email-masked]> wrote:

>Now the question is how do you protect from this, if you're unstrusted
>neighbor AS send this community over eBGP session.

I suggest we log an error and drop the community.

Regards,
Keyur

>IMO adding the text "The sender should not do that" is not a very strong
>protection. Otherwise, we would not need any crypto signature. (e.g. you
>should not originate a BGP route if you are not the true originator).
>You can add the check on the receiver side, but this would now require
>that all ASBR be upgraded to support this new community, before it could
>be used. If this is the chosen path, it should be written in the draft in
>the deployment consideration section
> 
>>the AS
>__________________________________________________________________________
>Ce message et ses pieces jointes peuvent contenir des informations
>confidentielles ou privilegiees et ne doivent donc
>pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
>recu ce message par erreur, veuillez le signaler
>a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
>electroniques etant susceptibles d'alteration,
>This message and its attachments may contain confidential or privileged
>information that may be protected by law;

---

From: <[email-masked]>
Date: Sat, 14 Jun 2014 16:57:08 +0000

Hi Keyur,

> From: Keyur Patel (keyupate) [mailto:[email-masked]] > Sent: Saturday, June 14, 2014 9:07 AM
> 
> Hi Bruno,
> 
> 

Looks good. Could you please add this in the draft?

Thanks.
Bruno

> >IMO adding the text "The sender should not do that" is not a very
> >strong protection. Otherwise, we would not need any crypto signature.
> >(e.g. you should not originate a BGP route if you are not the true
> originator).
> >that all ASBR be upgraded to support this new community, before it
> >could be used. If this is the chosen path, it should be written in the
> >draft in the deployment consideration section
> >
> >_________________________________________________________
> ______________
> >___ _______________________________________________
> >
> >confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> >exploites ou copies sans autorisation. Si vous avez recu ce message par
> >erreur, veuillez le signaler a l'expediteur et le detruire ainsi que
> >les pieces jointes. Les messages electroniques etant susceptibles
> >d'alteration, Orange decline toute responsabilite si ce message a ete
> >altere, deforme ou falsifie. Merci.
> >
> >information that may be protected by law; they should not be
> >distributed, used or copied without authorisation.

---

From: "Keyur Patel (keyupate)" <[email-masked]>
Date: Sun, 15 Jun 2014 01:00:16 +0000

Hi Bruno,

>Looks good. Could you please add this in the draft?

Sure.

Regards,
Keyur