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

From: Lars Eggert <[email-masked]>
Date: Mon, 11 Oct 2021 13:08:21 +0300

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 <[email-masked]> 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.

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

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?

Thanks,
Lars

---

From: Giuseppe Fioccola <[email-masked]>
Date: Mon, 11 Oct 2021 13:46:12 +0000

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

Regards,

Giuseppe

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

Hi,

On 2021-8-6, at 12:36, Lars Eggert via Datatracker <[email-masked]> wrote:
> 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?

[GF]: Thanks.

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

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

[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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 Oct 2021 09:16:49 +1300

Giuseppe,

I think you're still not addressing Lars's question. I can't answer for you, but I can restate why 20 bits is not a problem for the IPv6 flow label.

The use case for the flow label is stateless load balancing or ECMP. For that purpose, a collision rate of 1 per million (for packets between the same source and destination) is perfectly acceptable, since there are far fewer than a million possible paths and the effect of an occasional collision on effective load balancing is completely negligible. To say that another way, the n-tuple that includes the flow label will be hashed down to a few bits (to one bit if there are only two paths for example) so who cares about a 1/1048576 chance of collision?

Can you make an argument like that for why 1/1048576 collision rate is OK in your use case?

Regards
   Brian Carpenter

On 12-Oct-21 02:46, Giuseppe Fioccola wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Giuseppe Fioccola <[email-masked]>
Date: Mon, 11 Oct 2021 22:46:06 +0000

Hi Brian,
Thanks for the comment.
1/1048576 collision rate is ok because you can always use the FlowMonID together with source and destination addresses for possible disambiguation.
If we do not want to rely on source and destination addresses, 1/1048576 could not be enough. But we can simply define a longer FlowMonID so it can be used alone. 
I have nothing against this option, I'm just saying that source and destination addresses can easily be used together with FlowMonID.

Regards,

Giuseppe

-----Original Message-----
From: Brian E Carpenter <[email-masked]> 
Sent: Monday, October 11, 2021 10:17 PM
To: Giuseppe Fioccola <[email-masked]>; Lars Eggert <[email-masked]>; [email-masked]
Cc: [email-masked]; Bob Hinden <[email-masked]>; The IESG <[email-masked]>; [email-masked]
Subject: Re: Lars Eggert's Discuss on draft-ietf-6man-ipv6-alt-mark-08: (with DISCUSS and COMMENT)

Giuseppe,

Regards
   Brian Carpenter

On 12-Oct-21 02:46, Giuseppe Fioccola wrote:
> Cc: The IESG <[email-masked]>; Bob Hinden <[email-masked]>; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Lars Eggert's Discuss on 
> draft-ietf-6man-ipv6-alt-mark-08: (with DISCUSS and COMMENT)
> 
> Hi,
> 
>> 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 
>> 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?
>

---

From: Lars Eggert <[email-masked]>
Date: Tue, 12 Oct 2021 15:45:36 +0300

Hi,

> I have nothing against this option, I'm just saying that source and destination addresses can easily be used together with FlowMonID.

what I am trying to get at is that with a 20-bit FlowMonID, at most ~1M concurrent flows can be tracked, and much less than that with random assignment of FlowMonIDs. That seems insufficient for anything but very small deployments.

If there are these two modes of deployment (based on just matching FlowMonIDs and based on matching FlowMonIDs and src/dst addresses), the document should discuss how one would determine which mode to use for a given network, and what the consequences are of choosing an inappropriate one.

Or, the document should simply require a single deployment mode where source and destination IP addresses are always included in the match. This would get you to ~1M concurrent flows per host-pair (with centralized assignment), which seems to support more use cases.

You could of course also lengthen the FlowMonID, but then the document should discuss why a given length is suitable for many/most deployment scenarios of interest (in terms of supported concurrent flows), esp. with randomized assignment.

Thanks,
Lars

---

From: Giuseppe Fioccola <[email-masked]>
Date: Tue, 12 Oct 2021 15:57:22 +0000

Hi Lars,

Regards,

Giuseppe

-----Original Message-----
From: Lars Eggert <[email-masked]> 
Sent: Tuesday, October 12, 2021 2:46 PM
To: Giuseppe Fioccola <[email-masked]>
Cc: Brian E Carpenter <[email-masked]>; [email-masked]; Bob Hinden <[email-masked]>; [email-masked]; The IESG <[email-masked]>; [email-masked]
Subject: Re: Lars Eggert's Discuss on draft-ietf-6man-ipv6-alt-mark-08: (with DISCUSS and COMMENT)

Hi,

[GF]: The requirement of the controlled domain mitigates not only the security concerns but also the probability of FlowMonID collisions, since the option is not spread over the internet. Our practice shows that, for limited domains with a central controller, the 20-bit FlowMonID is enough. However, I agree with you and, generally speaking, the 20-bit FlowMonID alone could not be enough in every scenario.

[GF]: I will definitely revise the draft soon and clarify better the deployment mode. In order to support most of the scenarios, the draft will recommend only the mode where source and destination addresses are considered in the match criteria together with the FlowMonID.

[GF]: The enlargement of the FlowMonID could not be the first choice, especially when the option is used with other extension headers (e.g. SRH) and we need to control the extension header length.

Thanks,
Lars

---

From: Giuseppe Fioccola <[email-masked]>
Date: Thu, 21 Oct 2021 13:49:18 +0000

Hi Lars, All,
Please note that we just published a new revision of the draft. In section 5.3 we have clarified the recommended deployment mode based on matching FlowMonID with source and destination addresses.

Regards,

Giuseppe

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Giuseppe Fioccola
Sent: Tuesday, October 12, 2021 5:57 PM
To: Lars Eggert <[email-masked]>
Cc: [email-masked]; [email-masked]; Bob Hinden <[email-masked]>; The IESG <[email-masked]>; [email-masked]
Subject: RE: Lars Eggert's Discuss on draft-ietf-6man-ipv6-alt-mark-08: (with DISCUSS and COMMENT)

Hi Lars,

Regards,

Giuseppe

-----Original Message-----
From: Lars Eggert <[email-masked]> 
Sent: Tuesday, October 12, 2021 2:46 PM
To: Giuseppe Fioccola <[email-masked]>
Cc: Brian E Carpenter <[email-masked]>; [email-masked]; Bob Hinden <[email-masked]>; [email-masked]; The IESG <[email-masked]>; [email-masked]
Subject: Re: Lars Eggert's Discuss on draft-ietf-6man-ipv6-alt-mark-08: (with DISCUSS and COMMENT)

Hi,

Thanks,
Lars

---

From: Lars Eggert <[email-masked]>
Date: Fri, 22 Oct 2021 10:26:04 +0300

Hi,

> Please note that we just published a new revision of the draft. In section 5.3 we have clarified the recommended deployment mode based on matching FlowMonID with source and destination addresses.

I'm looking at the diff at https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-ipv6-alt-mark-11.

There is now this paragraph in Section 5.3:

>    The value of 20 bits has been selected for the FlowMonID since it is
>    a good compromise and implies a low rate of ambiguous FlowMonIDs that
>    can be considered acceptable in most of the applications.  Indeed,
>    with 20 bits the number of combinations is 1048576.

You only get ~1M concurrent flows with centralized assignment of the FLowMonIDs. With uncoordinated local randomized assignment, you'll get much less, esp. since you'll want to require very low collision probabilities (do the math). The tradeoffs here are important to explain in detail, so that deployers realize they need to either look into using a controller and/or combining the FlowMonID with additional header fields.

>    The requirement
>    of the controlled domain also reduces the probability of FlowMonID
>    collisions, since the AltMark Option is not spread over the internet.

I don't understand how this is true. The collision probability only depends on flow creation rates?

>    A consistent approach MUST be used in the implementation to avoid the
>    mixture of different ways of identifying.

I think you mean "A consistent approach MUST be used ***in deployment***"?

>    By considering source and destination
>    addresses together with the the FlowMonID it can be possible to
>    monitor 1048576 concurrent flows per host pairs.  This allows finer
>    granularity and therefore adds even more flexibility to the flow
>    identification.

Again, this ~1M concurrent flows per host pair only holds for centralized assignment via a controller, not for randomized assignment.

Thanks,
Lars

---

From: Giuseppe Fioccola <[email-masked]>
Date: Fri, 22 Oct 2021 07:55:24 +0000

Hi Lars,
My replies inline as [GF].
I will submit a new version soon to address your comments.

Regards,

Giuseppe

-----Original Message-----
From: Lars Eggert <[email-masked]> 
Sent: Friday, October 22, 2021 9:26 AM
To: Giuseppe Fioccola <[email-masked]>
Cc: Bob Hinden <[email-masked]>; [email-masked]; [email-masked]; The IESG <[email-masked]>; [email-masked]
Subject: Re: Lars Eggert's Discuss on draft-ietf-6man-ipv6-alt-mark-08: (with DISCUSS and COMMENT)

Hi,

[GF]: I agree. I will clarify that for local random assignment the collision probability is different (50% chance of collision for 1206 flows). For this reason, the draft can also recommend the centralized solution.

[GF]: To avoid misunderstanding I can omit this sentence.

[GF]: Yes, I will revise.

[GF]: yes, as above.

Thanks,
Lars

---

From: Giuseppe Fioccola <[email-masked]>
Date: Fri, 22 Oct 2021 13:55:26 +0000

Hi Lars,
I just submitted the new version. Please check whether the revised section 5.3 clarifies and addresses your concerns.

Regards,

Giuseppe

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Giuseppe Fioccola
Sent: Friday, October 22, 2021 9:55 AM
To: Lars Eggert <[email-masked]>
Cc: [email-masked]; [email-masked]; Bob Hinden <[email-masked]>; The IESG <[email-masked]>; [email-masked]
Subject: RE: Lars Eggert's Discuss on draft-ietf-6man-ipv6-alt-mark-08: (with DISCUSS and COMMENT)

Hi Lars,

Regards,

Giuseppe

-----Original Message-----
From: Lars Eggert <[email-masked]> 
Sent: Friday, October 22, 2021 9:26 AM
To: Giuseppe Fioccola <[email-masked]>
Cc: Bob Hinden <[email-masked]>; [email-masked]; [email-masked]; The IESG <[email-masked]>; [email-masked]
Subject: Re: Lars Eggert's Discuss on draft-ietf-6man-ipv6-alt-mark-08: (with DISCUSS and COMMENT)

Hi,

[GF]: yes, as above.

Thanks,
Lars

---

From: Lars Eggert <[email-masked]>
Date: Tue, 26 Oct 2021 17:05:53 +0300

Hi,

> I just submitted the new version. Please check whether the revised section 5.3 clarifies and addresses your concerns.

thank you, I have cleared my Discuss.

Lars

---

From: Giuseppe Fioccola <[email-masked]>
Date: Tue, 26 Oct 2021 16:18:58 +0000

Thank you Lars.
Regards,

Giuseppe

-----Original Message-----
From: Lars Eggert <[email-masked]> 
Sent: Tuesday, October 26, 2021 4:06 PM
To: Giuseppe Fioccola <[email-masked]>
Cc: Bob Hinden <[email-masked]>; [email-masked]; [email-masked]; The IESG <[email-masked]>; [email-masked]
Subject: Re: Lars Eggert's Discuss on draft-ietf-6man-ipv6-alt-mark-08: (with DISCUSS and COMMENT)

Hi,

Lars