Re: [tcpm] Security issues of AccECN (was: RE: AccECN field order)

[Bob Briscoe <[e-mail]>]

Michael,

On 18/11/2020 05:36, Scharf, Michael wrote:
>
> Only on remark [ms2] regarding the issue of a covert channel due to 
> „forward compatibility“…
>
>         From a security perspective, it is not clear to me whether
>         allowing arbitrary unspecified bytes in a TCP option is a good
>         idea **at all**. It will be interesting to hear the opinion
>         from SEC area on that. Personally, I am not convinced that
>         this really makes sense, but I my concerns are not strong
>         enough to formally push back. I’ll leave it to others to think
>         about whether this is a bug or a feature.
>
>
>     [BB] Well, let's first try to deal with security ourselves:
>     * Octets that are explicitly declared as part of an option cannot
>     be used for a buffer overflow attack. I don't really need to, but
>     I could add the following text to the forward compatibility wording:
>         A receiver considers octets beyond those it uses, but within
>     the specified length, as if they are padding.
>     * And such octets cannot be any different from the current ability
>     of a sender to add padding. So there's no new attack possible here.
>     * And there's no need to specify a max length for any AccECN
>     Option, which would just unnecessarily limit flexibility.
>
>     [ms] I have more thought about the covert channel that some
>     unspecified bytes in a standards track TCP option could offer… In
>     particular if the AccECN option gets widely deployed and used,
>     would some malicious users find those bytes useful? For what? For
>     instance, what in the AccECN protocol design prevents use of these
>     “padding” bytes as super-cookie? To me, it is much more important
>     to think about abuse of whatever we standardize **now**, instead
>     of engineering for some entirely unknown future. I am not a
>     security expert, but I suggest a careful analysis of any security
>     implications of the AccECN option. We seldomly specify new TCP
>     options and malicious users will certainly look for
>     “opportunities” in the spec. So far, I don’t know whether that
>     whole idea of forward compatibility is a feature or a bug.
>
>
> [BB] If that were a problem, it could already be done, because (by my 
> reading of RFC793) it is valid to set the data offset to stretch out 
> the padding to any length within the max option space limits.
>
> [ms2] I don’t understand. RFC 793 mandates that padding is composed of 
> zeros, i.e., a firewall or IDS could detect a non-zero covert channel 
> in the padding (and even remove the padding). Also, there are IMHO no 
> reasonable engineering reasons for making the padding longer than 
> needed, i.e. such a covert channel could be detected as anomality. As 
> far as I understand RFC 793, a middlebox could also safely remove the 
> additional padding w/o impacting a standard-compliant TCP connection.
>
> [ms2] Allowing arbitrary bytes in a TCP option is IMHO a very 
> different story, in particular if you allow the values to have 
> non-zero values and forbid middleboxes to check or remove parts of the 
> option that are not standardized by the IETF. If I correctly 
> understand draft -13, an attacker could transmit 29 bytes payload at 
> the end of the AccECN option, in any TCP connection, for any purpose.
>
> [ms2] I think the „forward compatibility“ (e.g., Section 3.3.2 in the 
> I-D) needs a very careful security analysis. As far as I understand, 
> this whole idea of „forward compatibility“ is not needed for using the 
> **currently** standardized AccECN options. IMHO you could just remove 
> that „forward compatibility“ idea w/o impacting the rest of the AccECN 
> protocol as currently specified (including the current format of the 
> two options). If the idea of „forward compatibility“ stays in the 
> document, IMHO the security section needs a dedicated discussion 
> regarding potential misuse as covert channel. This could either be a 
> security or privacy issue, depending on who puts what additional bytes 
> into the option and claims that these bytes to be AccECNv2.
>

[BB] Fair enough.

I will happily mention in Security Considerations that this forward 
compatibility provision creates a covert channel of up to 29B,  but I 
don't think we need to panic about it. I suspect SEC area review will 
think about it for a moment, then let it through. There are all sorts of 
covert channels in TCP/IP headers, not least the packet ID field, or a 
TFO cookie. If they want it changed, we can either limit the additional 
length that we allow for forward compatibility or shut it down 
completely, depending on what we agree.

It is definitely worth noting this, and useful that you've noticed it at 
this stage, but I think even the SEC area will consider that future 
extensibility is more valuable than shutting off a covert channel.


Bob

> Michael
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/