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

[Christoph Loibl <[e-mail]>]

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

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