Subject: Re: Last Call: <draft-ietf-sidr-rpki-rtr-19.txt> (The RPKI/Router Protocol) to Proposed Standard

From: Shane Amante <[email-masked]>
Date: Tue, 13 Dec 2011 20:27:35 -0700

[Resending to [email-masked]]

I am curious why an IETF WG (SIDR) has endorsed a wholly new protocol through which to configure policy information on routers (as proposed in draft-ietf-sidr-rpki-rtr), particularly when the IETF already has existing standards to do so, namely: NETCONF [RFC4741] & YANG [RFC6020]?  In addition, given that NETCONF + YANG were designed for extensibility, they would allow operators to take it upon themselves, if they wish, to easily enrich and/or extend RPKI-validated data before it is sent from an RPKI cache to routers, (compared to a binary protocol like RPKI-RTR).  I don't see any discussion in draft-ietf-sidr-rpki-rtr as to whether: a) consideration was given to develop a YANG model, for validated RPKI data, which then would use NETCONF to securely transport that from an RPKI cache to the router; and, b) if it was considered, what were the reasons that approach was not pursued.

In the short-term, I am concerned that, from an architectural point-of-view, the IETF has not chosen to re-use the existing set of very successful configuration protocols, namely NETCONF & YANG, for the task of configuring validated policy information from the RPKI to/within routers.  This could not only cause confusion in the industry, but also lead to additional operational costs to operators who would have to maintain two protocols for configuring policy on their network: RPKI-RTR and, separately, NETCONF/YANG, particularly when those same operators already have to use NETCONF/YANG for other router configuration tasks anyway.  Furthermore, NETCONF is in shipping & deployed implementations today vs. RPKI-RTR which is likely still several years in the future before it starts shipping in GA SW releases, not including the time it will take to qualify it before it sees actual network deployment.

Longer term, development of a new configuration protocol, (namely RPKI-RTR), likely has architectural implications given the discussion that occurred at IETF 82 in the SDN "informational-gathering session", held on Thursday afternoon.  Although it is a too early to tell where the discussions at that SDN meeting will ultimately lead to, there did seem to be a significant amount of interest in the architectural concept of looking at the problem of attempting to configure networks using a top-down methodology and, in particular, re-using those existing IETF protocols, e.g.: NETCONF/YANG, SNMP, etc., southbound from an SDN Orchestrator toward various network elements.  As such, it may be useful for the IESG and IAB to collaborate on the long-term architectural implications and additional complexity that another "southbound protocol", specifically: RPKI-RTR, could have on future efforts such as those discussed in the SDN meeting.

-shane

On Nov 29, 2011, at 3:51 PM, The IESG wrote:
> The IESG has received a request from the Secure Inter-Domain Routing WG
> (sidr) to consider the following document:
> - 'The RPKI/Router Protocol'
>  <draft-ietf-sidr-rpki-rtr-19.txt> as a Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2011-12-13. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>   In order to formally validate the origin ASs of BGP announcements,
>   routers need a simple but reliable mechanism to receive RPKI
>   [I-D.ietf-sidr-arch] prefix origin data from a trusted cache.  This
>   document describes a protocol to deliver validated prefix origin data
>   to routers.
> 
> 
> 
> 
> 
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr/
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: Randy Bush <[email-masked]>
Date: Wed, 14 Dec 2011 13:42:49 -0800

I am not sure if this is an architectural misunderstanding V a red
herring.

As you say, NetConf is for *configuring* routers.  RPKI-rtr is not used
for router configuration, but rather dynamic data, a la IS-IS or BGP.
In fact, the RPKI-rtr payload data go into the same data structure as
the BGP data.

Of course, the configuration of the RPKI-rtr relationship to cache(s) is
router configuration, similar to configuring BGP peers, and presumably
can be done by NetConf on those platforms which support NetConf.

Bottom line: NetConf 'replaces' the CLI, not BGP.

FWIW, two or three years ago, not wanting to reinvent the wheel, we
looked at NetConf-style payload packaging.  After all, Bert and I
chartered NetConf back in the day.  I still owe a dinner to the two
NetConf folk who helped try.  Unfortunately the mismatch was
non-trivial, though nowhere near the mismatch of DNSsec, at which we
also looked (as the Tonys and I had published in 1998, Lutz in 2006,
etc., of which I presume you are unaware).

