RE: Lars Eggert's Discuss on draft-ietf-6man-ipv6-alt-mark-08: (with DISCUSS and COMMENT)

[Giuseppe Fioccola <[e-mail]>]

Hi Lars,
Thank you for your review.
Please find my replies inline tagged as [GF].

Regards,

Giuseppe

-----Original Message-----
From: Lars Eggert <[e-mail]> 
Sent: Monday, October 11, 2021 12:08 PM
To: [e-mail]
Cc: The IESG <[e-mail]>; Bob Hinden <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Subject: Re: Lars Eggert's Discuss on draft-ietf-6man-ipv6-alt-mark-08: (with DISCUSS and COMMENT)

Hi,

I looked at the diff between versions -08 and -10 to see if my DISCUSS was addressed:

On 2021-8-6, at 12:36, Lars Eggert via Datatracker <[e-mail]> wrote:
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Section 2.1. , paragraph 4, discuss:
>>   Therefore, the IPv6 application of the Alternate Marking Method MUST
>>   NOT be deployed outside a controlled domain.
> 
> That's not what Section 6 says, which allows use outside a controlled 
> domain (across the Internet) if protection is applied?
> 
> Section 2.1. , paragraph 4, discuss:
>>   Some scenarios may imply that the Alternate Marking Method is applied
>>   outside a controlled domain, either intentionally or unintentionally,
>>   but in these cases, IPsec authentication and encryption MUST be used.
> 
> How can one require use of IPsec for an unintentional use outside of a 
> controlled domain? If the header leaks by accident, surely it's 
> unreasonable to expect that IPsec had been set up to catch any and all such possible leakage?

the way I understand the additions in -10 is that a "controlled domain" is supposed to be some networks that either directly peer or interconnect with VPNs (like IPsec). I consider this part of my DISCUSS addressed.

[GF]: Thanks.

> Section 5.3.1. , paragraph 2, discuss:
>>   It is important to note that if the 20 bit FlowMonID is set
>>   independently and pseudo randomly there is a chance of collision.
>>   Indeed, by using the well-known birthday problem in probability
>>   theory, if the 20 bit FlowMonID is set independently and pseudo
>>   randomly without any additional input entropy, there is a 50% chance
>>   of collision for 1206 flows.  So, for more entropy, FlowMonID can
>>   either be combined with other identifying flow information in a
>>   packet (e.g. it is possible to consider the hashed 3-tuple Flow
>>   Label, Source and Destination addresses) or the FlowMonID size could
>>   be increased.
> 
> It seems odd to define a dedicated FlowMonID, but make it so short 
> that it is basically not usable in many realistic scenarios. If other 
> parts of the packet headers need to be inspected to disambiguate 
> FlowMonID collisions, this (1) should at least be more carefully 
> specified in this document (since every node will need to do it in the 
> same way) but (2) probably argues for a much longer FlowMonID - why not make it 64 bits or longer?

Some changes were made with regards to the FlowMonID, but I don't think they address my points above.

First, the ID is still too short to be useful by itself in moderately busy networks, even when centrally assigned (with the overheads that that entails) - it can only distinguish ~1M concurrent flows, and much less than that with random assignment.

[GF]: An option can be to make FlowMonID longer, but we are now following a conservative approach. In this regard, RFC6437 mentioned the 3-tuple of Flow Label, Source Address and Destination Address for efficient IPv6 flow classification. In case of Alternate Marking, as said in the document, it is not possible to use the Flow label, but the usage of the 3-tuple of the FlowMonID, Source Address and Destination Address fields is a viable solution also to solve disambiguation issues.


Second, doing lookups based on the FlowMonID together with other fields still seems underspecified. There is text that all devices in a domain need to use the same lookup mode (FlowMonID only or combined with other fields), but nothing is specified with regards to how a combined lookup needs to be implemented everywhere. Doesn't this measurement scheme rely on consistent hashing of such fields everywhere?

[GF]: A simple logical AND operation of the fields can work. The alternate marking method can be applied to both single path (RFC8321) and multipoint path (RFC8889). For this reason the flow selection rules, used to select the flows to be monitored, may vary in order to change the pattern of the monitored network. The FlowMonID can identify not only a point-to-point flow but, in general, it can be assigned to a multipoint-to-multipoint flow. Since this document only aims to define the IPv6 Option for Alternate Marking, we could mention that the type of lookup can be configured but outside the scope of this document. Indeed we are working on control plane I-Ds (draft-ietf-idr-sr-policy-ifit, draft-chen-pce-pcep-ifit) and plan to work on a YANG Model as well.


Thanks,
Lars