Subject: [RTG-DIR] draft-ietf-grow-blackholing-02.txt - Directorate review

From: "Susan Hares" <[email-masked]>
Date: Tue, 2 Aug 2016 12:41:15 -0400

I have been selected as the Routing Directorate and the Operational/NM 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 Operations Area directorate seeks to review all documents to determine if protocol mechanism are deployable. 

For details on the Routing Directorate, please see  <http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir> ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir.

For details on the Operational, please see RFC5706 and https://svn.tools.ietf.org/area/ops/trac/wiki/Directorates

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:  <http://tools.ietf.org/html/draft-name-version> draft-name-version.txt 
Reviewer: your-name 
Review Date: date 
IETF LC End Date: date-if-known 
Intended Status: copy-from-I-D

·         Summary: I have a major and minor concerns about this document that should be resolved prior to publications.  I have provide the highlights of these issues, but I am willing to help the authors quickly craft changes to their draft.  This community is useful to BGP deployments. 

Major: 

·         Interaction of BGP Blackhole community with:  BGP Flow Specification Communities that provide actions (RFC5575 and additional filters and actions being specified in IDR (draft-ietf-idr*flowspec*).  

·         BGP error actions based on RFC7606.  

Minor 

·         The document does not indicate whether combining ROA (RFC6483) plus this BGP community would resolve the concerns that the community comes from the authorized origin of the prefix that will be blackholed.  Sections 3.3 and 6 should be altered to provide the additional details on this point. 

·          Operational issues should cover whether this can be used in a IXP and Data Center. 

Comments:

*	Please supply an overview of the draft quality and readability.
*	Include anything else that you think will be helpful toward understanding your review.

Minor Issues:

·         [RTG-DIR] The document does not indicate whether combining ROA (RFC6483) plus this BGP community would resolve the concerns that the community comes from the authorized origin of the prefix that will be blackholed. 

*	[OPS-DIR]:  The different deployment scenarios for BGP are not considered in an operational section. These scenarios include (but are not limited to):  a) provider bgp, b) private vpn bgp, c) Data Center BGP, and d) IXP bgp. 

RFC minor issues 

*	 Please reference RFC 1997 in section 3.2 in the first sentence.   Pick one solution (NO_ADVERTISE or NO_EXPORT].   NO_ADVERTISE is a stronger restriction. 
*	 Please reference RFC4271 as the main BGP specification.  Change initial BGP reference outside of the abstract to include this reference. 

NITs 

·         Abstract  “namely BLACKHOLE, allows” to “named BLACKHOLE which allows”

·         Section 3.3 – “it has been observed” – is a very vague statement.  It need to be clarified by where it is observed.   

o   Alternative” “It has been observed in BGP data records (reference)” or “It has been observed in provider networks running BGP”> 

Sue Hares

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 2 Aug 2016 12:52:52 -0400

I forgot one other editorial nit  also discussed in the mail thread: 

https://www.ietf.org/mail-archive/web/grow/current/msg03516.html

the grow WG discuss suggests that the authors should indicate how this draft is different than an update to RFC5635.  For the operational directorate review, this would be necessary so operators can work with both the advice in RFC5635 and this draft.   
 
Thank you, 
 
Sue 

From: Susan Hares [mailto:[email-masked]] 
Sent: Tuesday, August 2, 2016 12:41 PM
To: [email-masked]'; [email-masked]'; [email-masked]'
Cc: 'Zhangxian (Xian)'; 'Alia Atlas'; 'Benoit Claise (bclaise)'; 'Joel jaeggli'
Subject: draft-ietf-grow-blackholing-02.txt - Directorate review 

Major: 

Minor 

Comments:

Minor Issues:

RFC minor issues 

NITs 

Sue Hares

---

From: Job Snijders <[email-masked]>
Date: Tue, 2 Aug 2016 19:40:27 +0200

Dear Susan,

On Tue, Aug 02, 2016 at 12:41:15PM -0400, Susan Hares wrote:
> I have been selected as the Routing Directorate and the Operational/NM
> directorate reviewer for this draft.

