Thanks Alissa, I’m speaking for several of the authors of this draft, we appreciate the suggestion and agree that the security related concerns be addressed in the standard track documents for SRv6 vs this one.
Stewart, I’ll send a response for the rest of the comments shortly. Thanks, Darren On 2017-12-13, 1:46 PM, "spring on behalf of Alissa Cooper" <[email protected] on behalf of [email protected]> wrote: Stewart, thanks for your review. I agree with your concerns around the trust model, but I think the underlying issue is with the standards-track specifications (architecture and the v6 header definition), not with this use case document. I did see a response from Mark on your question about homenet. I would encourage the authors to take a look at the remainder of your comments to see if there are associated changes to be made to the document. Thanks, Alissa > On Nov 30, 2017, at 5:47 PM, Stewart Bryant <[email protected]> wrote: > > Reviewer: Stewart Bryant > Review result: Not Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-spring-ipv6-use-cases-11 > Reviewer: Stewart Bryant > Review Date: 2017-11-30 > IETF LC End Date: 2017-05-04 > IESG Telechat date: 2017-12-14 > > Summary: The document has clearly been improved by the removal of the MPLS > text. It is now quite a short draft. However a number of major issues appear to > remain. > > Major issues: > > The homenet section calls up an enterprise related draft, but none of the > homenet drafts. As I understand it homenet also supports source-destination > routeing. Is the use case really the home environment? If so there really needs > to be text explaining why the apparently competing solution is needed. If the > use case is the Enterprise environment perhaps the section name should be > changed. > > The authors did not address my question from the previous review concerning how > the necessary routing information is provided given that the homenet WG are > using a distance vector routing protocol. > > There seems to be an outstanding comment concerning the text > > "Information included in the SPRING header, whether imposed by the > end-host itself, a customer edge router, or within the access network > of the ISP, may be of use at the far ends of the data communication > as well. For example, an application running on an end-host with > application-support in a data center can utilize the SPRING header as > a channel to include information that affects its treatment within > the data center itself, allowing for application-level steering and > load-balancing without relying upon implicit application > classification techniques at the data-center edge. Further, as more > and more application traffic is encrypted, the ability to extract > (and include in the SPRING header) just enough information to enable > the network and data center to load-balance and steer traffic > appropriately becomes more and more important." > > SB> However there is a trust issue with sharing information in this way > SB> and it was a breach of trust that caused the source routing feature > SB> to be removed from IPv6 in the first place. > SB> > SB> For this to be a valid use case I think you need to address the > SB> trust and security issues to explain why they are no longer relevant > SB> or make it clear that they need to be addressed. > > I don't thing the following question was addressed from my previous review: > > The need to setup a source-based path, going through some specific > middle/intermediate points in the network may be related to different > requirements: > > SB> There needs to be some discussion on the trust model here and > SB> attack vectors associated with this proposal. > > This remains from my previous review: > > An ingress node steers a packet through > a controlled set of instructions, called segments, by prepending the > packet with SPRING header. > > SB> That is what I think it should do, but that is not the design direction > SB> of the current IPv6 proposal. The design of record modifies the > SB> IPv6 header. > > As I understand the design the it does not prepend (i.e. use an encapsulation > or a tunnel) it modifies the IPv6 header and then inserts a block of data > between the header and the transport header. > > I do not recall seeing an answer to this question from the previous review: > > In an environment, where each single cache system can be uniquely > identified by its own IPv6 address, a list containing a sequence of > the caches in a hierarchy can be built. At each node (cache) in the > list, the presence of the requested content if checked. If the > requested content is found at the cache (cache hits scenario) the > sequence ends, even if there are more nodes in the list; otherwise > next element in the list (next node/cache) is examined. > > SB> This needs some discussion on the alternative approaches: > SB> for example service function chaining and an ICN overlay. > > Minor issues: None > > Nits/editorial comments: None > > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
