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

From: Randy Bush <[email-masked]>
Date: Wed, 17 Oct 2012 16:52:01 -1000

> Help me understand here that if we are talking about statically
> configured key on the CEs would it be not better to consider
> e-signature from verisign instead ?

the keys are arbitrary.  you can get ecerts from macdonalds for all the
spec cares.

randy

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 18 Oct 2012 05:15:40 +0200

> the keys are arbitrary.  you can get ecerts from macdonalds for all
 > the spec cares.

If this is so what is so novel about your draft if compared with already 
existing for over 10 years L3VPN WG below document ?

http://tools.ietf.org/html/draft-ietf-l3vpn-auth-00

?

Thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 21 Oct 2012 16:33:27 +0200

Hello,

Just noticed draft-ymbk-l3vpn-origination-01.txt ...

Few follow-up questions to new version:

1.
Section "5.2.  Provider/ASBR Based Validation/Authentication"
indicates possible validation at the ASBR. First clearly it is not
possible to do that in option C which I think the draft should
mention. In option C you could try to describe such validation on EBGP
peering VPNvX RRs.

Assuming option-B (or option-C on RRs) how do I set validation policy
(based on what value and parameter) that only some VPN customer's
routes will be subject for validation ? Same for PEs where subset of
VPN customers request validation.

Or is the draft discussing only option-A ASBRs ?

2.
How much the NLRI validation on the ASBR option B or PE helps if RTs
could have been mangled on the way and validated or not routes will
end up going to wrong VPN sites ?

Draft says: "ASBR2 is the trusted provider with whom CE1 has collaborated."

How can one validate on ASBRs (or remote PEs) in the CE based key
allocation scheme ? What happens if two VPN customers with overlaping
IP addresses will choose the same keys on their CEs ? Note that CEs
NLRI do not have notion of RDs and that ingress PEs convert IPv4 NLRIs
from CE to VPNv4 NLRIs on PEs adding RD. How can the signature be
possibly meaningful anywhere else that on the end PE's VRF or in the
end site CE ?

3.
In case of validating on the PEs or CEs how does one handle extranets
? Is the plan to share my keys with all extranet partners or use
different key per each extranet VPN - case of per CE validation ?

How would it work for PE based validation ? How would I carry
multiples keys if VPN chooses not to share his secret with some of his
extranets ?

How do you associate a L3OPA to RTs ? Is the assumption in the draft
that such validation is to happen in the VPNvX space on during/past
the import the VRFs ?

4.
How would service provider be able to inject his own prefixes into VPN
sites for offering value add services (example VoIP gateway addresses)
if customer chooses CE based validation ?

5.
How do I propagate the result of ASBR or PE based validation to the
VPN site if such (say multihomed) site is connected to SP not via BGP
but via an IGP ?

Many thx ..
R.

---

From: "Arjun Sreekantiah (asreekan)" <[email-masked]>
Date: Tue, 23 Oct 2012 18:20:09 +0000

Robert,

Answers inline...

1.
Section "5.2.  Provider/ASBR Based Validation/Authentication"
indicates possible validation at the ASBR. First clearly it is not possible to do that in option C which I think the draft should mention. In option C you could try to describe such validation on EBGP peering VPNvX RRs.

Assuming option-B (or option-C on RRs) how do I set validation policy (based on what value and parameter) that only some VPN customer's routes will be subject for validation ? Same for PEs where subset of VPN customers request validation.

Or is the draft discussing only option-A ASBRs ?
[Arjun]
The example provided is for option B ASBR. In option C, as you say the same could be performed on ebgp vpn RRs. This is meant to serve as an example illustrating usage of the scheme and not all inclusive list.
The validation policy is agreed upon between the trusted provider and the VPN customer on a per VPN basis. - This would necessarily mean all routes from that VPN will be subject to validation. Since all CEs for that VPN would be Part of the agreement, there is no need for perform validation on a subset of the routes.  We would however allow for incremental deployment in which case some of the CEs are not upgraded to support the scheme in which case the ASBR can define appropriate policy to accommodate these prefixes, this is a matter of implementation.

2.
How much the NLRI validation on the ASBR option B or PE helps if RTs could have been mangled on the way and validated or not routes will end up going to wrong VPN sites ?
[Arjun]
If the scheme  is implemented for the affected VPNs on the option B ASBR or PE , then a mangled RT will result in the route being associated with the wrong VPN and the  signature digest validation would fail  since the key identifier are unique per VPN, this way the mis-configuration of RTs is handled as well. 
Also typically,  some of the providers already perform inbound validation of the RTs today by stripping RTs received and mapping them locally to the ones used for that VPN.

Draft says: "ASBR2 is the trusted provider with whom CE1 has collaborated."
How can one validate on ASBRs (or remote PEs) in the CE based key allocation scheme ? What happens if two VPN customers with overlaping IP addresses will choose the same keys on their CEs ? Note that CEs NLRI do not have notion of RDs and that ingress PEs convert IPv4 NLRIs from CE to VPNv4 NLRIs on PEs adding RD. How can the signature be possibly meaningful anywhere else that on the end PE's VRF or in the end site CE ?
[Arjun]
Please note that we have Key Identifier defined which will be unique per VPN (can map to the vpn-id) and is also part of the signature digest. Hence in this case the  digest will be different for the VPNs with overlapping address/keys/ The validation on the ASBR/remote PE will be performed by retrieving the  key associated with the key identifier and computing the appropriate signature digest so there is not context of RD in use here.

