Subject: Re: [Idr] draft-ymbk-l3vpn-origination-00.txt

From: Robert Raszuk <[email-masked]>
Date: Tue, 16 Oct 2012 05:29:09 +0200

Dear authors,

I have one doubt regarding this proposal ...

Abstract says:

"This document describes how the sender of the VPN/Prefix binding may
sign it so that recipient of the binding may authenticate it."

I highly agree that this would be useful to address.

However just going to introduction section we find:

   This document describes how the originating PE, West, may sign the
   announcement so that the destination PE, East, may authenticate the
   NLRI and the Route Distinguisher (RD), , see RFC 4364 [RFC4364]

Let me point out that West PE is not the originator of the route
advertisement .. neither East PE is the destination. Originator and
destination are corresponding CEs on both sides.

With this in mind let me also point out that RFC4364 VPN sites very
often use private addresses which are never part of any public RPKI
for one simple reason that public RPKI has no notion of RDs to make
such prefixes unique.

Last let me point out also that RFC4364 defines CSC interconnect model
which this draft also does not comment on.

With this in mind I find the document quite incomplete at it's current
form to progress it further. Also I think l3vpn WG should be cc-ed on
this thread.

Best regards,
R.

On Mon, Oct 15, 2012 at 8:08 PM, Randy Bush <[email-masked]> wrote:
> Filename:        draft-ymbk-l3vpn-origination
> Revision:        00
> Title:           Authenticating L3VPN Origination Signaling
> Creation date:   2012-10-15
> WG ID:           Individual Submission
> Number of pages: 6
> URL:             http://www.ietf.org/internet-drafts/draft-ymbk-l3vpn-origination-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-ymbk-l3vpn-origination
> Htmlized:        http://tools.ietf.org/html/draft-ymbk-l3vpn-origination-00
>
>
> Abstract:
>    A BGP-signaled Layer-3 VPN's prefix bindings sent over BGP are
>    subject to unintentional errors, both by the legitimate originator
>    and by non-legitimate origins.  This is of special concern if the VPN
>    traverses untrusted networks.  This document describes how the sender
>    of the VPN/Prefix binding may sign it so that recipient of the
>    binding may authenticate it.
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 16 Oct 2012 06:03:31 +0200

Hello Randy,

On Tue, Oct 16, 2012 at 5:41 AM, Randy Bush <[email-masked]> wrote:
> thanks for review!

You are very welcome !

> good catch!

I was not that much fishing here ... just trying to understand if you
are validating CE-CE or PE-PE. If the latter I unfortunately think
there is much less of the value.

When we originally started to roll out 2547 there was very clear
consensus that real protection must happen on the CE-CE boundary.
Trusting SP where anyone who logs into PE can do anything for any VPN
there was never taken serious.

Note that the draft could also allow both, but this needs to be
clearly stated in the text.

> if they want to use the rpki, then, just as other rpki publishers using
> 1918 space, they would have local trust anchors and certify the private
> space.  see draft-ietf-sidr-ltamgmt.

And what happens in the event of PE-PE validation where only one SP of
L3VPN subscribes to RPKI business ?

> more specific cite, please?  thanks.

http://tools.ietf.org/html/rfc4364#section-9

Summary ... PEs are not involved in distribution of customer routes
between customer sites.

R.

> randy

---

From: Randy Bush <[email-masked]>
Date: Mon, 15 Oct 2012 17:41:52 -1000

thanks for review!

good catch!

randy

---

From: Randy Bush <[email-masked]>
Date: Mon, 15 Oct 2012 18:09:35 -1000

> clearly stated in the text.

it tries to make that pretty clear

   This document describes how the originating PE, West, may sign the
   announcement so that the destination PE, East, may authenticate the
   NLRI and the Route Distinguisher (RD), , see RFC 4364 [RFC4364]
   Section 4.3.1.  Alternatively, the originating CE router may sign the
   announcement so that the destination CE router may authenticate the
   NLRI.

>> if they want to use the rpki, then, just as other rpki publishers
>> using 1918 space, they would have local trust anchors and certify the
>> private space.  see draft-ietf-sidr-ltamgmt.
> 

then they should not use rpki keying but rather their own key
infrastructure using the Key Identifier to index their KI

randy

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 17 Oct 2012 06:47:28 +0200

