Subject: [sidr] Answering a question at the mic in Prague: Peter Lothberg's "what about vpn providers?"

From: Christopher Morrow <[email-masked]>
Date: Fri, 3 Jun 2011 00:52:44 -0400

Peter asked at the mic about how SIDR/BGPSEC could/would/etc deal with
VPN providers. I believe he meant something like MPLS VPN (RFC2547)
providers. I think that after some discussion about this with a few of
the document authors a summary of direction is:

A set of questions about the problem space (again, assuming 2547-type
vpn deployment was the target of the question)
  o  “what are you trying to secure?”
      i  vpn-provider to vpn-provider routing domain?
      ii  single-customer routing domain?
  o  not all customer routes are picked up by BGP in VPN scenarios
      i ospf/rip/eigrp/static routes
      ii lack of origin by the AS-Owner (ROAs would be required to the
VPN provider, not a problem)
  o  not all customers have unique ip space across a single provider,
never mind multiple providers
  o  not all customers have unique ASNs across a single provider
  o  route-targets are only unique across a single vpn-provider

Of the above the only open question was as to what the scope of
‘secure’ would be, we decided (in the discussion) that the scope we
would apply to the discussion is the:
  vpn-provider to vpn-provider security

Given a scenario that looks like:
vpn-provider BOB with vpns:
 A - route-target A - prefix 10.0.0.0/8
 B - route-target B - prefix 10.0.0.0/8
 C - route-target C - prefix 10.0.0.0/8

vpn-provider SALLY with vpns:
 Z - route-target Z - prefix 10.0.0.0/8
 Y - route-target Y - prefix 10.0.0.0/8
 X - route-target X - prefix 10.0.0.0/8

Each provider has their own Trust Anchor: TA-BOB and TA-SALLY
these Trust Anchors contain (notionally) the following routing/roa information:
 TA-BOB:
     AS-A:RT-A:10.0.0.0/8
     AS-B:RT-B:10.0.0.0/8
     AS-C:RT-C:10.0.0.0/8
     AS-D:RT-D:10.0.0.0/8

 TA-SALLY:
     AS-Z:RT-Z:10.0.0.0/8
     AS-Y:RT-Y:10.0.0.0/8
     AS-X:RT-X:10.0.0.0/8
    AS-D:RT-V:10.0.0.0/8

The two vpn-providers are connected together in order that their
customers can have a vpn extending across both networks, for the case
where a single provider (BOB) needs to extend their VPN service
reach/territory into a region where they do not have (for reasons
unimportant to the discussion) presence/facilities. If the intent is
to secure vpn-provider to vpn-provider route exchange, some service
must exist that translates:
 AS-D:RT-D:10.0.0.0/8 vs AS-D:RT-V:10.0.0.0/8

A proposed mapping service would accomplish this translation between
the vpn-providers that participate in the single-customer,
multi-provider network scenario. An open question, is whether this is
necessary in a single provider deployment.

It seems that the mechanisms being proposed for BGPSEC can be extended
to support the vpn-provider solution with the addition of a
RouteTarget extension to the ROA End Entity Cert. This would require
updating the certificate profile [draft-ietf-sidr-cp], and running the
algorithm change process [draft-ietf-sidr-algorithm-agility], in order
to flood proper certificates out with the new extension. We could, of
course, choose to change the cert profile today (except that it is in
rfc editor queue at this time) and decide that RT=0 (for instance) is
the “Internet”. It seems that the other mechanisms (mapping service)
still need to be better defined, so revising the certificate profile
later shouldn’t be a show stopper.

I hope the above helps some with Peter's question? Also, I'm really
just the note taker on the above, the authors were more involved with
the thought process (which makes sense to me, I do admit). Thanks for
your indulgence!

-Chris

---

From: Roque Gagliano <[email-masked]>
Date: Fri, 3 Jun 2011 12:08:01 +0200

Hi Chris,

Thank you for open this issue to the list.

From you email I did not get which is the security threat that you are trying to address. Is it just "fat fingers"? 

Also, I believe you may have a typo in your implementation comment as you cannot represent the RT in a certificate as it is not supported in the X.509 specification (i.e. RFC3779) . So, I guess you were referring to modify the ROA signed object to include the RT information.  In this case, what if you just define a new signed object for VPN interconnections? We do not change anything of what has be done up to now and we do not need to wait for any roll-over. Then, each RP can store their locally define objects, use local policies (based on the ta-local draft) on its validators  and an extension to the rtr protocol to transmit the RTs-prefixes to the BGP speakers.

Finally, please note that the current agility draft only addresses the process for an algorithm suite change. Not for a change in the certificate profile or any change in basic RPKI certificates or signed objects. 

Roque.

On Jun 3, 2011, at 6:52 AM, Christopher Morrow wrote:

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

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 3 Jun 2011 16:41:44 -0400

On Fri, Jun 3, 2011 at 6:08 AM, Roque Gagliano <[email-masked]> wrote:
> From you email I did not get which is the security threat that you are
> trying to address. Is it just "fat fingers"?

That's a great question... which I hope Peter will clarify, but I
think one stab at an answer may be:
"Stop one VPN provider from announcing space inside a VPN that
shouldn't be there."

So, some of this is likely fat-fingers, yes... across vpn boundaries
where RT's and such are not necessarily the same, and there is a level
of indirection at play between end-users and providers, some assurance
that the customer can have an impact on the provider (mis-)behaviour I
think is good.

Peter?

> Also, I believe you may have a typo in your implementation comment as you
> cannot represent the RT in a certificate as it is not supported in the X.509
> specification (i.e. RFC3779) . So, I guess you were referring to modify the
> ROA signed object to include the RT information.  In this case, what if you

I'd defer to someone who's profession is certs... (dr. kent? as a
simple first guess) The thinking may have been to overload some other
field in a EECert with RT content. That's likely a poor choice long
term though ("lets use that spare bit in the ip header for
pet-project-123!!" ...no)

> just define a new signed object for VPN interconnections? We do not change

what would the interconnection object say/contain?

> anything of what has be done up to now and we do not need to wait for any
> roll-over. Then, each RP can store their locally define objects, use local

Roll over would only be required if this idea has merit, work is done
to flesh it out and roll it out... in fact, it's only REALLY required
if there are networks that would share VPN and "public" routing data,
but that's neither here nor there right now.

> policies (based on the ta-local draft) on its validators  and an extension

this requires each RP to have a local-TA configured for each VPN peer
they talk to, no? I imagine that's goign to get complicated, and
there's no simple guarantee that RTA in VPNA is the same as RTA in
VPNB... so some map still has to happen (I think).

> to the rtr protocol to transmit the RTs-prefixes to the BGP speakers.
> Finally, please note that the current agility draft only addresses the
> process for an algorithm suite change. Not for a change in the certificate
> profile or any change in basic RPKI certificates or signed objects.

Sure, but in the short term that would look almost like an algorithm
change... or close enough for gov't work :) (discussion on list,
details later)

THanks for the read so far though :)

-chris