3.
In case of validating on the PEs or CEs how does one handle extranets ? Is the plan to share my keys with all extranet partners or use different key per each extranet VPN - case of per CE validation ?
How would it work for PE based validation ? How would I carry multiples keys if VPN chooses not to share his secret with some of his extranets ?
[Arjun]
Each VPN would have a unique key identifier and associated key. You could choose to share the key and key identifier among extranet partners. Also you could choose to define separate key identifier and associated key for private and shared prefixes The private keys would not be shared with extranet partners.

How do you associate a L3OPA to RTs ? Is the assumption in the draft that such validation is to happen in the VPNvX space on during/past the import the VRFs ?
[Arjun]
For PE based validation, the validation will happen during the import of  RTs using context of key identifiers defined for that VPN.

4.
How would service provider be able to inject his own prefixes into VPN sites for offering value add services (example VoIP gateway addresses) if customer chooses CE based validation ?
[Arjun]
In the example provided the provider is serving as transit and not sourcing any routes. If the service provider (SP) is injecting the routes then it makes sense to have the SP PE also being part of the scheme by computing the signature checksum on behalf of the CE. Here it makes sense to define a key identifier per VPN on the PEs/CEs and generate the signature digest on the VPN routes on the PE with the end CEs performing the validation as before.

5.
How do I propagate the result of ASBR or PE based validation to the VPN site if such (say multihomed) site is connected to SP not via BGP but via an IGP ?
[Arjun]
This is a BGP based scheme. One option you have in the scenario mentioned  above is to have the PE generate the signature digest on behalf of the VPN site by configuring the key identifier per VPN on the PE and the validation would be done on the PE.

Thanks
Arjun

On Thu, Oct 18, 2012 at 5:15 AM, Robert Raszuk <[email-masked]> wrote:
> If this is so what is so novel about your draft if compared with 
> already existing for over 10 years L3VPN WG below document ?
>
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 24 Oct 2012 00:00:36 +0200

Hi Arjun,

> The validation policy is agreed upon between the trusted provider and the VPN
> customer on a per VPN basis.

Let's observe that option B ASBR you are referring to has no per VPN
basis notion. What you are describing is not possible to accomplish as
said ASBR would have to perform the validation based on the subset of
VPNv4 or VPNv6 routes based on the local RT import.

Unless ASBR option B is also acting as local PE or is configured with
A+B or option D there is no per VRF import based on the RTs.

Please provide a sample configuration how are you going to enable
L3VPN origin validation on ASBR " on a per VPN basis" ?

> If the scheme  is implemented for the affected VPNs on the option B ASBR or PE ,
> then a mangled RT will result in the route being associated with the wrong VPN

RTs do not associate routes to VPNs on the ASBRs.

> and the  signature digest validation would fail  since the key identifier are unique per
> VPN, this way the mis-configuration of RTs is handled as well.

The draft clearly provides the option to assign such signature on the
CE. CEs are owned by customers and they may choose the same key id.

> Also typically,  some of the providers already perform inbound validation of the RTs
> today by stripping RTs received and mapping them locally to the ones used for that
> VPN.

RT mapping if at all used in production other then via option D does
not solve anything.

> Please note that we have Key Identifier defined which will be unique per VPN (can map to the vpn-id) and is also part of the signature digest.

The draft clearly provides the option to assign such signature on the
CE. CEs are owned by customers and they may choose the same key id and
the same prefix.

> Hence in this case the  digest will be different for the VPNs with overlapping
> address/keys/ The validation on the ASBR/remote PE will be performed by retrieving
> the  key associated with the key identifier and computing the appropriate signature
> digest so there is not context of RD in use here.

On ASBR and global VPNv4 table RD is part of the NLRI.

> Each VPN would have a unique key identifier and associated key. You could
> choose to share the key and key identifier among extranet partners. Also you could
> choose to define separate key identifier and associated key for private and shared
> prefixes The private keys would not be shared with extranet partners.

Please provide encoding to carry more then one key with the prefix so
my keys are not shared with my extranet partners.

> In the example provided the provider is serving as transit and not sourcing any
> routes.

Then such example is not that practical.

> If the service provider (SP) is injecting the routes then it makes sense to have the
> SP PE also being part of the scheme by computing the signature checksum on
> behalf of the CE.

The question was clearly for CE based validation.

> This is a BGP based scheme.

That's the problem with this scheme. L3VPN are not only BGP based on
the CE-CE basis.

Origin validation could be made to work for Internet (assuming there
is interest) however as documented it has number of architectural and
practical problems to solve for L3VPN architecture.

Best regards,
R.

---

From: "Arjun Sreekantiah (asreekan)" <[email-masked]>
Date: Wed, 24 Oct 2012 01:27:54 +0000