When we evaluated the data bloat for NetConf-style packaging we were not
cheered.  While probably not important for a CLI replacement, for a
continuous dynamic protocol the overhead of unpacking XML and decoding
the contained ASCII payload drew unhappy whining from the router
hackers.

NetConf is not ideal for a long-session back-and-forth protocol, with
RPKI-rtr's serial number exchange which leaves the router in control of
the exchanges and enables incremental update of the data.  You *really*
do not want the cache to send the full data set to the router every
time.  And you definitely do not want a cache trying to keep track of
the state of O(100) router clients which may or may not still think they
are its friend.

And, sadly, NetConf is not available on significant platforms where
RPKI-rtr is already running today.

So, all in all, being lazy, of course we tried.  But it was not a good
fit.  Of course, if you want to have a go at it, I am sure we would be
willing to at least kibitz.  But first you might want to talk to the
vendors who have already implemented RPKI-rtr to see if they would be
willing to re-code.

randy

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 15 Dec 2011 00:25:04 +0100

Let me observe that there could be middle ground to both sides here.

While I am very well aware that few of the commercial routers support 
inline origin validation and rpki-rtr protocol to retrieve the abstract 
of RPKI data needed for validation it seems also very clear that this is 
just one possible deployment model.

Let's observe that there are going to be orders of magnitude more BGP 
implementations which will never get the BGP origin validation code into 
their branches yet which will still happily run in many production 
networks for years to come which may be a significant obstacle to the 
deployment of this functionality.

Therefor I would consider an alternative deployment model where the 
validation happens (even if a bit delayed) at few distributed BGP prefix 
validators around given AS then the outcome of such validation is 
distributed in the form of BGP policy configuration (via Netconf) to all 
legacy BGP speakers.

While perhaps risking to say unpopular comment my personal preference 
would be for the latter deployment model. With this in mind I do agree 
with Shane that in general IETF should try to reuse existing protocols 
to accomplish the goals by recommending such deployment models which 
allow one to do so rather then keep inventing more and more protocols to 
address point solutions.

Best,
R.

> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>
>

---

From: Shane Amante <[email-masked]>
Date: Thu, 15 Dec 2011 17:11:56 -0700

On Dec 14, 2011, at 2:42 PM, Randy Bush wrote:
> I am not sure if this is an architectural misunderstanding V a red herring.

Let's call it an architectural misunderstanding.

> In fact, the RPKI-rtr payload data go into the same data structure as

"Dynamic data"?  Isn't that a truism?  We're not carving RPKI data out of stone tablets are we?  :-)

> Bottom line: NetConf 'replaces' the CLI, not BGP.

Here's another bottom-line: today, in my network, there is only one thing that can/does influence BGP policy on an individual router: locally configured (on the router itself) policy.  There is a well-established operational practice that only policy on the router itself, consumed through either CLI or NETCONF, will affect routing decisions made by that box.

RPKI-RTR is introducing a *new* side-channel, (I'm being kind by not calling it a 'backdoor'), through which "dynamic data" is now injected directly to the BGP routing process that "dynamically impacts" BGP policy and, ultimately, it's route-selection.  The key concern I have is: RPKI-RTR is another entry-point into BGP on the router for which I, and every other operator, now need to perform regression testing for each version of code, on each make & model of router!, I roll-out to my network.  If RPKI-RTR had used NETCONF, instead, this likely would have used an existing mechanism of loading, and evaluating, BGP policy in routers that exist *today*, (and since the dawn of time).  This is a non-trivial operational expense bourne by the entire SP industry for the lifetime of RPKI-RTR.

> the contained ASCII payload drew unhappy whining from the router

Was this discussed in the IETF?  If so, do you have a pointer to the evaluation or results of those findings?

Most importantly, why this overwhelming concern about "bloat" from NetConf-style packaging?  Surely there is substantial 'overhead' in pushing around just the RPKI data amongst the RPKI caches, (even within a single ISP), including having RPKI caches verify signatures associated with new RPKI updates on the caches?  NetConf would seem to be the least of the concerns here, but without an elaboration of the issues you cite, it's unclear if those issues were valid, let alone if they could have been mitigated.

> the state of O(100) router clients which may or may not still think they

Hrm, I think there is a grave misunderstanding indeed.  A few points:
a)  The current draft, draft-ietf-sidr-rpki-rtr-20, contradicts what you say above wrt not sending the full data set every time:
---snip---
   [...]  As with any update protocol based on
   incremental transfers, the router must be prepared to fall back to a
   full transfer if for any reason the cache is unable to provide the
   necessary incremental data.
