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

[Tom Herbert <[e-mail]>]

On Sun, Oct 17, 2021, 3:22 PM Brian E Carpenter <[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]>
> wrote:
> >>
> >> On Sun, 17 Oct 2021, 06:36 Michael Richardson, <[e-mail]>
> wrote:
> >>>
> >>> Mark Smith <[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/
> >> 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 :-) )

Tom


> As for draft-filsfils-6man-structured-flow-label, the problems in
> https://mailarchive.ietf.org/arch/browse/ipv6/?gbt=1&index=qrTou1rjtNDDchE5yFfSN31pkMc
> remain unsolved.
>
>    Brian
>