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

[Susan Hares <[e-mail]>]

Christoph and Ben: 

I think we should roll the paragraph into RFC5575 if Alvaro and Ben think it
helps.  I believe that DDoS implementers show know that concept, but it
never hurts to repeat security issues. 

The discussion on the IDR list for v6 did not deal with this specific issue
Ben is raising.  I also agree with Christoph's point that for DDoS
implementations, I do not see the incentive.  

Ben - is there some operational example you can provide for the DDoS event.

Sue


-----Original Message-----
From: Christoph Loibl [mailto:[e-mail]] 
Sent: Wednesday, November 4, 2020 3:34 PM
To: Benjamin Kaduk
Cc: The IESG; [e-mail]; [e-mail];
[e-mail]
Subject: Re: [BULK] [Idr] Benjamin Kaduk's Discuss on
draft-ietf-idr-flow-spec-v6-19: (with DISCUSS and COMMENT)

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

>>> 
>>> 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/zvpLPjllvKWFuyraZUVz8lB8Wz
>>> 0/
>>> 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?

Cheers Christoph
	
--
Christoph Loibl
[e-mail] | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at