---snip---
b)  I think there is a very bad assumption, above, that the router is a "database of record" and, therefore, should be the one in control of consuming configuration, excuse me: "dynamic", updates from RPKI caches.  That's not how networks are, or should be, run in my experience.  ISP's already have systems that maintain physical & logical inventory in offline DB's and, just as importantly, coordinate/synchronize changes from their offline systems to O(1,000's) of routers.  You need that for physical & logical inventory purposes alone, let alone more fancy configuration of routing protocols on those same devices.
c)  In draft-ietf-sidr-origin-ops-13, there is a suggestion that if "RPKI data [is used] as an input to operational routing decisions, they SHOULD ensure local cache freshness at least every four to six hours."  However, I believe it's been suggested that (Global?) RPKI synchronization intervals may, in practice, be as large as 24 hours.  Regardless, in my experience, anything that's updated on the order of hours is surely the domain of "configuration" and isn't what I would consider "dynamic" like would be the case in a routing protocol such as IS-IS or BGP.
d)  Given the above, very lax synchronization intervals of the underlying RPKI data, I don't see the need to open a long-lived TCP connection, (or as you said a couple of paragraphs ago: "continuous dynamic protocol"), between RPKI cache to receiving RPKI router.  Instead, do what is done today: NETCONF/SSH into the box when needed, i.e.: every 4 - 6 hours or 24 hours when new RPKI data arrives at the cache(s).
e)  Given the success operators have today with generating very, very large prefix-lists, (today based on IRR data), and periodically pushing them through the CLI into routers, it seems a misguided assumption that one is "required" to have incremental updates of data, particularly given the several hour intervals we're talking about here for new/updated RPKI data to arrive.  Nonetheless, if one wanted to do this, then please at least give us operators some credit that we're smart enough to (help) create NETCONF schemas that would be amenable to incremental updates onboard the router, based on a variety of well-known CompSci techniques, and which could also take advantage of RFC 5717, NETCONF Partial Locking.

> RPKI-rtr is already running today.

That's a bit of a circular argument isn't it?  RPKI-RTR is in existence today due to pre-standards development, which is fine, everyone does it.  Certainly a RPKI-RTR NETCONF schema would be there, today, had SIDR gone that as a direction, no?

-shane

---

From: Warren Kumari <[email-masked]>
Date: Mon, 19 Dec 2011 09:21:35 -0500

> beginning of the Subject line to allow automated sorting.

Support.

I have (carefully) read and reviewed this document and support publication….

W

---

From: Eric Osterweil <[email-masked]>
Date: Tue, 20 Dec 2011 10:28:55 -0500

> Bottom line: NetConf 'replaces' the CLI, not BGP.

Whoa... I am likely off in the weeds here, but if NetConf is operating on fundamentally different data and doesn't suffice here, wouldn't flow spec work?  You know, in the spirit of not reinventing the wheel?

> the contained ASCII payload drew unhappy whining from the router

Would it be possible to get a pointer to some of this eval?  I tried some google'ing and my typical ineptitude left me without any leads.

> the state of O(100) router clients which may or may not still think they

Wait, is this discussion about the impact of a new provisioning/configuration protocol for BGP routers, or a red herring about the scalability of the current cache design (which is a separate issue, if I'm not mistaken)?  imho, the architectural limitations of the cache design should not shift undue onus onto routers and justify new protocols (in of itself).  If the only reason not to use NetConf or flow spec is that the caches can't take the load of managing state, then maybe we should refocus on addressing the caches, and presume that new protocols to configure the routers is a last resort (rather than a first step).

> RPKI-rtr is already running today.

I just want to understand this: is the statement here that RPKI-rtr is more widely deployed than NetConf, or its deployment base is somehow more valuable, or something?

> vendors who have already implemented RPKI-rtr to see if they would be

Is there any reference to any sort of evaluation that we can get?  I (personally) understand that there are "experts in the room," but it would be nice to be able to look at some information so the rest of us can understand some of these limitations. :)