> · Summary: I have a major and minor concerns about this document that
> should be resolved prior to publications.  I have provide the
> highlights of these issues, but I am willing to help the authors
> quickly craft changes to their draft.  This community is useful to BGP
> deployments. 
> 
> Major: 
> 
> · Interaction of BGP Blackhole community with: BGP Flow Specification
> Communities that provide actions (RFC5575 and additional filters and
> actions being specified in IDR (draft-ietf-idr*flowspec*).  

I am not sure whether I understand your concern, RFC5575 does not
reference RFC 1997. draft-ietf-grow-blackholing provides nothing more
than a codepoint, any interaction or meaning is left as an excercise for
the network operator.

> · BGP error actions based on RFC7606.

Can you elaborate what the concern is? A similar well-known community
defined in RFC 3765 doesn't have specific BGP error handling. Should
some text be included "This document does not update RFC 7606" ? That
would seem somewhat superfluous to me.

> Minor 
> 
> · The document does not indicate whether combining ROA (RFC6483) plus
> this BGP community would resolve the concerns that the community comes
> from the authorized origin of the prefix that will be blackholed.
> Sections 3.3 and 6 should be altered to provide the additional details
> on this point. 

Correct, the document does not indicate whether RFC6483 resolves
concerns. I consider it out of scope how to validate authorized origins
of a prefix for the definition of this codepoint. 

The use of blackholing techniques predates RFC6483.

I am hesitant to include references to RFC6483, because as an example
NTT does not use ROAs yet is able to offer blackholing services to its
customers today. I don't think that draft-ietf-grow-blackholing should
depend on RFC6483, nor do I want to venture into the problem space "how
to validate origins".

Do you agree?

> *	[OPS-DIR]:  The different deployment scenarios for BGP are not
> considered in an operational section. These scenarios include (but are
> not limited to):  a) provider bgp, b) private vpn bgp, c) Data Center
> BGP, and d) IXP bgp. 

Can you clarify? As an example: all NTT's routers are located in Data
Centers, already today we offer our customers a blackholing community
(namely 2914:666) and this works fine.

I've heard of IXPs that encourage participants to implement routing
policy to honor a blackhole community. There has been some pushback on
the GROW mailinglist about using the word "IXP" in the document, it was
then decided to omit references to IXPs to address that concern.

Essentially the deployment scope is up to the operator, just like today
with their own RFC 1997 blackhole community.

I am also not sure what "IXP bgp" means.

> RFC minor issues 
> 
> *	 Please reference RFC 1997 in section 3.2 in the first sentence.
> Pick one solution (NO_ADVERTISE or NO_EXPORT].   NO_ADVERTISE is a
> stronger restriction. 

I can add a reference, but I cannot pick one solution. Whether
NO_ADVERTISE or NO_EXPORT or another community should be used is up to
the operator, it highly depends on their routing policy which strategy
is best.

Generally I advise against using NO_ADVERTISE, unless you are 100%
certain it accomplishes what you need in an economic fashion. We can
change the line to:

    "A BGP speaker receiving a BGP announcement tagged with the
    BLACKHOLE BGP community SHOULD add NO_EXPORT or similar community to
    prevent propagation of this route outside the local AS."

> *	 Please reference RFC4271 as the main BGP specification.  Change
> initial BGP reference outside of the abstract to include this
> reference. 

OK. We'll do this.

> · Section 3.3 – “it has been observed” – is a very vague statement.
> It need to be clarified by where it is observed.   
> 
> o   Alternative” “It has been observed in BGP data records
> (reference)” or “It has been observed in provider networks running
> BGP”> 

Why is the "(see section 6.1.3 [RFC7454])" not appropiate?

> the grow WG discuss suggests that the authors should indicate how this
> draft is different than an update to RFC5635.  For the operational
> directorate review, this would be necessary so operators can work with
> both the advice in RFC5635 and this draft.   

It is not an update to RFC5635? I am not sure how to address this
comment, clearly the two documents are different.

Kind regards,

Job

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 2 Aug 2016 14:42:56 -0400

Job: 

See comments below

-----Original Message-----
From: rtg-dir [mailto:[email-masked]] On Behalf Of Job Snijders
Sent: Tuesday, August 2, 2016 1:40 PM
To: Susan Hares; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [RTG-DIR] draft-ietf-grow-blackholing-02.txt - Directorate review

Dear Susan,

> I am not sure whether I understand your concern, RFC5575 does not reference RFC 1997. draft-ietf-grow-blackholing provides nothing more than a codepoint, any interaction or meaning is left as an excercise for the network operator.

I realize you are just providing an encoding.  For the protocol encoding assignment of a BGP community, the encoding is fine.  The operational functions need to consider what happens if you have RFC5575 (NLRI + Extended community), handling DDoS filtering.  If you do not intend to support the Community associated with RFC5575 NLRI, then please indicate this in an operations section.  If you do intend to allow this community to associated with a RFC5575 NLRI, please specify the precedence of the filtering, Actions.
The purpose of this major comment is to have you clearly indicate how these potentially interacting communities (RFC5575bis) for RFC5575 NLRI interact. 

