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

From: "George, Wes" <[email-masked]>
Date: Wed, 9 Apr 2014 17:05:27 -0400

I’ve reviewed previous versions of this draft, but made a new pass through it.
I think it’s mostly ready to publish, though soliciting reviews from non-IETF operator lists might be a good thing to do before we go to IETF LC.

The abstract needs to remove the reference to MD5 since it is deprecated. Similarly, section 4.1 needs to explicitly note that MD5 has been deprecated by AO, not simply recommend that AO be used when available. I’ll concede that MD5 is better than nothing, but it’s not something we want to recommend in a new BCP without being clear why it shouldn’t be used anymore.

There are places where words like “recommended" are used in ways that look to be 2119 usage, but are not capitalized. This needs to be consistent throughout the document, so that they are used whenever a recommendation is being made as something that you SHOULD/MUST do in order to be in compliance with this Best Common Practice.

Section 3- may want to mention rate-limiting accepted traffic in addition to strict filtering of unacceptable traffic

4.1 – reference to BCP38 in the “block spoofed packets” section at the end?

5.1.2.3 – reference to IRRtoolset?

5.2.1 (or possibly section 8) - Filtering peer ASes inbound from customers? (in this case “peer” meaning a non-transit interconnect, not just someone you are connected to via BGP) I.e. If I know that I should only receive routes with 701 in the path from 701 because I do not use any other ASN as transit to reach 701, I should filter routes inbound from other sources to ensure that they don’t announce routes with that path. This is somewhere between the strict IRR based filters and the loose filters, and depends on the topology of the network and my business relationships, but I think it’s a useful point to make to add some additional safety filtering to prevent “my idiot customer is trying to re-announce the internet to me” along with max-prefix, which you already cover.

Section 11’s future work either needs to be completed in this document or explicitly identified as work for a future document. The WG needs to discuss what is appropriate to add to this doc vs leave for future work before this proceeds.

Section 12 needs explicit notes to the RFC editor to remove the section prior to publication.

This may be something that the RFC editor will fix, but it would be preferable to use the actual draft name or RFC number as the reference tag instead of numeric tags, so that the reader knows what you are referencing without having to jump to footnotes each time.

Thanks,

Wes George

From: "Gunter Van de Velde (gvandeve)" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, April 8, 2014 at 5:18 AM
To: opsec wg mailing list <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [OPSEC] Start of 2nd WGLC for draft-ietf-opsec-bgp-security

Dear OpSec WG,

This starts a 2nd Working Group Last Call for draft-ietf-opsec-bgp-security.

Due to the time taken to integrate all comments from the first WGLC this 2nd WGLC is initiated.

All three authors have replied, stating that they do not know of any IPR associated with this draft.

The draft is available here: https://datatracker.ietf.org/doc/draft-ietf-opsec-bgp-security/<https://datatracker.ietf.org/doc/draft-ietf-opsec-lla-only/>

Please review this draft to see if you think it is ready for publication and comments to the list, clearly stating your view.

This WGLC ends 22-April-2014.

Thanks,

G/

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: "Jerome Durand (jerduran)" <[email-masked]>
Date: Thu, 10 Apr 2014 07:20:47 +0000

Hi George,

> I’ve reviewed previous versions of this draft, but made a new pass through it.

First thanks a lot for your help on this doc!

> I think it’s mostly ready to publish, though soliciting reviews from non-IETF operator lists might be a good thing to do before we go to IETF LC.

Doc has already been presented RIPE and NANOG meeting as you know. Should we simply send an email recalling this is last call?

> The abstract needs to remove the reference to MD5 since it is deprecated. Similarly, section 4.1 needs to explicitly note that MD5 has been deprecated by AO, not simply recommend that AO be used wh…

I'll remove MD5 from the abstract.
For section 4.1 I propose the following text for 2nd paragraph you're referring to:

   TCP sessions used by BGP can be secured with a variety of mechanisms.
   MD5 protection of TCP session header [14] was the first existing mechanism.
   It is now deprececated by TCP Authentication Option (TCP-AO, [10]) which
   offers stronger protection. IPsec can also be used for this purpose.
   While MD5 is still the most used mechanism due to its availability in
   vendor's equipment, TCP-AO and MD5 SHOULD be preferred when implemented.

Feel free to change the text.

> There are places where words like “recommended" are used in ways that look to be 2119 usage, but are not capitalized. This needs to be consistent throughout the document, so that they are used when…

OK.

> Section 3- may want to mention rate-limiting accepted traffic in addition to strict filtering of unacceptable traffic

Maybe a note on that. We probably don't want to start discussing the right thresholds here.

> 4.1 – reference to BCP38 in the “block spoofed packets” section at the end?

Good point. I remember there was BCP38 at some stage but we removed it and forgot to add it again when we added this small paragraph in 4.1

> 5.1.2.3 – reference to IRRtoolset?

OK for a reference.

> 5.2.1 (or possibly section 8) - Filtering peer ASes inbound from customers? (in this case “peer” meaning a non-transit interconnect, not just someone you are connected to via BGP) I.e. If I know th…

I think that first bullet of section 8 is saying this. We are saying we need to make sure we receive only identified ASes from customer, we probably don't need to add we have to filter the ones we don't want. Tell me if I didn't understand your point. Feel free to propose some modified text.

> Section 11’s future work either needs to be completed in this document or explicitly identified as work for a future document. The WG needs to discuss what is appropriate to add to this doc vs leav…

Indeed. Idea is indeed to remove this section: I forgot it was here.
Comments were integrated except the one about IRRTOOLSET. Adding a reference is enough I think, probably don't need to give examples in appendix.

