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 protected]> wrote: >> 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. _______________________________________________ Idr mailing list [email protected] https://www.ietf.org/mailman/listinfo/idr