I don't think the current argument justifies this work, but I'm looking forward to hearing about any more info that might change this.

Thanks!

Eric

---

From: Danny McPherson <[email-masked]>
Date: Tue, 20 Dec 2011 17:51:28 -0500

> In fact, the RPKI-rtr payload data go into the same data structure as

But aren't you're still going to need that static configuration data that's there today to augment this (e.g., customer prefix lists and nested AS path filter lists), it's not replacing anything, just adding more systems and cost?

If it's in a data structure like BGP data is it not persistent across reboots?   If so, I've now got to download >400k origin,prefix policy bindings from RPKI caches after each reboot, at the very same time I'm also trying to pickup the routing tables that the RPKI data is meant to help with validation for.  Is there really that much churn in this policy configuration data (origin,prefix) that it can't exist in static policy configuration files like the rest of the policy and router configuration data?

-danny

---

From: Danny McPherson <[email-masked]>
Date: Tue, 20 Dec 2011 18:00:57 -0500

I'm kinda surprised the security ADs are OK with this in a brand new connection-oriented protocol meant to increase security of the network:

S.7:

"Caches and routers MUST implement unprotected transport 
over TCP using a port, rpki-rtr, to be assigned, see Section 12.
Operators SHOULD use procedural means, ACLs, ... to reduce 
the exposure to authentication issues."

-danny

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 20 Dec 2011 23:17:45 +0000

Hi Danny,

> I'm kinda surprised the security ADs are OK with this in a brand new connection-oriented protocol meant to increase security of the network:

Me too. I didn't even know I'd read that draft yet:-)

When I do read it then I'll be ok with it or will
not be ok with it. Neither applies yet.

S

---

From: Danny McPherson <[email-masked]>
Date: Tue, 20 Dec 2011 18:44:40 -0500

> Me too. I didn't even know I'd read that draft yet:-)

Hah, meant routing ADs, but certainly, security ADs will have some opinion on this.

-danny

---

From: Warren Kumari <[email-masked]>
Date: Tue, 20 Dec 2011 20:17:48 -0500

> the exposure to authentication issues."

Yup. 

Just below the text that you included there is: "If available to the operator, caches and routers SHOULD use one of the following more protected protocols." and a list of things including AO, SSH, TCP MD5, IPSEC, TLS. 

Sections 7.1. (SSH Transport), 7.2.  (TLS Transport), 7.3.  (TCP MD5 Transport) and 7.4.  (TCP-AO Transport) provide more information on using these.

The Security Considerations section also say:
      ...
      So the strength of the trust relationship and the transport
      between the router(s) and the cache(s) are critical.  You're
      betting your routing on this.
      …
      Transports which can not provide the necessary authentication and
      integrity (see Section 7) must rely on network design and
      operational controls to provide protection against spoofing/
      corruption attacks.

I'm sure that the authors would have preferred to simply say "Use TCP-AO", and saved themselves a bunch of typing (and Security warnings, etc) -- it is obvious that they are not tying to gloss over the concerns.

Unfortunately not all OSs support TCP-AO…. Well then, it seems that, as routers already support SSH it should be simple to wrap a TCP stream, yes? Unfortunately no -- not all implementations have a simple library type model. Same things for IPSec / TLS, etc.

In an ideal world there would be ubiquitous, secure, fast, cheap, reliable, unencumbered transport security -- unfortunately we are not there (yet). Folk who have support for secure transports available should use them, but if I don't, I'd still like to have the option to deploy this.

The perfect is the enemy of the good.

> -danny

Warren.

---

From: Danny McPherson <[email-masked]>
Date: Tue, 20 Dec 2011 21:42:12 -0500