> Section 12 needs explicit notes to the RFC editor to remove the section prior to publication. 

Sure, I think I'll even remove this section in next version.

> This may be something that the RFC editor will fix, but it would be preferable to use the actual draft name or RFC number as the reference tag instead of numeric tags, so that the reader knows what…

If RFC editor can fix it I buy the idea. Otherwise you need to explain to me how to do it easily :)

Thanks again for your comments. They will be integrated really soon. Please let me know about the text I proposed in 4.1.

Jerome

> 
> 
> Thanks,
>  
> Wes George
>  
> 
> From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
> To: opsec wg mailing list <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> The draft is available here: https://datatracker.ietf.org/doc/draft-ietf-opsec-bgp-security/
>  
> _______________________________________________
> OPSEC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsec

--
Jerome Durand
Consulting Systems Engineer - Routing & Switching
[email-masked]  -  +33 6 35 11 60 50
blogs: http://reseauxblog.cisco.fr - http://ipv6blog.cisco.fr
twitter: @JeromeDurand
linkedin: http://fr.linkedin.com/in/jeromedurand

CISCO France
11, rue Camille Desmoulins
92782 Issy les Moulineaux
CEDEX 9
FRANCE

---

From: "George, Wes" <[email-masked]>
Date: Thu, 10 Apr 2014 13:30:00 -0400

On 4/10/14, 3:20 AM, "Jerome Durand (jerduran)" <[email-masked]> wrote:

>Doc has already been presented RIPE and NANOG meeting as you know. Should
>we simply send an email recalling this is last call?

Couldn’t hurt.

>   vendor's equipment, TCP-AO and MD5 SHOULD be preferred when

Looks fine, although I think you meant to say “TCP-AO SHOULD be preferred”
not “TCP-AO and MD5 SHOULD” in the last sentence.

>
>>Section 3- may want to mention rate-limiting accepted traffic in
>>addition to strict filtering of unacceptable traffic
>

Agree

>> 5.2.1 (or possibly section 8) - Filtering peer ASes inbound from
>>customers? (in this case “peer” meaning a non-transit interconnect, not
>>just someone you are connected to via BGP) I.e. If I know that I should
>>only receive routes with 701 in the path from 701 because I do not use
>>any other ASN as transit to reach 701, I should filter routes inbound
>>from other sources to ensure that they don’t announce routes with that
>>path. This is somewhere between the strict IRR based filters and the
>>loose filters, and depends on the topology of the network and my
>>business relationships, but I think it’s a useful point to make to add
>>some additional safety filtering to prevent “my idiot customer is trying
>>to re-announce the internet to me” along with max-prefix, which you
>>already cover.
>
>I think that first bullet of section 8 is saying this. We are saying we
>need to make sure we receive only identified ASes from customer, we
>probably don't need to add we have to filter the ones we don't want. Tell
>me if I didn't understand your point. Feel free to propose some modified
>text.

You’re right, it’s mostly saying that. I think the model you’re advocating
is a filter that explicitly permits certain ASNs, generated uniquely for
each customer, meaning each has an implicit deny of anything that isn’t
explicitly permitted. That’s certainly the better model. My suggestion was
more for the second case “if you cannot build filters…”, where building a
short list of explicitly denied ASNs that you should never see from *any*
downstream customer (i.e. The ASNs of your peers and/or upstream transit
providers) to a non-customer-specific filter that can be globally applied
on all customer BGP sessions provides a useful safety mechanism beyond
AS-path-length limits, and protects if the customer-specific filter is
inadvertently not applied (since that never happens :-) ).
Hope that’s clearer.

>
>> This may be something that the RFC editor will fix, but it would be
>>preferable to use the actual draft name or RFC number as the reference
>>tag instead of numeric tags, so that the reader knows what you are
>>referencing without having to jump to footnotes each time.
>

I just looked briefly at your XML compared with one of my drafts, and I
can’t see how it’s different, so I’m actually not sure how to fix, so I
guess let’s don’t worry about it.

Wes George

---

From: "Jerome Durand (jerduran)" <[email-masked]>
Date: Wed, 16 Apr 2014 23:14:12 +0000

> not “TCP-AO and MD5 SHOULD” in the last sentence.

Indeed!

> inadvertently not applied (since that never happens :-) ).

It is, thanks. I propose to slightly change the end of the first bullet then:

   o  You SHOULD accept from customers only AS(4)-Paths containing ASNs
      belonging to (or authorized to transit through) the customer.  If
      you can not build and generate filtering expressions to implement
      this, consider accepting only path lengths relevant to the type of
      customer you have (as in, if they are a leaf or have customers of
      their own), try to discourage excessive prepending in such paths.
      *This loose policy could be combined with filters for specific
      AS(4)-Paths that must not be accepted if advertised by the
      customer.*

Please tell me if that does the job. Feel free to propose an laternative text if not.

> guess let’s don’t worry about it.

Good!

Thanks agin for your suport!

Jerome

CISCO France

---

From: "George, Wes" <[email-masked]>
Date: Thu, 17 Apr 2014 10:45:41 -0400

>      AS(4)-Paths that must not be accepted if advertised by the

I suggest a slight addition- “This loose policy could be combined with
filters for specific AS(4)-Paths that must not be accepted if advertised
by the customer, such as upstream transit provider or peer ASNs.”

I think the examples make it clearer what we mean.

Wes

---

From: "Jerome Durand (jerduran)" <[email-masked]>
Date: Thu, 17 Apr 2014 20:03:06 +0000

> I think the examples make it clearer what we mean.

Perfect!

Jerome

CISCO France