Subject: [secdir] Secdir review of draft-ietf-sidr-origin-validation-signaling-09

From: Tero Kivinen <[email-masked]>
Date: Wed, 23 Nov 2016 17:00:39 +0200

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.

This is quite short draft explaining how to transmit prefix origin
validation state over BGP. Its security considerations section say:

   This document introduces no new security concerns beyond what is
   described in [RFC6811].

I think this is mostly correct, but I also think that there might be
also new security considerations when you are not doing prefixi origin
validation yourself, but you are trusting someone else to send you
that information. I.e. you need to know whether the sender should be
trusted to send that information and how the BGP information is
protected from tampering (on the other hand if you trust BGP
information from untrusted sources, or allow attackers to modify BGP
messages, you most likely have more serious issues :-)

Adding that kind of text to the security considerations section would
be needed.
-- 
[email-masked]

---

From: Randy Bush <[email-masked]>
Date: Thu, 24 Nov 2016 02:20:06 -0500

> Adding that kind of text to the security considerations section would

well said.  outsourcing security is a tenuous method and needs to be
flagged.

i do not hold the pen, otherwise i would fix.

randy

---

From: "John G. Scudder" <[email-masked]>
Date: Sun, 27 Nov 2016 14:14:02 -0500

> i do not hold the pen, otherwise i would fix.

I believe I have the current source. If someone sends me text, I'll paste it, or otherwise I'll send out the XML when I get a chance on Monday. If we have to wait for me to write the proposed text, it will not be very soon.

--John

---

From: Randy Bush <[email-masked]>
Date: Mon, 28 Nov 2016 09:47:43 -0800

This document describes a scheme where router A out-sources validation
to some router B.  Out-sourcing security is generally dangerous.  It is
strongly recommend that, if this scheme is to be used, that the
participating routers be under the same administrative control;
i.e. router B has truest in router A, and that there be some assurance
of the propagation path (TCP/MD5 authentication etc.).

randy

---

From: "John G. Scudder" <[email-masked]>
Date: Mon, 28 Nov 2016 16:49:53 -0500

[Fixed up some addresses]

> On Nov 28, 2016, at 12:47 PM, Randy Bush <[email-masked]> wrote:
> 

How about this?

 This document describes a scheme where router A outsources validation
 to some router B. If this scheme is to be used, the participating
 routers should have the appropriate trust relationship -- B should
 trust A either because they are under the same administrative control
 or for some other reason (for example, consider
 [draft-ietf-sidr-route-server-rpki-light]). The security properties of
 the propagation path between the two routers should also be
 considered. See [RFC 7454] Section 5.1 for advice regarding protection
 of the propagation path.

(both refs informative)

I'll wait a day or two for comments and if none, I'll publish. Thanks for the text.

--John