> Unfortunately not all OSs support TCP-AO…. Well then, it seems that, as routers already support SSH it should be simple to wrap a TCP stream, yes? Unfortunately no -- not all implementations have a…

Given that this would seem to be an underpinning element of a next-generation system aiming to enable more secure routing, we don't have to be fully constrained by what we can cobble together and support in a couple repurposed lab boxes, methinks.  

If that's indeed the case then perhaps we should consider why routers are establishing persistent transport connections to OSs and can't speak to one another in a secure manner.

-danny

---

From: Randy Bush <[email-masked]>
Date: Tue, 20 Dec 2011 22:52:53 -0500

> If it's in a data structure like BGP data is it not persistent across
> reboots?

rpki prefix/origin data are just as persistent as the bgp data in the
router.  i.e. not at all.

randy

---

From: Randy Bush <[email-masked]>
Date: Wed, 21 Dec 2011 06:44:44 -0500

>> I'm kinda surprised the security ADs are OK with this in a brand new
>> connection-oriented protocol meant to increase security of the
>> network:
> 
> When I do read it then I'll be ok with it or will not be ok with it.
> Neither applies yet.

this was discussed with HO in helpful secdir review:

    there is no reasonable (integrity and authentication, we do not care
    about privacy) protocol X implemented on all servers (unix, linux,
    solaris) and routers (cisco, juniper, ...).  AO, $diety's gift to
    the wire, is on none of them.  there are routers which have an ssh
    server built into the cli but which do not have an ssh library
    available to new hacks such as rpki-rtr.  freebsd can generate md5
    but does not check it on receipt.  and so on.  ground truth is very
    uuuuugly.

for when this was discussed in wg last call, see

    http://www.ietf.org/mail-archive/web/sidr/current/msg02899.html
    http://www.ietf.org/mail-archive/web/sidr/current/msg03186.html
    http://www.ietf.org/mail-archive/web/sidr/current/msg02694.html

a bunch security folk probably remember the discussion then, amusingly
some folk seem not to.

randy

---

From: Russ Housley <[email-masked]>
Date: Wed, 21 Dec 2011 08:01:49 -0500

> the exposure to authentication issues."

Since all of the objects that are transferred over this protocol are digitally signed, I do not see a security issue.  I think the Security Considerations section (Section 11) does a good job explaining the situation

Russ

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 21 Dec 2011 14:24:01 +0100

On Wed, Dec 21, 2011 at 08:01:49AM -0500,
 Russ Housley <[email-masked]> wrote 
 a message of 22 lines which said:

> Since all of the objects that are transferred over this protocol are
> digitally signed,

Over RTR? It is not mentioned in the I-D, quite the contrary.

> I think the Security Considerations section (Section 11) does a good
> job explaining the situation

Precisely, it explains that the link router<->cache must be secured
because the data is *not* signed:

      But this protocol document assumes that the routers can not do the
      validation cryptography.  Hence the last link, from cache to
      router, is secured by server authentication and transport level
      security.  This is dangerous, as server authentication and
      transport have very different threat models than object security.

---

From: Danny McPherson <[email-masked]>
Date: Wed, 21 Dec 2011 08:59:56 -0500

> Since all of the objects that are transferred over this protocol are digitally signed, I do not see a security issue.  I think the Security Considerations section (Section 11) does a good job expla…

They're signed and validated by the router?  Where?  I don't see that in the current spec and quite the contrary in the Security Considerations section, as Stephane pointed out and being the element that triggered my initial concern.

