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" ? > 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. > 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. > 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. > 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. > 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. > 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. 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. > 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. Best regards, R.
