Last Call Review of draft-ietf-opsec-bgp-security-05
review-ietf-opsec-bgp-security-05-opsdir-lc-morand-2014-10-02-00

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.