Also, what happened to defense in depth?  Even if they were signed (they're not) then object level integrity doesn't obviate the need for network and transport layer protections, else off-path attackers could easily trigger considerable churn with transport connection resets that could manifest themselves [directly] in the router control plane or impact routability of prefixes through validation state downgrade attacks, or misbehaving devices at lower layers could cause application-level object validation failures, how are these handled?

I see a "turtles all the way down" problem here:

  "Integrity protection for payloads is also desirable to protect against 
   monkey in the middle (MITM) attacks.  Unfortunately, there is no 
   protocol to do so on all currently used platforms.  Therefore, as of this 
   document, there is no mandatory to implement transport which provides 
   authentication and integrity protection."

I didn't realize support on "all currently used platforms" was a requirement
for a new security capability.

-danny

---

From: Matthias Waehlisch <[email-masked]>
Date: Tue, 20 Dec 2011 01:45:16 +0100

>    The IESG has received a request from the Secure Inter-Domain 
> Routing WG (sidr) to consider the following document:
>    The IESG plans to make a decision in the next few weeks, and 
> solicits final comments on this action. Please send substantive 
> comments to the ietf at ietf.org mailing lists by 2011-12-13. 
> Exceptionally, comments may be sent to iesg at ietf.org instead. In 
> either case, please retain the beginning of the Subject line to allow 
> automated sorting.
>
  I read the document, we implemented the protocol, and support further 
publication of the specs.

matthias

-- 
Matthias Waehlisch
.  Freie Universitaet Berlin, Inst. fuer Informatik, AG CST
.  Takustr. 9, D-14195 Berlin, Germany
.. mailto:[email-masked] .. http://www.inf.fu-berlin.de/~waehl
:. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net

---

From: Eric Osterweil <[email-masked]>
Date: Tue, 20 Dec 2011 10:24:39 -0500

Thanks!

Eric

---

From: Russ Housley <[email-masked]>
Date: Wed, 21 Dec 2011 11:55:13 -0500

Stephane:

Sorry, I was too terse in my response.  Let me try again.

All of the inputs to the server are signed, so there is no concern about theses objects being modified.

Once process by the server, a protocol that provides authentication and integrity protection is used between the server and router.  From the Table of Contents, the choices are clear:
     7.1.  SSH Transport
     7.2.  TLS Transport
     7.3.  TCP MD5 Transport
     7.4.  TCP-AO Transport

I would personally prefer that the TCP MD5 choice not be used, but the model is clear.

This approach lets the server handle that certificate path construction, signature checking, and revocation checking.  It seems desirable to offload these potentially expensive operations, while preserving the integrity of the subset of the information actually needed by the router.

Russ

---

From: Danny McPherson <[email-masked]>
Date: Wed, 21 Dec 2011 12:37:42 -0500

> This approach lets the server handle that certificate path construction, signature checking, and revocation checking.  It seems desirable to offload these potentially expensive operations, while pr…

Right, so precisely back to my original concern:

-danny

---

From: Russ Housley <[email-masked]>
Date: Wed, 21 Dec 2011 13:06:19 -0500

> the exposure to authentication issues."

Maybe I misunderstood your concern.  The operator's server to the operator's routers only involves the operator's internal network.  While I would personally prefer a mandatory-to-implement mechanism, I can see that operators do not necessarily want prescriptive statements on this part of the specification.

Russ

---

From: Danny McPherson <[email-masked]>
Date: Wed, 21 Dec 2011 13:56:22 -0500

> Maybe I misunderstood your concern.  The operator's server to the operator's routers only involves the operator's internal network.  While I would personally prefer a mandatory-to-implement mechani…

Hahhh..

I don't see a requirement that says that the RPKI cache much be on the local operators network, else you just created an industry for 60k+ caches, at least(!)..

Additionally, we should apply this to all IGP work?  Why are we doing KARP?  And why no bi-lateral, so we don't really need transport protections at all in eBGP?

Not subscribing to this...

-danny

---

From: "t.petch" <[email-masked]>
Date: Thu, 22 Dec 2011 21:15:38 +0100

----- Original Message -----
From: "Russ Housley" <[email-masked]>
To: "Danny McPherson" <[email-masked]>
Cc: "IETF" <[email-masked]>
Sent: Wednesday, December 21, 2011 7:06 PM
>
> >> Once process by the server, a protocol that provides authentication and
integrity protection is used between the server and router.  From the Table of
Contents, the choices are clear:
> >> This approach lets the server handle that certificate path construction,
signature checking, and revocation checking.  It seems desirable to offload
these potentially expensive operations, while preserving the integrity of the
subset of the information actually needed by the router.
> Maybe I misunderstood your concern.  The operator's server to the operator's
routers only involves the operator's internal network.  While I would personally
prefer a mandatory-to-implement mechanism, I can see that operators do not
necessarily want prescriptive statements on this part of the specification.

Russ

The question of where the servers would be located, locally or somewhere out on
the Internet, was raised during the development of this document and the answer
was, we do not know; so I think that if you only regard it as secure when only
an internal network is involved, then that needs calling out in the Security
Considerations.

Tom Petch

---

From: Russ Housley <[email-masked]>
Date: Thu, 22 Dec 2011 17:14:47 -0500

> an internal network is involved, then that needs calling out in the Security

I agree.

Russ

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 22 Dec 2011 23:31:58 +0100

Hi Tom,

> an internal network is involved, then that needs calling out in the Security

Let me observe that significant number of "internal networks" these days 
go over third party unencrypted or unsecured to the desired level VPNs.

So is it ok to state that a network which consists of N sites all with 
external EBGP feed while being interconnected by L3VPN could use single 
cache residing only in one site ?

Thx,
R.

---

From: Randy Bush <[email-masked]>
Date: Thu, 22 Dec 2011 18:34:40 -0500

> an internal network is involved, then that needs calling out in the Security

what the document actually says

   Transport Security:  The RPKI relies on object, not server or
      transport, trust.  I.e. the IANA root trust anchor is distributed
      to all caches through some out of band means, and can then be used
      by each cache to validate certificates and ROAs all the way down
      the tree.  The inter-cache relationships are based on this object
      security model, hence the inter-cache transport can be lightly
      protected.

      While we can not say the cache must be on the same LAN, if only
      due to the issue of an enterprise wanting to off-load the cache
      task to their upstream ISP(s), locality, trust, and control are
      very critical issues here.  The cache(s) really SHOULD be as
      close, in the sense of controlled and protected (against DDoS,
      MITM) transport, to the router(s) as possible.  It also SHOULD be
      topologically close so that a minimum of validated routing data
      are needed to bootstrap a router's access to a cache.

      The identity of the cache server SHOULD be verified and
      authenticated by the router client, and vice versa, before any
      data are exchanged.

send text for what you think should be added.

randy

---

From: Steven Bellovin <[email-masked]>
Date: Thu, 22 Dec 2011 21:39:40 -0500

Let me call attention to this sentence, too:

>  It also SHOULD be

That is, there are other, quite important, reasons to keep the cache
very close to the router(s) it serves.

		--Steve Bellovin, https://www.cs.columbia.edu/~smb

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 23 Dec 2011 11:44:36 +0100

Steven,

If the cache is within your domain the below sentence does not apply as 
you are not validating your IGP routes to bootstrap a router's 
reachability to a cache.

If the cache would be outside of your domain this sentence would apply 
as you would require to accept and install some set of essentially "NOT 
FOUND" routes to reach the cache.

Therefor if authors of draft-ietf-sidr-rpki-rtr-XX are really serious 
about recommending to keep the cache locally within each domian the 
below sentence you are quoting should be fixed or removed.

Rgs,
R.

---

From: Steven Bellovin <[email-masked]>
Date: Fri, 23 Dec 2011 16:45:20 -0500

Let me clarify what I said (and include context that I should have
put in my earlier note).

Security mechanisms are not designed in a vacuum.  One has to consider
the users, the threats, and the usage scenarios.  To take an absurd
example, while I can do Caesar ciphers in my head I'm quite incapable
of mental exponentiations of 2048-bit numbers; accordingly, I'm forced
to trust a computer to do those for me.  On the other hand, if I'm
trying to protect a secret from a first grader who has just learned
how to read, a Caesar cipher may be all I need.

The same principles apply here.  Given the desire to bootstrap secure
routing, we concluded that most ISPs would rely on local -- very local
-- caches.  In fact, I suspect that many, especially large ones, would 
want a cache per POP.  

You're quite correct that this implies no validation of IGP routes.
That's by intent -- the very first sentence of the abstract states
that RPKI is intended to validate BGP routes.  (If you have outsiders
sending your internal routes into your IGP via BGP, you have bigger
problems that RPKI can fix...) 

Given this, and given the reality of available platforms, we had to
make a decision.  The usage model suggests that the risk is low;
the capabilities of the platforms suggest that we couldn't actually
get the security we wanted, just like I can't do mental RSA (at least
until I get that brain chip implanted....).