Robert,
More replies below.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Tuesday, October 23, 2012 3:01 PM
To: Arjun Sreekantiah (asreekan)
Cc: Randy Bush; idr wg; L3VPN; [email-masked]
Subject: Re: [Idr] draft-ymbk-l3vpn-origination-00.txt

>> The validation policy is agreed upon between the trusted provider and 
>> the VPN customer on a per VPN basis.
>
>Let's observe that option B ASBR you are referring to has no per VPN basis notion. What you are describing is not possible to accomplish as said ASBR would have to perform the validation based on the subset of

[Arjun]
The ASBR can still perform the validation based on configured key-id and associated key without having to perform any import operation.  As explained before you can have the key-id map to a vpn-id and only the key-id and associated keys need to be defined on the ASBR.

>Please provide a sample configuration how are you going to enable L3VPN origin validation on ASBR " on a per VPN basis" ?
[Arjun]
We will pass it you as soon as we have a implementation ready.

>> If the scheme  is implemented for the affected VPNs on the option B 
>> ASBR or PE , then a mangled RT will result in the route being 
>> associated with the wrong VPN

>RTs do not associate routes to VPNs on the ASBRs.
[Arjun]
We are not suggesting using RTs to do that in this scheme, just use the context of the key identifier to retrieve the associated key and verify the signature digest.

>> and the  signature digest validation would fail  since the key 
>> identifier are unique per VPN, this way the mis-configuration of RTs is handled as well.

>The draft clearly provides the option to assign such signature on the CE. CEs are owned by customers and they may choose the same key id.
[Arjun]
For the provider validation case, the CE will still need to agree upon keys and key-id with the provider and the provider can ensure uniqueness of the key-id across vpns. For the CE-CE
Case, the secret key associated with key-id is private to the CEs in that VPN  and the signature digest will be unique across CEs .

>> Also typically,  some of the providers already perform inbound 
>> validation of the RTs today by stripping RTs received and mapping them 
>> locally to the ones used for that VPN.

>RT mapping if at all used in production other then via option D does not solve anything.
[Arjun]
It ensures improper RTs are discarded.

>> How can one validate on ASBRs (or remote PEs) in the CE based key allocation scheme ? What happens if two VPN customers with overlaping IP addresses will choose the same keys on their CEs ? Note that >>CEs NLRI do not have notion of RDs and that ingress PEs convert IPv4 NLRIs from CE to VPNv4 NLRIs on PEs adding RD. How can the signature be possibly meaningful anywhere else that on the end PE's VRF or >>in the end site CE ?
> >[Arjun]

>The draft clearly provides the option to assign such signature on the CE. CEs are owned by customers and they may choose the same key id and the same prefix.
[Arjun]
See above. The secret key to generate the digest is still private to the CEs in that VPN.

>> Hence in this case the  digest will be different for the VPNs with 
>> overlapping address/keys/ The validation on the ASBR/remote PE will be 
>> performed by retrieving the  key associated with the key identifier 
>> and computing the appropriate signature digest so there is not context of RD in use here.

>On ASBR and global VPNv4 table RD is part of the NLRI.
[Arjun]
Yes but I do not see what your point is here.

>> Each VPN would have a unique key identifier and associated key. You 
>> could choose to share the key and key identifier among extranet 
>> partners. Also you could choose to define separate key identifier and 
>> associated key for private and shared prefixes The private keys would not be shared with extranet partners.

>Please provide encoding to carry more then one key with the prefix so my keys are not shared with my extranet partners.
[Arjun]
There is no need to for encoding more than one key with a single prefix here. The prefix is either private when it is associated with a private key or shared for which it has a shared key defined.

>> In the example provided the provider is serving as transit and not 
>> sourcing any routes.
>> If the service provider (SP) is injecting the routes then it makes 
> >sense to have the SP PE also being part of the scheme by computing the 
> >signature checksum on behalf of the CE.

>The question was clearly for CE based validation.
[Arjun]
In this case, The PE can sign the prefixes in this case using locally and defined key ID and key and share it with the CEs.

>That's the problem with this scheme. L3VPN are not only BGP based on the CE-CE basis.

>Origin validation could be made to work for Internet (assuming there is interest) however as documented it has number of architectural and practical problems to solve for L3VPN architecture.
[Arjun]
I would disagree - we can work out a solution in the l3vpn case as well - suggest we sync up at the upcoming meeting  in Atlanta if you have further concerns.

Thanks
Arjun

Best regards,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 24 Oct 2012 09:27:31 +0200

> [Arjun]
> The ASBR can still perform the validation based on configured key-id and associated key
> without having to perform any import operation.  As explained before you can have the key-
> id map to a vpn-id and only the key-id and associated keys need to be defined on the
> ASBR.

There is no such a thing in VPNv4/v6 advertisement like "vpn-id".

> We are not suggesting using RTs to do that in this scheme, just use the context of the
> key identifier to retrieve the associated key and verify the signature digest.

That is precisely the main issue with your proposal. You would be much
better off with adding RT validation (*based on the very same scheme
as you proposed for NLRI validation in this draft*)

Thx,
R.