Re: [IPv6] sendmsg() for HBH ? Re: Removing extension headers from packets (revisited)

[Tom Herbert <[e-mail]>]

On Tue, Aug 22, 2023 at 3:14 AM Toerless Eckert <[e-mail]> wrote:
>
> On Fri, Aug 18, 2023 at 07:14:22AM -0700, Tom Herbert wrote:
> > Hi Toerless,
> >
> > Yes, admin privileges are need to set EH in Linux. I have patches to fix
> > that and am planning to push them at some point.
>
> Thanks, and *sigh* I was hoping that in the last 8 years where i hadn't checked this,
> something would have improved.
>
> > Yes, fortunately OS support doesn't require and standards action.
>
> True, but i think to remember that when we asked last time, that there where
> concerns from the linux kernel community that such non-privileged access to
> extension headers would pose security risks and hence it was never enabled
> in the linux kernel.

Yes, it does require fine grained security controls.

>
> Think about an unprivileged application using a UDP socket to send an
> SRH EH. Scary ? Network operators that use SRH might think so.

Network operators don't normally trust hosts anyway, and privileged
operations are only intended to protect host resources not network
resources. This is why HMAC is defined for SRH, FAST tickets can be
authenticated by the network, etc.

>
> Think about an unprivileged IoT application using a UDP socket to send
> a RFC6554 EH. Scary ? I would think all folks knowledgable of networking
> using RPL would say it should not be scary.

It's no different than if the IoT device was hacked and the attacker
started sending spewing routing headers. It's incumbent on the network
to protect itself from untrusted sources.

>
> Aka: One and the same fundamental scheme (traffic steering info) may likely
> be seen as more or less "privileged".
>
> And i think we simply need to put more force behind the notion that extension headers
> must NOT require special privileges. Or else, we will never get easy ubiquitous
> use of them.

Yes.

>
> Privile can and should be tied to protocol if anything (ICMP(v6)) for example,
> raw IP sockets etc. But not to any TCP, SCTP, UDP, QUICK or other correctly
> per-application demultiplexable transport protocol sockets.
>
> In return, the question is what level of security requirements do extension
> headers have to have to permit such unprivileged use ?

IIRC, the patches allowed the admin to enable HbH and destination
options by option number.

>
> To me, its practically, that extension headers MUST NOT impact / be impacted
> by traffic not matching their 5-tuple transport connection/transaction.
>
> This is a simple security requirement, but i am not sure it was written down anywhere.
> Is it (i don't know all relevant text).
>
> Do all our EH meet this security requirement ? aka: no traffic monitoring
> extension heaeder collection more than 5-tuple info ? I hope we do...
>
I think what you're saying is that correct processing of extension
headers cannot depend on headers or data that follow the extension
headers, nor on any external context or and state. AFAIK, this is true
for currently defined extension headers and options within extension
headers.

One possible exception is that we might want to process Destination
Options before a Routing Header differently than Destination Options
after a Routing Header or Destination Options without a Routing
Header. In the recommended EH ordering of RFC8200, a Routing Header
immediately follows Destination Options, so if the next header of
DestOpts is 43 then that is a strong signal that those are Destination
Options before the Routing Header and this determination is made just
by inspecting the DestOpts header. If this signal is used to DestOpts
processed differently it's probably debatable whether this violates
the rule about processing being dependent on downstream headers.

Tom


> Cheers
>     Toerless
>
> >
> > Tom
> >
> >
> > > Cheers
> > >     Toerless
> > >
> > > On Mon, Aug 14, 2023 at 01:12:40PM -0700, Tom Herbert wrote:
> > > > Hi 6man,
> > > >
> > > > I know this topic of removing extension headers has been brought up
> > > > before, but I think in light of some emerging use cases it might be
> > > > worth revisiting.
> > > >
> > > > draft-herbert-fast and draft-media-hdr-wireless describe host to
> > > > network signaling. Both of these use Hop-by-Hop extension headers
> > > > (draft-media-hdr-wireless currently specifies using UDP options, but
> > > > could be HBH). A common attribute of these is that the information in
> > > > Hop-by-Hop options is only relevant in the local network of the
> > > > source. More specifically, it might only be relevant to the first hop
> > > > router in a provider network to process the options. After processing
> > > > by that router, the Hop-by-Hop option just along for the ride, no
> > > > other nodes in the path care about it and the end node probably
> > > > doesn't care either.
> > > >
> > > > Segment routing has a similar property. Once the final segment is set
> > > > in the Destination Address, the segment routing header contains no
> > > > useful information to downstream nodes.
> > > >
> > > > In both these cases, as long as the destination is in the same domain
> > > > as the sender, we expect things to work. For EH it's a statement of
> > > > practicality because of perceived drop rates on the Internet, for
> > > > segment routing it's inherent in the design for segment routing
> > > > domains. So this raises the question, what happens if a sender sends
> > > > to a destination out of its local domain and still wants services
> > > > applied to packets while they're in the local domain, or what if
> > > > segment routing is used to route a packet to an egress point in the
> > > > segment routing domain that then traverses the Internet.
> > > >
> > > > Could it be acceptable for routers to remove HBH EH or routing header
> > > > EH when a packet exits a limited domain? I realize this is contrary to
> > > > RFC8200 and might be considered an architectural abomination, but on
> > > > the other hand this might be a practical way to improve the
> > > > deployability of extension headers without any material adverse side
> > > > effects (other than packets being dropped which might happen anyway if
> > > > packets with EH escaped the limited domain).
> > > >
> > > > Comments?
> > > >
> > > > Thanks,
> > > > Tom
> > > >
> > > > --------------------------------------------------------------------
> > > > IETF IPv6 working group mailing list
> > > > [e-mail]
> > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > > --------------------------------------------------------------------
> > >
> > > --
> > > ---
> > > [e-mail]
> > >
>
> --
> ---
> [e-mail]