Re: Re: HBH Option Header Configuration (draft-hinden-6man-hbh-processing)

["[e-mail]" <[e-mail]>]

Add one more co-existing policy:
1) rfc2460 implementations, which aim to process all HbH
2) Deployed reality which drops HbH
3) RFC8200 implementations -- which ignore HbH unless required
4) draft-hinden-6man-hbh-processing, which would only process part of it.
5) draft-ietf-opsec-ipv6-eh-filtering, in which the processing policy for the packets with HBH EH is DROP or IGNORE

Best Regards,
Zhenqiang Li


[e-mail]
 
From: Fernando Gont
Date: 2021-06-10 01:12
To: [e-mail]; [e-mail]
Subject: Re: HBH Option Header Configuration (draft-hinden-6man-hbh-processing)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
 
Hello, Bob,
 
On Tue, 2021-06-08 at 13:06 -0700, Bob Hinden wrote:
> Gorry and I are going over the comments received on draft-hinden-
> 6man-hbh-processing-01, thanks very much for your comments, it is
> very helpful.  We are working on respond to them.
> 
> One issue that is common to several questions is what does
> configuration mean regarding HBH Option headers.    Our draft and in
> hindsight RFC8200 is not clear what this means.   The note in Section
> 4 of RFC8200:
> 
>   NOTE: While [RFC2460] required that all nodes must examine and
>   process the Hop-by-Hop Options header, it is now expected that
> nodes
>   along a packet's delivery path only examine and process the
>   Hop-by-Hop Options header if explicitly configured to do so.
> 
> This can be interpreted to mean a configuration flag
> allowing/disallowing processing of a HBH Option Header, or specific
> configuration for each HBH Option type.
 
IMO, the above meanns "unless you have been explicitly configured
otherwise, feel free to skip/ignore the HbH header".
 
That relieves intermmediate systems from having to process HbH header,
which in some cases might be unnfeasible.
 
 
 
> 
draft-hinden-6man-hbh-processing-01 says:
> 
>   This document updates [RFC8200] that a
>   node MUST process the first Option in the Hop-by-Hop Header in the
>   Fast Path and MAY process additional Hop-by-Hop Options if
> configured
>   to do so.
> 
 
IMO, it's hard to enforce that requirement -- if at all possible.
 
1) You're assuming there is a fast-path -- maybe there isn't such a
thing.
 
2) What if there are multiple HbH?
 
3) What about the option size? e.g., if the first option is, say 512
bytes long, maybe you just can't do that.
 
4) If processing other options is a MAY, is there any point in
supporting multiple options in HbH?
 
 
 
> Several people asked if we are proposing to remove the ability to not
> process the HBH Option Header.
> 
> We have discussed this and conclude that yes, we are proposing to
> require all nodes to examine and process the first HBH Option in the
> Fast Path.   Not just drop packets with HBH Option Headers.  This
> change needs to be made clearer in the draft.
 
While other might disagree, even if the IETF were to manage to progress
this to an RFC, for the reasons specified above I really doubt this
would have any impact on real devices.
 
OTOH, we'd have a bunsh of things co-existing:
 
1) rfc2460 implementations, which aim to process all HbH
2) Deployed reality which drops HbH
3) RFC8200 implementations -- which ignore HbH unless required
4) draft-hinden-6man-hbh-processing, which would only process part of
   it.
 
 
If I had any reason for even thinking about using HbH options, the
above would certainly drive me away of that.
 
 
 
> We do note that per option configuration could be set to not support
> any options, that would be allowed, but it would require a router to
> follow the two high order bits in the Option type that control if the
> packet should be dropped or forwarded for at least the first option,
> and any other options that it was configured to support.
 
At least for infrastructure devices, that's not doable.
 
I find it very hard for an operator to even consider processing HbH
options (*), unless they have a very specific requirement to do so (say
RSVP).
 
(*) Some might extrapolate that to EHs in general :-) , but I won't get
into that. ;-)
 
Thanks,
- -- 
Fernando Gont
Director of Information Security
EdgeUno, Inc.
PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531
 
 
 
 
-----BEGIN PGP SIGNATURE-----
 
iQFOBAEBCgA4FiEE371j47JIrnnFmK8j667aAwZEFTEFAmDA9n8aHGZlcm5hbmRv
LmdvbnRAZWRnZXVuby5jb20ACgkQ667aAwZEFTFGiQgAors1BHXz812gxmQzhv5H
FUzC7+2gUeLJtgWNUamnrPUdZbMSvymYqRWRPvdviTklSJqTvGuthBgZBaEtJjDz
i3QUcqjC0AFhVVOzXolfofO4s0gXSfarrl99BdOh3LwFGpXIOZJzKSTga8XvYTaC
FywEDrek4+HQVNntcMOcF8lcn0RD3LrvU0NNYODoOGVXcdcMWroVujPPwleXJ9PJ
ajgror9IR8QvqvPPSLJbxS0a2xnZb692YWJYCWG+lJoA7jyM1Hvex4C4ow5CbDQw
v1U0+Yk0/Z9V9EriI8dwNB2WSwFw3geOq2pQaoJo02SYZX4TsbVeVThx6rT8SHD9
uQ==
=7v0L
-----END PGP SIGNATURE-----
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------