On Dec 23, 2011, at 5:44 36AM, Robert Raszuk wrote:

> Steven,
> 
> If the cache is within your domain the below sentence does not apply as you are not validating your IGP routes to bootstrap a router's reachability to a cache.
> 
> If the cache would be outside of your domain this sentence would apply as you would require to accept and install some set of essentially "NOT FOUND" routes to reach the cache.
> 
> Therefor if authors of draft-ietf-sidr-rpki-rtr-XX are really serious about recommending to keep the cache locally within each domian the below sentence you are quoting should be fixed or removed.
> 
> Rgs,
> R.
>

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 24 Dec 2011 01:52:28 +0100

Hello Steven,

 > -- caches.  In fact, I suspect that many, especially large ones, would

The fact that you say "we concluded" is indeed very interesting. I 
wonder how much real ISPs and SPs have contributed to this conclusion. 
To the extend I was part of those discussions I saw very little to none.

 > get the security we wanted,

Sorry to say this today but I think that you got the deployment model 
wrong which directly translates into platforms you are performing the 
actual validation on. I recall feedback from operators in the early 
stages of the design which suggest that validation could be done in few 
places of the domain then security applied p2mp once wrong route is 
detected.

Contrary you went and recommended upgrade of each ASBR. This is pure 
fantasy. There are IETF drafts by vendors who say black on white that 
some of their products will not get any new features in. That means that 
as long as this equipment is running basic origin validation will not 
get deployed.

