Re: [OPSEC] Comments on draft-jdurand-bgp-security

["Jerome Durand (jerduran)" <[e-mail]>]

Thank you Ron for this great feedback.
Comments in-line:

Thanks for writing draft-jdurand-bgp-security. On the whole, it is a very well written document. The following are a few comments:

Section 2.5
============
Somewhere between Section 2 and Section 3, you should mention that the BGP process needs to be protected from stray packets. Protection can be achieved by applying a forwarding plane ACL. The ACL accepts all packets that meet the following criteria:

- directed to TCP port 179 on the local device
- sourced from a known BGP neighbor

It discards all packets directed to TCP port 179 on the local device and sourced from an address not known to be a BGP neighbor.

Yes. Will be added in next version.

Section 3.1
============
In Section 3.1, you talk about MD5 Password Protection. This make the reader think that you are talking about RFC 2385. However, the reference is to RFC 5925 (TCP-AO). Please be clear about which you are recommending.

In this regard, we have a dilemma. The IETF has obsoleted RFC 2385 and replaced it with RFC 5925. However, to the best of my knowledge, there are no commercially available implementations.

Already integrated but not published yet :-)

Section 4.1.1.1
===============
Rather than listing every IPv4 special-use address, you might want to simply refer the reader to RFC 5735 and 5736.
Section 4.1.1.2
================
Rather than listing every IPv6 special-use address, you might want to refer the reader to http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xml. It might be better to refer the reader to the registry, because it will be kept up to date in the future.

Yes we have progress to make for these 2 points. From your comments and the ones from Marc Blanchet we'll propose new text here.

Section 4.1.3
=============
It is true that most ISPs will not accept advertisements beyond a certain level of specificity. However, this is an issue to be worked out between the operators, and not an issue for standardization.

Indeed. Of course we don't intend to standardize anything or to mandate any operator to do what is said in the document. We just want to describe what are the BCP's so we have somehow to say that it's BCP to think about a limit (quickly recalling reasons for that), that each domain is free to decide its limit (that can change accross peerings for sure) , and that some communities have documented what limit is usually adopted.

Thanks again.

Jerome








--------------------------
Ron Bonica
vcard:       www.bonica.org/ron/ronbonica.vcf<http://www.bonica.org/ron/ronbonica.vcf>

_______________________________________________
OPSEC mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/opsec

[cid:[e-mail]]

Jérôme Durand
Consulting Systems Engineer
Routing & Switching

[e-mail]<mailto:[e-mail]>
Mobile :[phone]

http://reseauxblog.cisco.fr

http://ipv6blog.cisco.fr


Cisco France
11, rue Camille Desmoulins
92782 Issy les Moulineaux
Cedex 9
France
www.cisco.fr<http://www.cisco.fr>



[cid:[e-mail]]
 Think before you print.
This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message.
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html