Hey Pranav,

Do you really believe that each 7-11 or Walmart store will be
subscribing to global RPKI or building their own key infrastructure? I
do not. It seems few orders of magnitude easier to sign advertisements
at the src/spoke and validate signature at the hub site by the same
very network admin residing in the enterprise hub location. That is
something we should define in BGP for VPNs and not trying to reuse
origin validation concept which works well (for what it is designed to
do) in the Internet case.

Btw ,,, I do not buy any "trusted" ASBR business ;)

Best,
R.

On Tue, Oct 16, 2012 at 11:02 PM, Pranav Mehta (pmehta)
<[email-masked]> wrote:
> Robert,
>
> As Randy already mentioned, Draft already covers an alternate approach where originating CE would sign the announcement and it will come all the way to destination CE to authenticate.
>
> Alternately this mechanism can also help in Inter-AS scenario.  In Inter-AS scenario, originating CE can sign the announcement and a "trusted" ASBR on the Inter-AS boundary can authenticate the announcement if customer trusts one of the two ISPs.    In such scenario, ISP may use the Key identifier to find the Key associated with the VPN and send unsigned NLRI in its own network once it is authenticated at ASBR boundary.
>
> - Pranav
>
> -----Original Message-----
> From: Randy Bush [mailto:[email-masked]]
> Sent: Monday, October 15, 2012 9:10 PM
> To: Robert Raszuk
> Cc: Keyur Patel (keyupate); Pranav Mehta (pmehta); Arjun Sreekantiah (asreekan); [email-masked]; idr wg; L3VPN
> Subject: Re: [Idr] draft-ymbk-l3vpn-origination-00.txt
>
> then they should not use rpki keying but rather their own key infrastructure using the Key Identifier to index their KI
>
> randy

---

From: "Pranav Mehta (pmehta)" <[email-masked]>
Date: Tue, 16 Oct 2012 21:02:46 +0000

Robert,

- Pranav

-----Original Message-----
From: Randy Bush [mailto:[email-masked]] 
Sent: Monday, October 15, 2012 9:10 PM
To: Robert Raszuk
Cc: Keyur Patel (keyupate); Pranav Mehta (pmehta); Arjun Sreekantiah (asreekan); [email-masked]; idr wg; L3VPN
Subject: Re: [Idr] draft-ymbk-l3vpn-origination-00.txt

randy

---

From: "Pranav Mehta (pmehta)" <[email-masked]>
Date: Wed, 17 Oct 2012 17:25:18 +0000

Hi Robert,

Thanks for your feedback.  My comments inline.. #P#

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Tuesday, October 16, 2012 9:47 PM
To: Pranav Mehta (pmehta)
Cc: Randy Bush; Keyur Patel (keyupate); Arjun Sreekantiah (asreekan); [email-masked]; idr wg; L3VPN
Subject: Re: [Idr] draft-ymbk-l3vpn-origination-00.txt

Hey Pranav,

Do you really believe that each 7-11 or Walmart store will be subscribing to global RPKI or building their own key infrastructure? I do not. It seems few orders of magnitude easier to sign advertisements at the src/spoke and validate signature at the hub site by the same very network admin residing in the enterprise hub location. That is something we should define in BGP for VPNs and not trying to reuse origin validation concept which works well (for what it is designed to
do) in the Internet case.

#P# I don't think 7-11/Walmart will be subscribing to global RPKI or even build their own infrastructure.  RPKI makes it easier to distribute the key but the end CE can be configured to use a static Key and this draft doesn't preclude provisioning using static configuration.  As far as all the sites belong to same network admin, same key can be provisioned on all the sites and in such case we don't need to get RPKI infrastructure involved.  If it's not clear from the draft, we can definitely change the wording to clarify this.

#P#
In most of the cases I agree that this asymmetric solution might not be preferred but think about a scenario where a VPN has few sites connected via non-trusted provided and most of the other (may be in thousands) sites are connected to a trusted provider.  Instead of upgrading all these sites to generated signed NLRIs the VPN can choose to just add the authentication at the ASBR boundary to protect prefix origination from un-trusted network.  The goal of this draft is to allow the flexibility by adding Key Identifier so that VPN is not forced to upgrade all the sites under this scenario.  

Thanks,
-- Pranav