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

[Christopher Morrow <[e-mail]>]

On Fri, Jun 3, 2011 at 6:08 AM, Roque Gagliano <[e-mail]> wrote:
> 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"?

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

> Roque.
>
> On Jun 3, 2011, at 6:52 AM, Christopher Morrow wrote:
>
> 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
> _______________________________________________
> sidr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidr
>
>