Robert, More replies below. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Robert Raszuk Sent: Tuesday, October 23, 2012 3:01 PM To: Arjun Sreekantiah (asreekan) Cc: Randy Bush; idr wg; L3VPN; [email protected] Subject: Re: [Idr] draft-ymbk-l3vpn-origination-00.txt
>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. [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. > 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 >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. >> 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. >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. >> 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. >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. > 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. >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. >> 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. >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.
