On Thu, Mar 21, 2024 at 6:52 PM [email protected] <[email protected]> wrote: > > On Mar 21, 2024, at 6:36 PM, Tom Herbert <[email protected]> wrote: > > > > On Thu, Mar 21, 2024 at 5:38 PM [email protected] > > <[email protected]> wrote: > >> > >> On Mar 21, 2024, at 8:01 AM, Tom Herbert <[email protected]> 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. The requirements are well established. If a host receives an AH or ESP Header it MUST either validate ICV or decrypt, or drop the packet. If a host receives a Frag Header it MUST reassemble the packet before processing after the Frag Header. If a host receives a Routing Header it must process it and can only continue past the Header when segments left equals zero. If a host receives an unrecognized Hop-by-Hop or Destination option and the high order two bits of the option type are nonzero then the host MUST discard the packet. > > 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. If some device supports IPv6 EH through NAT then they could support IPv4. In fact, there's a lot of implementation to be shared. > > >> > >> 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. > > 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. > > > 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. > > 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. 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) Tom > > Joe > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