>Can you elaborate what the concern is? A similar well-known community defined in RFC 3765 doesn't have specific BGP error handling. Should some text be included "This document does not update RFC 7606" ? That would seem somewhat superfluous to me.

RFC7606 specify what happens if the community is misformed.  See section 7.8.  If the community is malformed, it will be treated as a withdraw.  If you wish another error handling (because it is just notification of DDoS), you can add an alternative process. If you just want to accepted the RFC7606 specification, then simply say.  "The error handling for this community follows the process in RFC7606 that causes a malformed community to be treated as a withdrawl." 

>Correct, the document does not indicate whether RFC6483 resolves concerns. I consider it out of scope how to validate authorized origins of a prefix for the definition of this codepoint. 

>I am hesitant to include references to RFC6483, because as an example NTT does not use ROAs yet is able to offer blackholing services to its customers today. I don't think that draft-ietf-grow-blackholing should depend on RFC6483, nor do I want to venture into the problem space "how to >validate origins".
>Do you agree?

I am fine with your solution. All you need is to clearly state what you have said in this message.   ROAs are not widely deployment.  Considering a solution which depends on ROAs is not in the scope of this draft. 

>Can you clarify? As an example: all NTT's routers are located in Data Centers, already today we offer our customers a blackholing community (namely 2914:666) and this works fine.

Just state that you except it to work in all types of BGP environments (DC, IXP, providers, private VPNS).  

>I've heard of IXPs that encourage participants to implement routing policy to honor a blackhole community. There has been some pushback on the GROW mailinglist about using the word "IXP" in the document, it was then decided to omit references to IXPs to address that concern.
> Essentially the deployment scope is up to the operator, just like today with their own RFC 1997 blackhole community.

It is my short hand to indicate the changes to BGP (e.g. route server) that make BGP function in an IXP environment.  You do not need to use that phrase. 

>I can add a reference, but I cannot pick one solution. Whether NO_ADVERTISE or NO_EXPORT or another community should be used is up to the operator, it highly depends on their routing policy which strategy is best.

If this is so, explain this fact in the operations section. 

>Generally I advise against using NO_ADVERTISE, unless you are 100% certain it accomplishes what you need in an economic fashion. We can change the line to:

This is fine or simply explaining that either NO_ADVERTISE or NO_EXPORT is dependent on the operational practice. 

OK. We'll do this.

>Why is the "(see section 6.1.3 [RFC7454])" not appropiate?

This is a nit - you can ignore it.  IMO - it causes the reader to ask lots of questions. 
However, if this text was agreed upon in debate - keep it. 

>It is not an update to RFC5635? I am not sure how to address this comment, clearly the two documents are different.

Easily.  Simply state it is not an update to RFC5635.  State how the documents are different. 

Best wishes, 
Sue

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 2 Aug 2016 21:53:16 +0000

On 8/2/16, 1:40 PM, "rtg-dir on behalf of Job Snijders"
<[email-masked] on behalf of [email-masked]> wrote:

Job:

Hi!

>depend on RFC6483, nor do I want to venture into the problem space "how

Not really.  The right reference is rfc6811 (Origin Validation), not
rfc6483.

Putting some non-normative text around Origin Validation closes the idea
already put forward in 3.3:

Section 3.3. (Accepting Blackholed IP Prefixes) says that "BGP speakers
SHOULD only accept and honor BGP announcementsŠfor which the neighboring
network is authorized to advertise."   That sounds like Origin Validation
to me.  Given that Section 3.2. (Local Scope of Blackholes) is not strict
(uses "SHOULD" and not "MUST" when talking about propagation of marked
routes outside the receiving AS), I would like to see a sentence or two
(in the Security Considerations section) about how Origin Validation can
help determine if the neighbor is in fact authorized.

Note that I'm not suggesting that anyone needs to implement rfc6811, or
even sign ROAs, for the BLACKHOLE community to work.  Which is why I said
non-normative text above...

Thanks!

Alvaro.

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 3 Aug 2016 09:56:27 -0400

Alvaro: 

As you are the AD for SIDR, I'm sure your answer is right  - but  RFC6481?? 
 
RFC6481 - A Profile for Resource Certificate Repository Structure
RFC6482 - A Profile for Route Origin Authorizations (ROAs)
RFC6483 - Validation of Route Origination Using the Resource Certificate
Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs)

