Re: [Idr] [BULK] Benjamin Kaduk's Discuss on draft-ietf-idr-flow-spec-v6-19: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

Hi Christoph, Sue,

On Wed, Nov 04, 2020 at 09:33:56PM +0100, Christoph Loibl wrote:
> Hi Benjamin,
> 
> See my comments below (I stripped down the message, it only contains the remaining issues). 
> 
> @ Alvaro: Please also read my last question.
> 
> 
> > On 04.11.2020, at 17:36, Benjamin Kaduk <[e-mail]> wrote:
> >>> ## DISCUSS:
> >>> A fairly minor point, but I think that allowing Type 13 (flow label)
> >>> component values to be encoded as 2-byte quantities encourages the
> >>> selection of non-random flow label values, and thus violates the
> >>> guidance from RFC 6437 that these values "should be chosen such that
> >>> their bits exhibit a high degree of variability" and that "third parties
> >>> should be unlikely to be able to guess the next value that a source of
> >>> flow labels will choose." While having the short 1-byte encoding for a
> >>> flow label of 0 might be reasonable, a 2-byte label can represent at
> >>> most 16 bits of the 20-bit identifier space, discouraging the use of the
> >>> high 4 bits, when such bits of unpredictability are scarce already.
> >>> Let's discuss how big an issue this is and what might be done to
> >>> mitigate it.
> >> 
> >> The Type-13 component is not the flow label itself. It is only the filter that allows to match on that particular field in the IPv6 header of the packets. If the flow-label encoded in the packet (unlikely, but possible) can be encoded in 8,16-bits one could encode the match filter in a shorter form. However, this may be very unlikely. This specification does not choose those flow labels, but allows to match on flow labels in packets (usually generated by other systems).   
> > 
> > I understand that this specification is describing patterns to match flow
> > labels and not the flow labels themselves, yes.  However, this document is
> > saying that, *if* the flow labels themselves have a certain structure, then
> > the flow specification (from this document) to match the flow labels has a
> > more compact encoding.  This, in turn, sets up an incentive for the party
> > assigning flow labels to conform to the specific structure of flow label
> > values, in order to take advantage of the more compact encoding.  I believe
> > that using any kind of substructure when assigning flow label values is
> > contrary to the guidance of RFC 6437 (and, relately, harms the overall
> > security of the internet), and thus am supplying resistance to a mechanism
> > that incentivizes using such internal structure in flow label values.
> > The discussion that I would like to have here relates to the magnitude of
> > incentive in question (to use specific substructure when generating flow
> > label values), which in turn is related to how much benefit there is from
> > shaving two bytes off the flow specification encoding.  I do not believe
> > that your comment above is trying to make such an assessment on the
> > magnitude of the incentive in question or the value of having the slightly
> > more compact encoding available.
> 
> I do not think that is an incentive for anyone. The main application for FS is DDoS mitigation. Those who mitigate an attack with FS do not even have control over the flow-labels used by an attack. One could argue that for an attacker it could be even an advantage to make use of the entire 20-bit flow-label space to make mitigation via FS less efficient (but this might be a bit exaggerated). 

Thanks for the extra context; I was assuming there were "normal traffic
management" cases as well as DDoS mitigation ones.

That would make me want to flip my question around, then -- what is gained
by encoding the flow spec filter for flow labels in 8 or 16 bits instead of
32?  I am not trying to say that it must always be in 32, especially if the
WG definitely wants to allow those cases.  It just seems like it might be
simpler to always use the 32-bit encoding and avoid having to deal with the
case where the value in the filter has to match a wider field in the actual
IP header.

To attempt to answer Sue's question: I don't have a particular DDoS case in
mind where this is relevant (and I would mostly assume that an extra byte
or two in the flowspec encoding would be in the noise).  I was just trying
to understand the reasoning for having the flexibility of the shorter
encoding, since using the shorter encoding introduces other issues.

> >>> 
> >>> Section 7
> >>> 
> >>> It was a little surprising to me that the inability to match (e.g.) TCP
> >>> flags or Port values on non-initial IP fragments was not reiterated in
> >>> the security considerations of 5575bis. I don't think it would make
> >>> sense to mention that just in this document's security considerations,
> >>> though -- if we are to change anything it should be in 5575bis. But I
> >>> guess we had that conversation already, at
> >>> https://mailarchive.ietf.org/arch/msg/idr/zvpLPjllvKWFuyraZUVz8lB8Wz0/
> >>> and thus no change is expected.
> >> 
> >> While IPv4 and IPv6 fragmentation serves the same pupose the encoding is different so we needed to redefine thi section. FS is working stateless on the packets and can only match on what is in the packet.
> > 
> > Exactly.  I am proposing that this restriction (working stateless and
> > cannot match [application-layer headers] things not in the packet) is
> > mentioned again in the security considerations section.  I believe that
> > this limitation can be described in a way that is agnostic to IPv4 vs IPv6,
> > and thus would be better placed in 5575bis than in this document.
> 
> I agree that this should rather go into 5575bis than in this document. 
> 
> I suggest to add the following to the Security Considerations section: 
> 
> ADD: 
> Implementations may not be able to locate all header values
> required to identify a packet. This can be especially problematic 
> in the case of fragmented packets that are not the first fragment 
> and thus lack upper-layer protocol headers or Encapsulating Security 
> Payload (ESP) NULL [RFC4303] encryption.
> 
> @ Alvaro do you think we should roll that paragraph into rfc5575bis?

I'm happy to see that or something like it in 5575bis; thanks!
I am not sure, though, of the intended grouping -- is the ESP NULL
encryption case intended to be one of the "especially problematic" cases,
or something that is absent in fragmented packets?  I assume the former, in
which case this version might be easier to read:

% Implementations may not be able to locate all header values
% required to identify a packet. This can be especially problematic 
% in the case of fragmented packets that are not the first fragment and
% thus lack upper-layer protocol headers, or when Encapsulating Security
% Payload (ESP) NULL [RFC4303] encryption is used.

Thanks again!

-Ben