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

[Toerless Eckert <[e-mail]>]

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.

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

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.

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. 

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 ?

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...

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]