Re: [spring] All IPv6 fields are now mutable (Re: Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression)

[Brian E Carpenter <[e-mail]>]

On 18-Oct-21 13:35, Tom Herbert wrote:
> 
> 
> On Sun, Oct 17, 2021, 3:22 PM Brian E Carpenter <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     On 18-Oct-21 09:39, Tom Herbert wrote:
>     > On Sat, Oct 16, 2021 at 4:59 PM Mark Smith <[e-mail] <mailto:[e-mail]>> wrote:
>     >>
>     >> On Sun, 17 Oct 2021, 06:36 Michael Richardson, <[e-mail] 
<mailto:[e-mail]>> wrote:
>     >>>
>     >>> Mark Smith <[e-mail] <mailto:[e-mail]>> 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
>