Re: [Idr] AD Review of draft-ietf-idr-ix-bgp-route-server-09

["Alvaro Retana (aretana)" <[e-mail]>]

On 12/11/15, 3:15 PM, "Idr on behalf of Alvaro Retana (aretana)" <[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> wrote:

Hi!

It's been almost two months since I sent this review, but have received no answer. :-(

Alvaro.

Hi!

I just finished reading this document.  Please find my comments below.

As you can see, the comments I labeled as Major are mostly related to security considerations, where I think there's more to add, and clarity with respect to the behavior in RFC4271.  I don't think that any of the comment will be hard to address.

I will wait for your comments/discussion and/or an update before starting the IETF Last Call.

Thanks!

Alvaro.


Major:

  1.  Should this document be marked as updating rfc4271?  There are several places in Section 2 where the behavior is different than what is specified in rfc4271.  Given that the route server functionality is an optional enhancement, I don't think this document should be marked as updating rfc4271 (I.e. It changes the behavior only for the functionality specified here).  I'm assuming the authors/WG agree since there is no indication of an update.  Please include a clear statement (maybe in the Introduction) to the fact that the mechanism is optional.
  2.  Section 2.1. (Client UPDATE Messages). "The route server SHOULD forward UPDATE messages where appropriate…to its clients."  When is it appropriate?  I'm guessing that you mean something like "where local policy permits"..  Please be clear.
  3.  Section 2.2.2. (AS_PATH Attribute)  Not prepending the route server's AS_PATH brings up a couple of issues/questions:
     *   RFC4271 talks about prepending the local ASN (when advertising to an EBGP peer), and it doesn't mention any exceptions.  This document includes an exception.  Clearly indicate the modifications to Section 5.1.2. (AS_PATH) of RFC4271.
     *   Section 6.3. (UPDATE Message Error Handling) of rfc4271 says that when an "…UPDATE message is received from an external peer, the local system MAY check whether the leftmost…AS in the AS_PATH attribute is equal to the autonomous system number of the peer that sent the message", and MUST send a NOTIFICATION if it doesn't.
        *   Please be explicit about the required behavior for both the route server, and the clients.
        *   Even though this check is optional in RFC4271, mandating that is not be done could be interpreted as a security issue.  Please include some text around it (and mitigation) in the Security Considerations section.
     *   Independent of the check, not including an ASN in the AS_PATH could (in the general case) result in loops; which I also interpret as a potential security issue.  Please include some text about this too — a mitigation option is clearly to not check the first ASN only when known route servers are peers.
  4.  Section 2.2.4. (Communities Attributes) says that Communities "SHOULD NOT be modified, processed or removed.  However, if such an attribute is intended for processing by the route server itself, it MAY be modified or removed."  How does the route server know if the sender intended for a community to be processed by it, or not?  Please add details.
  5.  Section 3. (Security Considerations)
     *   Besides the points above, because clients rely on the route server to implement outbound route filtering for them, there can be a privacy issue/route leak scenario where the route server can send routes to clients that it shouldn't have.  Not much can be done to mitigate this because it will mostly be due to a bad implementation or simply a "bad operator".
     *   You should point at relevant sections of RFC7454.
  6.

Minor:

  1.  Please be consistent:
     *   s/exterior BGP/external BGP..or even just EBGP (yes, a nit..but that's how rfc4271 calls EBGP)
     *   s/best path selection process/Decision Process
     *   s/IX/IXP
  2.  Section 2.2.3. (MULTI_EXIT_DISC Attribute) specifically calls out the MED, but you already said in Section 2.2. (Attribute Transparency) that all optional attributes "SHOULD NOT be updated by the route server…and SHOULD be passed on to other route server clients."  Is there anything special about the MED that I'm missing?  If not, then you should be able to delete the section.
  3.  In Section 2.3.1. (Path Hiding on a Route Server) policy implementation is described in terms of outbound route filtering.  The description of the example says that if "AS1's policy prevents AS2's path from being accepted, then AS1 would never receive a path to this prefix".  To be consistent with the outbound filtering description, you might want to change that text to something like "AS2's policy prevents AS1 from receiving the path, …".
  4.  Section 2.3.2.2. (Advertising Multiple Paths) says that if the route server sends "more than a single path to a route server client,…the path hiding problem described in Section 2.3.1 would disappear."  That statement is true, but only if all the paths are propagated, not just "more than a single" one. [You do talk about that in 2.3.2.2.1, but not the general case.]
  5.  Section 2.3.2.2.2. (BGP ADD-PATH Approach)
     *   This section says that if "the route server client propagates multiple paths for the same prefix to the route server, then this could potentially cause the propagation of inactive, invalid or suboptimal paths to the route server, thereby causing loss of reachability to other route server clients."  I can see how suboptimal (= non best) paths can be propagated by the clients, but what about invalid?
     *   To be consistent, there's no such thing as send-only and receive-only modes negotiated with ADD-PATH.  For the result in the text (having only the route server send), the route server should advertise the Send/Receive field in the ADD_PATH capability set to 2 (only able to send).  It doesn't matter what the client sets the value to (as long as it is not 2).
  6.  References:  I think the following can be made Informational: RFC1997, RFC4360

Nits:

  1.  Given that Section 2.3 is "included for information purposes only", you might want to consider making it an Appendix.
  2.  Section 2.3.3. (Implementation Suggestions) seems superfluous to me.