Subject: [secdir] Secdir review of draft-ietf-idr-ix-bgp-route-server-10

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Mon, 6 Jun 2016 00:33:04 +0000

I have reviewed 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.

Summary: ready with (potential) issues.

This standards track draft describes a method to exchange routing information between 3 or more BGP peers on shared network access media. The approach is intended to reduce the overhead involved in sharing routes in densely populated interconnection points through the use of a common route broker.

I found the draft clearly articulates the problem it is trying to solve.

The following is a minor nit on the organization of the text:

In general the security considerations section covers the issues fairly well. In the first paragraph, the last sentence suggests that steps should be taken to address path hiding, but the text does not point to the text in section 2.3.2 on this topic. One way to improve this consideration would be to move the text in 2.3.3 to the end of this paragraph. Section 2.3.3 is adjacent to the security consideration section, so I don't see this as a significant change.

Some (potentially) minor issues:

A number of the requirements in section 2.2 and the subsections define requirements that differ and often conflict with requirements in RFC 4271. It would be good to indicate this at the start of 2.2.  Should this relationship also be called out in the abstract?

I am not an expert in BGP security, so please consider this issue in that context:

The statement at the end of the security considerations section points the reader to RFC7454. I was left wondering if this draft changes any of considerations in RFC7454. It would be beneficial if some text was added to this draft speaking to this point. Again not being an expert in BGP security, I am not certain what the new text should say on this matter.

Regards,
Dave Waltermire

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 10 Jun 2016 23:35:57 +0100

Hi Dave,

thank you for your review.

Waltermire, David A. (Fed) wrote:
> In general the security considerations section covers the issues
> fairly well. In the first paragraph, the last sentence suggests that
> steps should be taken to address path hiding, but the text does not
> point to the text in section 2.3.2 on this topic. One way to improve
> this consideration would be to move the text in 2.3.3 to the end of
> this paragraph. Section 2.3.3 is adjacent to the security
> consideration section, so I don't see this as a significant change.

I see what you're saying here, but we wanted to have a specific
recommendations section in the main body of the draft.  The security
considerations section is clear about what needs to be done and the
reference is given a couple of lines previously.  We've also added some
more text to the Implementation Suggestions section (after a suggestion
from Alvaro), so in the current version, it would probably look a bit
peculiar to move the path hiding recommendation into the security
considerations section.

> A number of the requirements in section 2.2 and the subsections
> define requirements that differ and often conflict with requirements
> in RFC 4271. It would be good to indicate this at the start of 2.2.

yes, good point. [commit #8c113b3]

> Should this relationship also be called out in the abstract?

Mmm, it's already in the introduction and now in section 2.0.  Having it
in three places would be repetitive.

> The statement at the end of the security considerations section
> points the reader to RFC7454. I was left wondering if this draft
> changes any of considerations in RFC7454. It would be beneficial if
> some text was added to this draft speaking to this point. Again not
> being an expert in BGP security, I am not certain what the new text
> should say on this matter.

The short answer is that it mostly doesn't.

The longer answer is that this ID is a draft about RS implementations
rather than RS operations.  There is a parallel draft
(ietf-grow-ix-bgp-route-server-operations), where this reference and
comment are more appropriate instead.  RFC7454 didn't make it into the
-operations draft because it was published after the last update was
done.  I've just made a note to add this into the operations draft
during AUTH48, along with a side note to say that care needs to be taken
with section 11 of RFC7454.

I've just posted draft -11.  Can you check if this deals with your comments?

Nick

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Fri, 10 Jun 2016 22:48:57 +0000

Nick,

Thank you for following up on my review.

> -----Original Message-----
> From: Nick Hilliard [mailto:[email-masked]]
> Sent: Friday, June 10, 2016 6:36 PM
> To: Waltermire, David A. (Fed) <[email-masked]>
> Cc: [email-masked]; [email-masked]; draft-ietf-idr-ix-bgp-route-
> [email-masked]
> Subject: Re: Secdir review of draft-ietf-idr-ix-bgp-route-server-10
> 
> Hi Dave,
> 
> reference is given a couple of lines previously.  We've also added some more
> text to the Implementation Suggestions section (after a suggestion from
> Alvaro), so in the current version, it would probably look a bit peculiar to
> move the path hiding recommendation into the security considerations
> section.

I am ok with this.

> > A number of the requirements in section 2.2 and the subsections define
> > requirements that differ and often conflict with requirements in RFC
> > 4271. It would be good to indicate this at the start of 2.2.
> 

Thanks.

> Mmm, it's already in the introduction and now in section 2.0.  Having it in
> three places would be repetitive.

Agreed.

> > The statement at the end of the security considerations section points
> > the reader to RFC7454. I was left wondering if this draft changes any
> > of considerations in RFC7454. It would be beneficial if some text was
> > added to this draft speaking to this point. Again not being an expert
> > in BGP security, I am not certain what the new text should say on this
> > matter.
> 
> The longer answer is that this ID is a draft about RS implementations rather
> than RS operations.  There is a parallel draft (ietf-grow-ix-bgp-route-server-
> operations), where this reference and comment are more appropriate
> instead.  RFC7454 didn't make it into the -operations draft because it was
> published after the last update was done.  I've just made a note to add this
> into the operations draft during AUTH48, along with a side note to say that
> care needs to be taken with section 11 of RFC7454.

Thanks for the clarification. What you are suggestion sounds reasonable.

> I've just posted draft -11.  Can you check if this deals with your comments?

Draft -11 looks good.

Thanks,
Dave

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 11 Jun 2016 00:05:19 +0100

On 10 Jun 2016, at 23:48, Waltermire, David A. (Fed) <[email-masked]> wrote:
> Draft -11 looks good

Yay, thanks!

Nick