Re: [Int-area] New Version Notification for draft-herbert-ipv4-eh-03.txt

[Tom Herbert <[e-mail]>]

On Thu, Mar 21, 2024, 7:28 PM [e-mail] <[e-mail]>
wrote:

>
> > On Mar 21, 2024, at 7:18 PM, Tom Herbert <[e-mail]> wrote:
> >
> > On Thu, Mar 21, 2024 at 6:52 PM [e-mail]
> > <[e-mail]> wrote:
> >>
> >> On Mar 21, 2024, at 6:36 PM, Tom Herbert <[e-mail]> wrote:
> >>>
> >>> On Thu, Mar 21, 2024 at 5:38 PM [e-mail]
> >>> <[e-mail]> wrote:
> >>>>
> >>>> On Mar 21, 2024, at 8:01 AM, Tom Herbert <[e-mail]> wrote:
> >>>>
> >>>> I haven’t seen it mentioned yet (apologies if so), but there is a big
> difference between extension headers and encapsulated protocols.
> >>>>
> >>>> Extension headers - no matter how many - can each refer back to the
> base header. Same for the first encapsulated protocol.
> >>>>
> >>>> E.g.:
> >>>>
> >>>> IP1 IP2 IP3 TCP…. TCP uses a pseudo header based on IP3
> >>>> But:
> >>>> IPv6a EHb EHc TCP… TCP uses a pseudo header based on IPv6a; each of
> the EH’s can also refer back to IPv6a
> >>>>
> >>>> I see NO way to do this with any mechanism for IPv4 except options
> (whose space is limited). There’s no way to redefine protocol processing to
> ensure that information can be “Carried” forward across EHs.
> >>>>
> >>>> This seems like a show-stopper; has it been addressed?
> >>>>
> >>>>
> >>>> Joe,
> >>>>
> >>>> It already happens in IPv4. Consider the header chain IPv4-AH-TCP. In
> >>>> practice, host stacks have already accounted for this so I don't see
> >>>> this as a problem.
> >>>>
> >>>> Tom
> >>>>
> >>>>
> >>>> There’s a big difference and it relates to discussions we've had
> about UDP options.
> >>>>
> >>>> With IPsec, the assumption is “if I add it, it MUST be checked”, so
> an endpoint that doesn’t know to check would drop the packet as expected.
> >>>
> >>> Joe,
> >>>
> >>> As you know from the discussions on UDP Options, I believe that if
> >>> someone sends security information in a packet then the information
> >>> MUST be verified. It's always better to drop something you don't
> >>> understand, rather than accept it and put the user at risk for
> >>> security or data corruption.
> >>
> >> I understand; for ESP, the data is also modified and not useful.
> >> For EH, we can debate whether it’s important to *force* checks t at the
> receiver.
> >
> > Joe,
> >
> > There's nothing to debate.
>
> We can debate what IPsec requires and whether that was an appropriate
> choice.
> What it currently requires is not under debate, of course.
>
> >>
> >> But either way, there are also options that you might want a legacy
> receiver to allow, and this approach won’t do that. So it’s necessarily
> limited.
> >>
> >>>> But that means these extensions can only be useful where they MUST be
> supported; you can’t send them to (or through) legacy devices (or NATs) and
> have them work correctly.
> >>>
> >>> We can't send AH, ESP, DCCP, SCTP, GRE through NAT either. For that
> >>> matter, has any ever tested if IPv6 EH can make it through NAT. In any
> >>> case, from IPv6 data we already know that extension headers will
> >>> probably ever only be useful in limited domains, so I don't believe
> >>> NAT traversal is a showstopper.
> >>
> >> Whether EH *does* make it through any NAT is different than whether it
> could. It could - there’s enough information.
> >>
> >> This approach for IPv4 cannot - because it doesn’t change the base
> protocol.
> >
> > IPv4 works the same way as IPv6.
>
> Not for EHs. An existing IPv6 NAT can skip over EHs because they were
> defined when IPv6 was defined; an existing IPv4 NAT cannot.
>
> >>>> In which case, rather than this mechanism, you could as easily do
> basically ANYTHING else too - because it’s no longer a matter of backward
> compatibility.
> >>>
> >>> But isn't that the *whole point* of an extensible protocol like IP?...
> >>
> >> My point is that you’re NOT extending IP.
> >
> > I guess it depends on what you mean by "extending". To me "extension"
> > headers are a mechanism to "extend" a protocol.
>
> Yes, but you’re not extending IP. You’re running a protocol inside IP.
> These are “pre transport extensions” (or see next section).
>
> >> This is just a protocol layer like any other. It doesn’t really have
> any relation to IP. IPv4 endpoints don’t know how to skip them if they
> don’t support or understand them.
> >
> > Correct. That's the benefit of extension headers compared to IP options.
>
> A protocol inside IP that has no relation to IP is just a transport
> protocol.
>
> >>> to allow innovation and extensions to be able to solve problems that
> >>> would never have been foreseen when the protocol was first developed.
> >>> And not everything we do can be backwards compatible, if that were a
> >>> requirement IETF never could have created IPv6.
> >>
> >> IPv6 is not an extension to IPv4.
> >>
> >> My point is that this proposal isn’t either. I’m not saying it’s not
> useful, but it’s not particularly tied to IP any more than any other
> protocol layer is or would be, AFAICT.
> >
> > Right. So operationally it's no different than introducing any other
> > new protocol in the network.
>
> New endpoint, basically transport protocol, yes.
>
> So it’s not an extension to IP. Just another transport.
>
> >> So let’s say it’s useful and let's say there are two places you would
> want to use it:
> >>
> >> - for a protocol that legacy receivers silently ignore
> >>        that won’t work
> >>
> >> - for a protocol that upgraded receivers will support
> >>        the will work - but at that point, ANY solution above IPv4 would
> work too - e.g., redefining TCP to have a “pre header” with the same effect.
> >
> > But it doesn't. Extension headers are the *only* correct mechanism to
> > send ancillary network layer information that works with any transport
> > protocol and allows intermediate nodes to robustly read and
> > potentially modify the information.
>
> You’ve just described a transport protocol that the intermediate nodes
> know.
>

Joe,

A transport protocol doesn't meet the requirements. They don't work with
any transport protocol other than themselves, and intermediate nodes cannot
robustly parse transport headers  This has to be L3 protocol.

Tom


> > The only possible alternative I
> > know of is IP options, but as Brian mentioned those have been
> > considered dead for over twenty years. (if there's an other
> > alternative that I'm missing please point it out)
>
> This is just a transport protocol.
>
> The problem with a new transport is exactly the same as the problem here -
> that there’s no way to make it silently backward compatible with legacy
> endpoints.
>
> That’s not the case for IPv6 options because the option mechanism was
> defined at the time IPv6 was. But that’s not the case for IPv4.
>
> Joe