As to the final comments - yes, I would like to see:

1)  the details regarding how ROA can help the authorization, and 
2)  the details on why the ROA cannot be used as requirement due to lack of
ROA deployment. 

Sue 

-----Original Message-----
From: Alvaro Retana (aretana) [mailto:[email-masked]] 
Sent: Tuesday, August 2, 2016 5:53 PM
To: Job Snijders; Susan Hares; [email-masked]; [email-masked];
[email-masked]
Cc: Benoit Claise (bclaise); [email-masked]; [email-masked];
[email-masked]
Subject: Re: [RTG-DIR] draft-ietf-grow-blackholing-02.txt - Directorate
review

Job:

Hi!

>>
>>Minor
>>. The document does not indicate whether combining ROA (RFC6483) plus 

Section 3.3. (Accepting Blackholed IP Prefixes) says that "BGP speakers
SHOULD only accept and honor BGP announcementsŠfor which the neighboring
network is authorized to advertise."   That sounds like Origin Validation
to me.  Given that Section 3.2. (Local Scope of Blackholes) is not strict
(uses "SHOULD" and not "MUST" when talking about propagation of marked
routes outside the receiving AS), I would like to see a sentence or two (in
the Security Considerations section) about how Origin Validation can help
determine if the neighbor is in fact authorized.

Note that I'm not suggesting that anyone needs to implement rfc6811, or even
sign ROAs, for the BLACKHOLE community to work.  Which is why I said
non-normative text above...

Thanks!

Alvaro.

---

From: Job Snijders <[email-masked]>
Date: Wed, 3 Aug 2016 16:13:22 +0200

On Wed, Aug 03, 2016 at 09:56:27AM -0400, Susan Hares wrote:
> 2)  the details on why the ROA cannot be used as requirement due to lack of ROA deployment. 

I'm sorry but I consider commenting on the usefulness of ROAs a
controversial item that is outside the scope of documenting a well-known
BGP community.

Kind regards,

Job

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Wed, 3 Aug 2016 16:54:48 +0000

On 8/3/16, 9:56 AM, "Susan Hares" <[email-masked]> wrote:

Sue:

Hi!

>As you are the AD for SIDR, I'm sure your answer is right  - but

RFC6481??   I mentioned rfc6811 (BGP Prefix Origin Validation) below.

>2)  the details on why the ROA cannot be used as requirement due to lack

I pointed at rfc6811 because it provides a framework for origin validation
while saying that "Although RPKI provides the context for this document,
it is equally possible to use any other database that is able to map
prefixes to their authorized origin ASes."  Which should then be generic
enough to satisfy the advertisement authorization already mentioned in the
document.

To be clear, what I'm suggesting below is something like the following (in
the Security Considerations section):

   Section 3.3 recommends that BGP announcements carrying the
   BLACKHOLE community be accepted and honored only if the neighboring
   network is authorized to advertise the prefix.  rfc6811 describes
   a simple mechanism for BGP to validate authorization of an
advertisement.

That's it.  Nothing normative, nothing specific about signing ROAs, etc..
Just a statement about an existing mechanism that can be used...

Thanks!

Alvaro.

