Subject: [secdir] Secdir review of draft-ietf-grow-ix-bgp-route-server-operations-03

From: Catherine Meadows <[email-masked]>
Date: Wed, 17 Sep 2014 16:09:01 -0400

I  have reviewed the current version of this document as part of the security
directorate's ongoing effort to review all IETF documents being processed by
the IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.

This draft discusses several issues of operational relevance to route server operators and provides recommendations
to help them provide a reliable interconnection services.  Reliability, not security, is the main focus of this
document, but several of the problems that are discussed also have implications for security, mainly because
if they are not properly addressed they can be used to implement various attacks, mostly in the
form of denial of service.  These are
summarized in the Security Considerations section, and it is pointed out in that section which 
countermeasures described in the document defend against these attacks.

My only criticism of the Security Considerations section is that the issues are not described in very
much detail.  It would be helpful to have references to other documents where more information is given.
Otherwise I find myself asking questions such as “What are the ‘certain circumstances’ under which the path
hiding problem can be exploited” and “How is it trivial for a route server to implement denial of service if prefix
leakage mitigation is not implemented?”

Also, a nit.  I found the summary of  path hiding in Section 4.1 a little misleading:

    "Path hiding" is a term used in [I-D.ietf-idr-ix-bgp-route-server] to
    describe the process whereby a route server may mask individual paths
    by applying conflicting routing policies to its Loc-RIB.

This gave me the impression that path hiding is something done deliberately, when actually it appears to
be an unintended side effect.  The reference draft.ietf-idr-ix-bgp-route-server makes the unintended nature
of path hiding more clear.  I think it would be better to have something like the following:

   "Path hiding" is a term used in [I-D.ietf-idr-ix-bgp-route-server] to
    describe the process whereby a route server may inadvertently mask individual paths
    by applying conflicting routing policies to its Loc-RIB.

Catherine Meadows
Naval Research Laboratory
Code 5543
4555 Overlook Ave., S.W.
Washington DC, 20375
phone: 202-767-3490
fax: 202-404-7942
email: [email-masked]

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 17 Sep 2014 22:59:24 +0100

Catherine,

thank you for taking the time to review this draft.

On 17/09/2014 21:09, Catherine Meadows wrote:
> My only criticism of the Security Considerations section is that the
> issues are not described in very much detail.  It would be helpful to
> have references to other documents where more information is given. 
> Otherwise I find myself asking questions such as “What are the ‘certain 
> circumstances’ under which the path hiding problem can be exploited”

The intention of this sentence was to notify route server operators that
there were security issues associated with path hiding, and a reference was
given to ietf-idr-ix-bgp-route-server where the problem was explained more
clearly.  As the two drafts share the same authors, we felt that it was
better not to have overlap between the two, as there is some virtue in brevity.

> and
> “How is it trivial for a route server to implement denial of service if
> prefix leakage mitigation is not implemented?”

We could change that sentence to:

"...it is trivial for route server clients to implement denial of service
attacks against arbitrary Internet networks by leaking prefixes to a route
server."

Leaking prefixes is trivia -- and disturbingly common.

> describe the process whereby a route server may mask individual paths by
> applying conflicting routing policies to its Loc-RIB.
> 
> This gave me the impression that path hiding is something done 
> deliberately, when actually it appears to be an unintended side effect.

Path hiding may or may not be intentional.  We deliberately left the
wording non-specific.

Nick