Subject: Re: [OPSEC] Start of WGLC for draft-ietf-opsec-bgp-security

From: Kotikalapudi Sriram <[email-masked]>
Date: Thu, 22 Aug 2013 14:26:17 +0530

I have read the document (draft-ietf-opsec-bgp-security-01) and I’m in
support of publication this document as a BCP. Some comments/suggestions
below.  I have not had chance to go through all the comments you have
received so far on this list. Hence, sorry if some of mine seem like a
repeat of comments from others.

At NIST, we had put together BGP security recommendations document several
years ago. You may consider referencing it:

R. Kuhn, K. Sriram, and D. Mongomery, “Border Gateway Protocol Security,”
NIST  Special Publication 800-54.
http://csrc.nist.gov/publications/nistpubs/800-54/SP800-54.pdf

Some nits/comments follow:

Consider defining inbound/outbound upfront.

p.3, sec 1, para 1: ACL is access control list

p.3, sec 1, para 1: this quoted phrase needs further clarity and can be
rephrased / explained:  “…. to avoid filtering transit traffic if not
needed”

section 5.1.1.1 title change: IPv4 special purpose prefixes

section 5.1.1.2 title change: IPv6 special purpose prefixes

section 5.1.2: replace “…described in this section if it is not capable
of…” with “…described in this section if they are not capable of…”

sec 5.1.2.1, para 1: replace “…keep checking prefixes in the IANA allocated
address space …” with “…keep checking prefixes in the IANA allocated IPv4
address space …”

sec 5.1.2.1, para 1: replace “…IPv4 prefixes they receive have been
allocated…”  with  “…IPv4 prefixes they receive in BGP updates have been
allocated……”

sec 5.1.2.2, para 1: replace “…To overcome this risk…”  with  “…To
partially mitigate this risk……”

sec 5.1.2.3, para 3: replace “…a script can build for…”  with  “…a script
can be built for……”

sec 5.1.2.3, para 4: comment about “…only use information from sources
representing the five current RIRs…”  Question: Why not include the
mirrored IRR data of major ISPs as well? I understand such data are readily
available in the RADB.

sec 5.1.2.3, para 5: replace “…may quickly vary over time…”  with  “…may
frequently vary over time ……”

sec 5.1.2.3, para 5: replace “…could even been considered…”  with  “…could
even be considered ……”

sec 5.1.2.4, last para: The validation procedure described is inaccurate
and incomplete. So (per Randy’s suggestion as well) you may simply refer to
RFC 6811 here. It may also be worth including RFC 6907 (the SIDR RPKI use
cases document) as a reference here.

Sec 5.1.4: It would be helpful if a definition of “local AS” is provided
here.

Sec 5.1.5.2: Acronyms pMTUd and uRPF should be spelt out.

Sec 5.2.3.1, para 1: replace “is the same than the one for” with “is the
same as the one for”

Section 8, last bullet: Is there a practical example when an exception
(accepting your own AS number in AS-path) is required?

Thanks much.

Sriram

---

From: "Jerome Durand (jerduran)" <[email-masked]>
Date: Thu, 22 Aug 2013 10:23:06 +0000

Hi!

> I have read the document (draft-ietf-opsec-bgp-security-01) and I’m in support of publication this document as a BCP. Some comments/suggestions below.  I have not had chance to go through all the comments you have received so far on this list. Hence, sorry if some of mine seem like a repeat of comments from others.  

No problem! I haven't been able to answer to all the great coments we've received so far. Thanks for your support that's appreciated!

> At NIST, we had put together BGP security recommendations document several years ago. You may consider referencing it:
> 
> R. Kuhn, K. Sriram, and D. Mongomery, “Border Gateway Protocol Security,” NIST  Special Publication 800-54. http://csrc.nist.gov/publications/nistpubs/800-54/SP800-54.pdf

I wasn't aware of it sorry. I believe this is highlighting that having an IETF BCP would be useful as no network operator can be aware of all the great material avalaible everywhere.

> p.3, sec 1, para 1: ACL is access control list

OK

> p.3, sec 1, para 1: this quoted phrase needs further clarity and can be rephrased / explained:  “…. to avoid filtering transit traffic if not needed”

Clarified

> section 5.1.1.1 title change: IPv4 special purpose prefixes

OK

> section 5.1.1.2 title change: IPv6 special purpose prefixes

OK

> section 5.1.2: replace “…described in this section if it is not capable of…” with “…described in this section if they are not capable of…” 

OK

> sec 5.1.2.1, para 1: replace “…keep checking prefixes in the IANA allocated address space …” with “…keep checking prefixes in the IANA allocated IPv4 address space …”

OK

> sec 5.1.2.1, para 1: replace “…IPv4 prefixes they receive have been allocated…”  with  “…IPv4 prefixes they receive in BGP updates have been allocated……”

OK

> sec 5.1.2.2, para 1: replace “…To overcome this risk…”  with  “…To partially mitigate this risk……”

OK

> sec 5.1.2.3, para 3: replace “…a script can build for…”  with  “…a script can be built for……”

I don't think so. Full sentence is below so we are talking about the fact that the script builds something:
"With these two mechanisms a script can build for a given peer the list of allowed prefixes and the AS number from which they should be originated"

> sec 5.1.2.3, para 4: comment about “…only use information from sources representing the five current RIRs…”  Question: Why not include the mirrored IRR data of major ISPs as well? I understand such data are readily available in the RADB.

OK, changed to:

One could check a popular IRR containing many sources (such as RADB, the Routing Assets Database) and only select as sources some desired RIRs and trusted major ISPs

> sec 5.1.2.3, para 5: replace “…may quickly vary over time…”  with  “…may frequently vary over time ……”

OK

> sec 5.1.2.3, para 5: replace “…could even been considered…”  with  “…could even be considered ……”

OK

> sec 5.1.2.4, last para: The validation procedure described is inaccurate and incomplete. So (per Randy’s suggestion as well) you may simply refer to RFC 6811 here. It may also be worth including RFC 6907 (the SIDR RPKI use cases document) as a reference here.

Yes we'll work further on the section globally.

> Sec 5.1.4: It would be helpful if a definition of “local AS” is provided here.

OK. Same here we should clarify few things here.

> Sec 5.1.5.2: Acronyms pMTUd and uRPF should be spelt out.

OK, will appear in accronym&definition section of -02 

> Sec 5.2.3.1, para 1: replace “is the same than the one for” with “is the same as the one for”  

OK

> Section 8, last bullet: Is there a practical example when an exception (accepting your own AS number in AS-path) is required?   

Well I've personnaly seen that when customers have a single AS for several sites and are interconnected through various ISPs. We are usually using other mecahnisms like as-override but I'd assume some would prefer to change default BGP bahaviour and agree on the risks. I am not sure we wanted to put an example in the document.

Again, thanks a lot for your participation!

Jerome

---

From: Barry Greene <[email-masked]>
Date: Thu, 22 Aug 2013 20:16:04 +0700

> I wasn't aware of it sorry. I believe this is highlighting that having an IETF BCP would be useful as no network operator can be aware of all the great material avalaible everywhere.

For completeness sake, include the workshop seminar references from NANOG, RIPE, and APRICOT as well as the recommendations in a couple of books.