>(in
>even

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 4 Aug 2016 15:38:36 -0400

Alvaro: 

You, Alia, and Deborah are the boss!  I would have put in details on "why
not ROA".  I thought Job's comments that ROAs were not deployed was useful
-- but you are the boss. 

Sue 

-----Original Message-----
From: rtg-dir [mailto:[email-masked]] On Behalf Of Alvaro Retana
(aretana)
Sent: Wednesday, August 3, 2016 12:55 PM
To: Susan Hares; 'Job Snijders'; [email-masked]; [email-masked];
[email-masked]
Cc: Benoit Claise (bclaise); [email-masked]; [email-masked];
[email-masked]
Subject: Re: [RTG-DIR] draft-ietf-grow-blackholing-02.txt - Directorate
review

Sue:

Hi!

>RFC6483 - Validation of Route Origination Using the Resource 
>Certificate Public Key Infrastructure (PKI) and Route Origin 
>Authorizations (ROAs)
>

I pointed at rfc6811 because it provides a framework for origin validation
while saying that "Although RPKI provides the context for this document, it
is equally possible to use any other database that is able to map prefixes
to their authorized origin ASes."  Which should then be generic enough to
satisfy the advertisement authorization already mentioned in the document.

   Section 3.3 recommends that BGP announcements carrying the
   BLACKHOLE community be accepted and honored only if the neighboring
   network is authorized to advertise the prefix.  rfc6811 describes
   a simple mechanism for BGP to validate authorization of an advertisement.

Thanks!

Alvaro.

>>>this BGP community would resolve the concerns that the community 
>>>comes from the authorized origin of the prefix that will be blackholed.
>>>Sections 3.3 and 6 should be altered to provide the additional 
>>>details on this point.
>>
>>concerns. I consider it out of scope how to validate authorized 
>>origins of a prefix for the definition of this codepoint.
>>
>>depend on RFC6483, nor do I want to venture into the problem space 
>>"how to validate origins".
>>
>>Do you agree?
>
>Putting some non-normative text around Origin Validation closes the 
>idea already put forward in 3.3:
>
>to me.  Given that Section 3.2. (Local Scope of Blackholes) is not 
>strict (uses "SHOULD" and not "MUST" when talking about propagation of 
>marked routes outside the receiving AS), I would like to see a sentence 
>or two (in the Security Considerations section) about how Origin 
>Validation can help determine if the neighbor is in fact authorized.
>
>
>even sign ROAs, for the BLACKHOLE community to work.  Which is why I 
>said non-normative text above...
>
>Thanks!
>
>Alvaro.
>
>

---

From: joel jaeggli <[email-masked]>
Date: Thu, 11 Aug 2016 00:14:59 -0700

> controversial item that is outside the scope of documenting a well-known
I struggle with the question of how we as a comunity organize around 
the use of origin validation, but this is probably not the place we do that.

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 11 Aug 2016 09:45:34 -0400

Joel:
	
You are correct, It is not the only place we do origin validation.
However, the operational review was to consider what happens operationally
when this was deployed.  The other things BGP features that involve dropping
a route in DDoS attack can be the use of ROA (origin validation).  My
initial question/request was to document: a) why Grow chose this option, and
b) how ROA and blackholing interact. 

Job stated they did not use ROA because ROA was not as widely deployed as
communities.  I thought that piece of design lore should be capture in a
operational note.   Also, the ordering of Communities and ROA SHOULD not
matter in the vendor code.  By stating this, the test cases for BGP can add
this. I was hoping the operational/BGP section would state this.  

 Sue 

-----Original Message-----
From: rtg-dir [mailto:[email-masked]] On Behalf Of joel jaeggli
Sent: Thursday, August 11, 2016 3:15 AM
To: Job Snijders; Susan Hares
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; 'Benoit Claise (bclaise)'; 'Alvaro Retana (aretana)';
[email-masked]
Subject: Re: [RTG-DIR] draft-ietf-grow-blackholing-02.txt - Directorate
review

On 8/3/16 7:13 AM, Job Snijders wrote:
> controversial item that is outside the scope of documenting a 
> well-known BGP community.
I struggle with the question of how we as a comunity organize around the use
of origin validation, but this is probably not the place we do that.

---

From: Job Snijders <[email-masked]>
Date: Fri, 12 Aug 2016 14:22:04 +0200

Hi Team,

I wanted to run this change proposal by you:

In section 6:

OLD:
    "Also, RPKI [RFC6810] and BGPSec [I-D.ietf-sidr-bgpsec-protocol] do
    not fully resolve this situation.  For instance, BGP communities can
    still be added or altered by a forwarding agent even if RPKI and
    BGPSec are in place."

NEW:
    "BGPSec [I-D.ietf-sidr-bgpsec-protocol] does not resolve this
    situation.  Even when BGPSec is in place, a forwarding agent can
    alter, add or remove BGP communities."

I think its better to remove the RFC6810 reference in that location, as
RPKI never had as design goal to protect attributes. Leaving RPKI in
that contex there would be like saying "SNMP does not fully resolve this
situation" - just like RPKI, SNMP is entirely unrelated in the context.

I'd appreciate your feedback on this modification.

Kind regards,

Job

---

From: Gert Doering <[email-masked]>
Date: Fri, 12 Aug 2016 14:24:10 +0200

Hi,

> I'd appreciate your feedback on this modification.

Makes sense.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Christoph Dietzel <[email-masked]>
Date: Fri, 12 Aug 2016 12:30:01 +0000

Hi all,

> that contex there would be like saying "SNMP does not fully resolve this

I agree. The assumption is "Even when BGPSec ..." which implies that
RPKI is deployed to a certain degree anyway.

Thanks, Chris