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

[Alvaro Retana <[e-mail]>]

Hi!

Yes, if that text works for Ben then we can still add it to rfc5575bis.

Thanks!

Alvaro.

On November 4, 2020 at 3:34:36 PM, Christoph Loibl ([e-mail]) 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.


...


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