Subject: [v6ops] Spencer Dawkins' No Objection on draft-ietf-v6ops-pmtud-ecmp-problem-04: (with COMMENT)

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 13 Oct 2015 09:59:03 -0700

Spencer Dawkins has entered the following ballot position for
draft-ietf-v6ops-pmtud-ecmp-problem-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-pmtud-ecmp-problem/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In section 3, "Mitigation", I'm reading this.

   Mitigation of the potential for PTB messages to be mis-delivered
   involves ensuring that an ICMPv6 error message is distributed to the
   same anycast server responsible for the flow for which the error is
   generated.  Ideally, mitigation could be done by the mechanism hosts
               ^^^^^^^
   use to identify the flow, by looking into the payload of the ICMPv6
   message (to determine which TCP flow it was associated with) before
   making a forwarding decision.  Because the encapsulated IP header
   occurs at a fixed offset in the ICMP message it is not outside the
   realm of possibility that routers with sufficient header processing
   capability could parse that far into the payload.  Employing a
   mediation device that handles the parsing and distribution of PTB
   messages after policy routing or on each load-balancer/server is a
   possibility.
   
Most of the document is about using other mitigations that make this
mitigation unnecessary, but it's still a bit odd to see Deep Packet
Inspection characterised as "ideally", now that RFC 7258 is now BCP 188,
and we've chartered TCPINC to make that DPI fail as often as possible. 

Could that one word go away?

I see in email that Fred asked if any reviews were needed before
submitting this draft for publication, and David Black suggested reviews
from INT and TSV, and that made it as far as the shepherd writeup, but
I'm not seeing a request for review popping up in TSV (at least not with
"PMTUD" and "V6OPS" in an e-mail). I don't have concerns about this
particular draft, but I wish it hadn't slipped through that particular
crack. 

Yes, Fred copied TSVWG and TSVAREA on his note asking for guidance, and
yes, there was an IETF Last Call, so I'm not hitting "Defer" to chase
that. Just something to watch for, in the future.

And yes, Martin and I have a call set up to talk with the TSVdir triage
team next week ...

---

From: Benoit Claise <[email-masked]>
Date: Thu, 15 Oct 2015 09:47:44 +0200

Spencer,
> https://datatracker.ietf.org/doc/draft-ietf-v6ops-pmtud-ecmp-problem/
 From a resource consumption point of view, the ideal situation would be 
NOT to distribute the PTB message to all anycast servers. This is a 
fact. Therefore, I don't have a problem with "ideally" in this context. 
After all, this document is not a spec on using DPI.

Regards, Benoit
> .

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 15 Oct 2015 07:56:41 -0500

Hi, Benoit,

On Thu, Oct 15, 2015 at 2:47 AM, Benoit Claise <[email-masked]> wrote:

> NOT to distribute the PTB message to all anycast servers. This is a fact.
> Therefore, I don't have a problem with "ideally" in this context. After
> all, this document is not a spec on using DPI.

I agree with your observation. I would think that in order for something to
be ideal, it should be possible (ideally we should be able to send packets
at greater than the speed of light, but we can't, so. Ideally we should be
able to send the PTB only to the place it needs to go, but we can't, so).

But I'm a TSV guy who is poking at this because of RFC 7258, so if the SEC
folk don't care, I'm fine.

Spencer

---

From: Tim Chown <[email-masked]>
Date: Thu, 15 Oct 2015 21:06:12 +0100

Hi,

> On 15 Oct 2015, at 13:56, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Hi, Benoit,
> 
> On Thu, Oct 15, 2015 at 2:47 AM, Benoit Claise <[email-masked] <mailto:[email-masked]>> wrote:
> Spencer,
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html <https://www.ietf.org/iesg/statement/discuss-criteria.html>
> https://datatracker.ietf.org/doc/draft-ietf-v6ops-pmtud-ecmp-problem/ <https://datatracker.ietf.org/doc/draft-ietf-v6ops-pmtud-ecmp-problem/>
> 
> 
> 
> >From a resource consumption point of view, the ideal situation would be NOT to distribute the PTB message to all anycast servers. This is a fact. Therefore, I don't have a problem with "ideally" in this context. After all, this document is not a spec on using DPI.
> 
> I agree with your observation. I would think that in order for something to be ideal, it should be possible (ideally we should be able to send packets at greater than the speed of light, but we can't, so. Ideally we should be able to send the PTB only to the place it needs to go, but we can't, so). 

None of the mitigations are ‘ideal’.

But the document is useful for noting the problem,describing it well, and discussing wha *could* be done.

Tim

> 
> But I'm a TSV guy who is poking at this because of RFC 7258, so if the SEC folk don't care, I'm fine.
> 
> Spencer
>  
> Regards, Benoit
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: joel jaeggli <[email-masked]>
Date: Sun, 18 Oct 2015 18:49:06 -0700

On 10/15/15 1:06 PM, Tim Chown wrote:

>> I agree with your observation. I would think that in order for
>> something to be ideal, it should be possible (ideally we should be
>> able to send packets at greater than the speed of light, but we can't,
>> so. Ideally we should be able to send the PTB only to the place it
>> needs to go, but we can't, so). 
> 

I tweaked it to remove ideal...

https://www.ietf.org/rfcdiff?url1=draft-ietf-v6ops-pmtud-ecmp-problem-04&url2=draft-ietf-v6ops-pmtud-ecmp-problem-06

>> [email-masked] <mailto:[email-masked]>