netdev - Question: AF-Independence of ECN (was [PATCH 0/4] inet6: minor cleanups)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20090722201731.GA8877@gerrit.erg.abdn.ac.uk>
Date:	Wed, 22 Jul 2009 22:17:31 +0200
From:	Gerrit Renker <gerrit@....abdn.ac.uk>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org
Subject: Question: AF-Independence of ECN (was [PATCH 0/4] inet6: minor
	cleanups)

Thank you for reviewing the patches.

| > Patch #4: Finds that RT_TOS() redefines IPTOS_TOS().
| 
| This macro probably exists so that if the ipv4 route cache entry TOS
| representation changes compared to IPTOS_TOS(), we would simply have
| to change the definition of this macro.
| 
| Just because they happen to be the same now is no reason to kill off
| this macro I think.
| 
| I'm not applying this either.
| 
These patches are a byproduct of studying the code. I think it is better to
post the question I am trying to resolve, before discussing any more patches.
I hope that there will be some input and/or discussion.

The problem is that
 * IPv4 TOS and IPv6 Traffic Class have identical semantics
   - the DiffServ bits 0..5 due to RFC 2474,
   - the 'CU'/ECN bits 6,7  due to RFC 3168.
 * in the code this is currently handled AF-dependent:
   - as inet_sk's    "tos"    field,
   - as ipv6_pinfo's "tclass" field.

There are already three existing Linux transport protocols affected by
the AF-dependence of ECN:
 * TCPv4 supports ECN, but TCPv6 currently does not;
 * SCTP achieves ECN support for v4 and v6 only with difficulties:
   - it uses a function pointer 'ecn_capable', which calls wrappers around
   - INET_ECN_xmit (sctp_v4_ecn_capable)
   - modification of inet6_sk(sk)->tclass (sctp_v6_ecn_capable)
 * DCCP ECN is not supported yet, but a working patch set exists.

So the whole point is: to achieve AF-independent ECN/DiffServ support, 
I was using an ugly hack to work around the existing AF-dependence:

  #define IP6_ECN_flow_xmit(sk, label) do {                               \
  -       if (INET_ECN_is_capable(inet6_sk(sk)->tclass))                  \
  -               (label) |= htonl(INET_ECN_ECT_0 << 20);                 \
  +       IP6_ECN_flow_init(label);                                       \
  +       (label) |= htonl((inet_sk(sk)->tos & INET_ECN_MASK) << 20);     \
       } while (0)

Realising that 
 * this is so ugly that I don't want to submit it (it has been the reason for
   several patches sitting idly for a couple of months), and 
 * finding that other transport protocols are facing a similar situation,

I am interested in solving the problem so that 
 (a) the DCCP code becomes usable and 
 (b) other transport protocols might benefit from a more generic solution.

My question:
 * is there support for an AF-independent use of ECN/DiffServ field?
 * what needs to be considered other than a good understanding of the code:
   - are there possible breakages,
   - legacy code or,
   - anything else that would prevent this?

Gerrit
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html