|
Response inline [Ron]
---------------------------------------
Adrian and Ron,
Thank you very much for the quick responses. Please see my additional comments and some questions inserted below: Linda
---------------------------------------
Juniper Business Use Only Sent: Tuesday, February 4, 2025 11:10 AM To: 'Ron Bonica' <rbonica=40juniper.net@xxxxxxxxxxxxxx>; gen-art@xxxxxxxx; Linda Dunbar <linda.dunbar@xxxxxxxxxxxxx> Cc: draft-ietf-6man-vpn-dest-opt.all@xxxxxxxx; ipv6@xxxxxxxx; last-call@xxxxxxxx Subject: RE: [IPv6]Re: Genart last call review of draft-ietf-6man-vpn-dest-opt-01 I concur with Ron while partly agreeing with Linda. "IPv6 Destination Options are typically meant for end-host processing" Exactly! And in a VPN tunnel, the end-host is the end of the tunnel: the node identified by the packet's destination address. This may very well (erm, nearly always?) be a PE in the case of VPN tunnels. [Linda] Do you assume that the network between ingress and egress is VPN network? if not, the IPv6 packet with the VPN Service Option would be forwarded hop-by-hop as regular IPv6 traffic. Correct?
[Ron] The network that connects the two PEs has no requirements other than the ability to carry IPv6. For example, the network can be:
So, in some cases the IPv6 packet will be forwarded hop-by -hop through the provider network and in other cases it will not. It doesn't matter because IPv6 VPN Destination option is only processed by the two PEs.
Are you asking because you don't think that the packet will make it from PE to PE if it is forwarded hop-by-hop through the provider network. I don't think that this is the case.
"Many IPv6 deployments drop packets with extension headers, particularly in transit networks." Indeed, and if they do this (and everything else that uses extension headers) will fail. I guess that includes SRv6 ;-) [Linda] The key difference is that SRv6 typically operates within SRv6-enabled networks, which have seen significant industry adoption, and operators have adapted to ensure its usability. However, the same cannot necessarily be said for all use cases, including this proposed VPN Service Option. Have you considered mitigations or operational guidance to address the known deployment challenges caused by extension header filtering in transit networks?
[Ron] Please revisit Section 7, Security Consideration. The IPv6 VPN Destination Option can operate in a limited domain, just like SRv6.It also can be protected by cryptographic methods (e.g., the IPv6 Authentication Option). Both are not required. Just one
or the other.
Section 7 also describes ACLs that must be deployed to operate in a limited domain. Section 9 requires experimenters to report on how well these ACLs worked.
Also, your request for a comparison with SRv6 is beyond the scope of this document. If published, this document will be an EXPERIMNTAL RFC. Its goal is to describe an experiment that will test the feasibility of a technology. If the experiment succeeds, someone
can have a longer discussion about who should deploy which technology.
I see some use-cases where each is preferable. But that's not a discussion for today.
"There is a security risk of VPN boundaries being breached if an attacker injects a packet with a forged VPN Service Option." It's almost as if the Security Considerations section should discuss this. Oh, wait! The challenge of "tunnel security" is fundamental to all VPN deployments regardless of technology. The key solution has been two-fold 1. Secure the network edges so that packets cannot enter the network and join the tunnel mid-way 2. Use end-to-end security on the tunnel [Linda] I understand that tunnel security is a general VPN concern, but my point is about whether the specific risk of injecting a forged VPN Service Option is sufficiently mitigated in this proposal. The security considerations mention AH and ESP, but are these mandatory, and what happens in deployments where they are not enforced? Could we clarify this in the document?
[Ron] Linda, please revisit Section 7, Security Considerations, and see my comments above.
"The document does not clearly explain why this approach is preferable to SRv6 or MPLS-over-IPv6" Well, I think the second approach is covered by the note that the MPLS-based mechanism 'cannot be deployed where one or both of the PEs does not support MPLS.' That might not be the case with modern PE routers, but is likely to be the case with server-based PE implementations (such as virtual routers in a DC). As to compare and contrast with SRv6: I refuse to get drawn into a beauty contest. But by making this draft Experimental, we allow for the possibility that no one will like this idea and it will not see any experimental results. [Linda] Since SRv6 has been widely adopted, readers should understand why this approach exists alongside SRv6 rather than just stating it as an alternative. Can the document provide an objective comparison highlighting trade-offs in terms of scalability, operational complexity, and interoperability?
[Ron] Please see my comments about document scope above.
Ron - nit. Section 7 s/fo/of/ Cheers, Adrian From: Ron Bonica <rbonica=40juniper.net@xxxxxxxxxxxxxx<mailto:rbonica=40juniper.net@xxxxxxxxxxxxxx>> Sent: 04 February 2025 17:37 To: gen-art@xxxxxxxx<mailto:gen-art@xxxxxxxx>; Linda Dunbar <linda.dunbar@xxxxxxxxxxxxx<mailto:linda.dunbar@xxxxxxxxxxxxx>> Cc: draft-ietf-6man-vpn-dest-opt.all@xxxxxxxx<mailto:draft-ietf-6man-vpn-dest-opt.all@xxxxxxxx>; ipv6@xxxxxxxx<mailto:ipv6@xxxxxxxx>; last-call@xxxxxxxx<mailto:last-call@xxxxxxxx> Subject: [IPv6]Re: Genart last call review of draft-ietf-6man-vpn-dest-opt-01 Linda, I think that you are assuming the PE's are always routers. They can be hosts that support VPN. In fact, this is the most likely use-case. These days, most routers support MPLS. So, MPLS VPNs suffice. There is no need for an alternative forwarding plane. The only case where you need an alternative forwarding plane is when the PE is a server that doesn't support MPLS. [Linda] I am actually asking if the network to the End Host is VPN? Or plain IPv6?
[Ron] Please see my response above
Also, the Destination Options Header is least likely to be dropped by an intervening network. If we were to follow the reasoning that you present below, we would have to deprecate all extension headers. Ron |
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
