Hi, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the operational area directors.  Document editors and WG chairs should treat these comments just like any other last call comments. This document is a BCP for network administrators. It summarizes common practices for BGP session protection and routing information flow control. I think that the quality of the documents is good. Its content will be useful for network administrators and is somehow ready for publication. I not already addressed, authors may however take into account the following late comments before final publication. Regards, Lionel *************** - Idnits highlight some errors that can be easily fixed. - All along the document: s/internet/Internet. s/you or one/network administrators (when applicable) Please expand acronym when used for the first time. *Section 2 The rules defined in this document are intended for generic Internet BGP peerings. Nature of the Internet is such that Autonomous Systems can always agree on exceptions for relevant local needs, and therefore configure rules which may differ from the recommendations provided in this document. If this is perfectly acceptable, one should note that every configured exception has an impact on the complete BGP security policy and requires special attention before implementation. If I'm correct, the first recommendation here is that networks admins "SHOULD" follow these rules. Exceptions are possible but if there is, the full impact on BGP security model must be carefully appraised. *Section 4: In addition to strict filtering, rate-limiting MAY be configured for accepted BGP traffic. This protects the BGP router control plane in case the amount of BGP traffic overcomes platform capabilities. No normative wording is used in section 5, except this "MAY". Is it really meant to use a "MAY"? If yes, why there is no normative recommendation regarding the use of ACL (e.g. "SHOULD")? *Section 5: Current issues of TCP-based protocols (therefore including BGP) have been documented in [26]. The following sub-sections recall the major points raised in this RFC and gives best practices for BGP operation. s/gives/give * Section 5.1: While MD5 is still the most used mechanism due to its availability in vendor's equipment, TCP-AO be preferred when implemented. s/TCP-AO be preferred when implemented/TCP-AO SHOULD be preferred when implemented. The drawback of TCP session protection is additional configuration and management overhead for authentication information (ex: MD5 password) maintenance. Protection of TCP sessions used by BGP is thus RECOMMENDED when peerings are established over shared networks where spoofing can be done (like IXPs). I'm not expert on security but I don't think that configuration/management overhead is a valid excuse for no TCP session protection. I think the main recommendation remains that TCP session protection is RECOMMENDED and it is more true when IP spoofing can not be prevented (e.g. in shared-network). You SHOULD block spoofed packets (packets with a source IP address belonging to your IP address space) at all edges of your network [13] [14], making the protection of TCP sessions used by BGP unnecessary on iBGP or eBGP sessions run over point-to-point links. regarding eBGP, this is true only if all the ASs apply the same rule, and this is what you can't ensure and why there is the recommendation to use TCP session protection over IXPs for instance. Except if I've missed something... Note: Like MD5 protection, TTL security has to be configured on both ends of a BGP session. I'm not sure that the NOTE is relevant. I think that any security mechanism will have to be supported by both ends to be used. Or something is hidden behide this note. *Section 6.1.1.2: At the time of the writing of this document, the list of IPv6 prefixes that MUST NOT cross network boundaries can be simplified as IANA allocates at the time being prefixes to RIR's only in 2000::/3 Expand RIR (first appearance) *Section 6.1.2: IANA allocates prefixes to RIRs which in turn allocate prefixes to LIRs. It is wise not to accept in the routing table prefixes that Expand LIR (first appearance) Therefore automation of such prefix filters is key for the success of this approach. One SHOULD probably NOT consider solutions described in this section if they are not capable of maintaining updated prefix filters: the damage would probably be worse than the intended security policy. please consider removing the "probably" and replace "one" by "Network administrators" in the second sentence. *Section 6.1.2.1: Based on past experience, authors recommend that the process in place makes sure there is no more than one month between the time the IANA IPv6 allocated prefix list changes and the moment all IPv6 prefix filters are updated. If it is a strong recommendation, you may consider use a "SHOULD" or "RECOMMENDED" in the RFC2119 format. If process in place (manual or automatic) cannot guarantee that the list is updated regularly then it's better not to configure any filters based on allocated networks. The IPv4 experience has shown that many network operators implemented filters for prefixes not allocated by IANA but did not update them on a regular basis. This created problems for latest allocations and required a extra work for RIRs that had to "de-bogonize" the newly allocated prefixes. This is already indicated in the end of the introduction in the section 6.1.2. Maybe you can keep part of the additional details and move it in the section 6.1.2 that will then apply to all the sub-sections. *Section 6.1.2.2: At this stage 2 options can be considered (short and long term options). They are described in the following subsections. therefore, section 6.1.2.3 and section 6.1.2.4 should be renumbered as section 6.1.2.2.1 and section 6.1.2.2.2 *Section 9: o You SHOULD accept from customers only AS(4)-Paths containing ASNs belonging to (or authorized to transit through) the customer. For consistency, would it be better to say: o You SHOULD NOT accept from customers AS(4)-Paths containing ASNs *not* belonging to (or *not* authorized to transit through) the customer. You can also try to reorganize the section around what the network admins SHOULD NOT accept in one part and what they SHOULD NOT advertise. Except if the logic is somewhere else and I didn't get it. _________________________________________________________________________________________________________________________ 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.