When I sit and look from the perspective of both vendor and operator I 
do wonder what is the real goal here.

Last you still have not commented on the applicability of the statement 
you quoted. What is it actually saying considering no validation for IGP 
routes nor IBGP routes if anyone would like to carry it's internal 
reachability subnets within ibgp.

Happy Holidays !
R.

---

From: "t.petch" <[email-masked]>
Date: Wed, 28 Dec 2011 11:35:07 +0100

----- Original Message -----
From: "Randy Bush" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "IETF" <[email-masked]>
Sent: Friday, December 23, 2011 12:34 AM
> send text for what you think should be added.

Randy

The problem is the disconnect (as I see it) between Security Considerations and
Transport.  The latter says that unprotected transport over TCP is mandatory,
the former that ".. the last link, from cache to
      router, is secured by server authentication and transport level
      security."

I am stuck trying to work out how unprotected transport over TCP gives transport
level security.

If it does not, then I would add a sentence to that paragraph in the Security
Considerations along the lines of
"This cannot be achieved with the mandatory-to-implement transport protocol
TCP."

I would also add to Transport
"Unprotected transport over TCP should only be used within an operator's local
network where adequate security can be achieved by other means."
at the end of the paragraph that states that TCP is a MUST.

Tom Petch

---

From: "t.petch" <[email-masked]>
Date: Wed, 28 Dec 2011 11:45:01 +0100

----- Original Message -----
From: "Robert Raszuk" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Russ Housley" <[email-masked]>; "Danny McPherson" <[email-masked]>;
"IETF" <[email-masked]>
Sent: Thursday, December 22, 2011 11:31 PM

> go over third party unencrypted or unsecured to the desired level VPNs.

Robert

You surprise me.  My impression of VPNs is that they are one of few areas where
operators show some signs of offering and using security, like using a cipher
suite with 56 bit entropy instead of 8 alphabetic characters sent in clear.
Inadequate, true, but with the basics in place, capable of being upgraded to
offer real security.

Tom Petch

---

From: "Borchert, Oliver" <[email-masked]>
Date: Fri, 23 Dec 2011 13:10:32 -0500

We have implemented an earlier version of the protocol for our BGP-SRx
software (www-x.antd.nist.gov/bgpsrx) and the BRITE framework
(brite.antd.nist.gov) and plan on upgrading our implementation to the
latest available version.

We will support this protocol/version going forward.

Oliver

---------------------------------------------------------------------------
-

Oliver Borchert  Computer Scientist
National Institute of Standards and Technology
phone: 301-975-4856, fax: 301-975-6238

On 11/29/11 5:51 PM, "The IESG" <[email-masked]> wrote:

>sidr mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sidr