On 18-Oct-21 13:35, Tom Herbert wrote: > > > On Sun, Oct 17, 2021, 3:22 PM Brian E Carpenter <brian.e.carpen...@gmail.com > <mailto:brian.e.carpen...@gmail.com>> wrote: > > On 18-Oct-21 09:39, Tom Herbert wrote: > > On Sat, Oct 16, 2021 at 4:59 PM Mark Smith <markzzzsm...@gmail.com > <mailto:markzzzsm...@gmail.com>> wrote: > >> > >> On Sun, 17 Oct 2021, 06:36 Michael Richardson, <m...@sandelman.ca <mailto:m...@sandelman.ca>> wrote: > >>> > >>> Mark Smith <markzzzsm...@gmail.com <mailto:markzzzsm...@gmail.com>> > wrote: > >>> > In fight changing DAs also will break AH protection of the IPv6 > header. > >>> > >>> AH is dead. It's been dead for decades. > >>> I say this as an IPsec enthusiast who wishes this wasn't true. > >>> But it is. > >> > >> > >> Then all IPv6 field immutability while the packet is in flight is also > dead. > >> > >> "Controlled domain" == redefine any field, field semantics, and field > >> processing we like in an existing protocol, yet claim we're still > >> using the original protocol. > >> > >> That has been tacitly endorsed via standards track RFC8986. The Next > >> Header field is not supposed to be modified in flight per internet > >> standard RFC8200, yet standards track RFC8986 specifies the behaviour > >> via PSP. > >> > >> This SRH compression ID is redefining the IPv6 DA field semantics. It > >> encodes multiple network hop destinations in the single IPv6 > >> destination address field. > >> > >> Structured Flow Label - > >> > https://datatracker.ietf.org/doc/draft-filsfils-6man-structured-flow-label/ > <https://datatracker.ietf.org/doc/draft-filsfils-6man-structured-flow-label/> > >> is redefining the IPv6 flow label field. > >> > >> This will be an operational nightmare in the future, when there are > >> multiple applicable RFCs that conflict with each other. I don't want > >> to have to spend time getting into arguments with vendors about which > >> protocol variant RFC their implementation should or shouldn't have to > >> comply with while I have 1000s, 10s or 100s of 1000s of customers > >> off-line. > > > > Mark, > > > > I think you might be lumping together several disparate proposals in > > your general claim that "IPv6 field immutability while the packet is > > in flight is also dead". > > > > When SRH was under discussion in 6man there was a lot of work to > > define which fields were immutable and that is described in RFC8754. > > Those definitions are sufficient to specify proper interaction between > > SRH and AH, however RFC8754 knowingly breaks AH as that handling was > > not specified. Some of us did object to that, but I suppose expediency > > to publish the protocol won out. Nevertheless, there is nothing that > > prevents someone from properly defining AH usage with SRH. > > > > As for the IPv6 destination address, it was never defined to be an > > immutable field inflight. In fact, the core operation of a routing > > header is to overwrite the destination address at each intermediate > > destination. NAT also changes the DA in flight, but there is a > > significant difference between NAT and the routing header header > > operation: when a routing header is set in a packet the sender knows > > and indicates the destination address. For the purposes of AH or > > transport checksum, both the sender and final receiver use this > > address-- there is no ambiguity and the fact that the destination > > address is mutable in flight doesn't adversely impact end to end > > protocol operations that operate on the addresses. > > > > We have seen various proposals to steal bits or redefine flow label > > fields, but IMO it's unlikely any of those will ever get consensus. > > Hosts routinely set the flow label as an unstructured value, and > > redefining flow label semantics would be a massive retroactive change > > in deployment. I would point out though, that the flow label is > > technically not immutable in flight, RFC6437 allows it to be modified > > by intermediate nodes for "only for compelling operational security > > reasons". > > Correct, because it was very clear that some firewalls were going to > clobber it whatever we wrote. So we tried to describe behaviour > that would not nullify the usefulness of the field for stateless > load balancing. > > > Brian, > > Thanks for the explanation concerning why the exception was created. For the > concern that the flow label could be used a a covert channel, was this a > hypothetical possibility or in response to some real events (sending twenty > bits at a time doesn't seem like a very effective covert channel compared to other methods :-) )
This was one of the crucial differences between RFC3967 and RFC6437. As I recall, it was started by anecdotal evidence of firewalls zapping the flow label, and then we discussed how to deal with this. For example: https://mailarchive.ietf.org/arch/msg/ipv6/0T2gPgciSq6qG-2JGBzHvBuVKb8/ It was discussed at length but (almost inevitably) without input from actual firewall vendors, I believe. Brian > > Tom > > > As for draft-filsfils-6man-structured-flow-label, the problems in > https://mailarchive.ietf.org/arch/browse/ipv6/?gbt=1&index=qrTou1rjtNDDchE5yFfSN31pkMc > > <https://mailarchive.ietf.org/arch/browse/ipv6/?gbt=1&index=qrTou1rjtNDDchE5yFfSN31pkMc> > remain unsolved. > > Brian > _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
