Re: Mirja Kühlewind's Discuss on draft-ietf-6man-rfc1981bis-06: (with DISCUSS and COMMENT)

[Suresh Krishnan <[e-mail]>]

Hi Mirja,
  Thanks for the comments. I will let Bob comment on the DISCUSS
points on the original text from 1981 as he might be able to provide
more perspective. I just wanted respond to some of your comment points

On Mon, May 8, 2017 at 3:08 PM, Mirja Kühlewind <[e-mail]> wrote:
> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-6man-rfc1981bis-06: Discuss
>
> 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-6man-rfc1981bis/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> 1) I agree with Ekr on this sentence:
> "Nodes SHOULD appropriately validate the payload of ICMPv6 PTB
>    messages to ensure these are received in response to transmitted
>    traffic (i.e., a reported error condition that corresponds to an
> IPv6
>    packet actually sent by the application) per [ICMPv6]."
> This sounds like it should be a MUST but I guess it depends on the upper
> layer protocol if such a validation is possible or not, e.g. if
> information are available that can be used for validation. Maybe you can
> be more explicit here and even say something like pmtu discovery
> should/must only be used if the upper layer protocol provides means for
> validation of the icmp payload (like a sequence number in TCP)…?
>
> Further also note that if the upper layer does the validation while the
> IP layer maintains EMTU_S

This is not the case. The upper layer maintains the EMTU_S. Also see
my response to ekr that explains why this is a SHOULD instead of a
MUST.

> , there must be an interface from the upper
> layer to the IP layer to tell if a packet is valid or not before the IP
> layer updates the MTU estimate. This seems actually more complicated than
> this one sentences indicates.
>
> 2) Also as Ekr says, I also have problems to fully understand this
> normative text in section 4:
> "After receiving a Packet Too Big message, a node MUST attempt to
>    avoid eliciting more such messages in the near future.  The node
> MUST
>    reduce the size of the packets it is sending along the path.  Using
> a
>    PMTU estimate larger than the IPv6 minimum link MTU may continue to
>    elicit Packet Too Big messages.  Since each of these messages (and
>    the dropped packets they respond to) consume network resources, the
>    node MUST force the Path MTU Discovery process to end.
>
>    Nodes using Path MTU Discovery MUST detect decreases in PMTU as fast
>    as possible."
> I especially don't understand the first part, given that a PTB message
> may still indicate a MTU that is larger than the minimum link MTU which
> then may cause another PTB message later on the path. This text reads
> like if you receive one PTB message you should better end discovery and
> fall back to the minimum link MTU to avoid any further PTB message and
> not waist any resources. I don't think that's the intention and as such I
> don't understand when it is recommended to end discovery here...?

This talks about not increasing the size of the probe packet past the
MTU received in the PTB message. I think this can be reworded if it is
confusing.

>
> 3) Section 5.2 seems to be written with only single homed hosts in mind.
> It might be good to advise that the pmtu information should always be
> stored on a per interface basis...?

OK.

>
> 4) Also section 5.2:
> You only advise to store information per flow ID, however, if the flow
> label is not used, wouldn't it make really sense to just use the 5-tuple
> instead? Also note that EMCP is often done based on the 5-tuple or even
> 6-tuple (with the ToS field).

OK.

>
> 5) And more in section 5.2:
> "When a Packet Too Big message is received, the node determines which
>    path the message applies to based on the contents of the Packet Too
>    Big message. "
> MAYBE:
> "When a valid Packet Too Big message is received, the node determines
> which
>    path the message applies to based on the contents of the Packet Too
>    Big message."
> And further on:
> "If the tentative PMTU is less than the existing PMTU estimate, the
>    tentative PMTU replaces the existing PMTU as the PMTU value for the
>    path."
> This doesn't cover the case where a pmtu probe with a larger size was
> send and the PTB message returns a larger value then stored. Maybe state
> this explicitly.
>
> This applies similar to this sentence in section 6:
> OLD
> "A node, however, should never raise its estimate of the
>       PMTU based on a Packet Too Big message, so should not be
>       vulnerable to this attack.“
> NEW
> "A node, however, MUST NOT raise its estimate of the
>       PMTU based on a Packet Too Big message that is not a (validated)
> response to a PMTU probe that was previously send by this node, so should
> not be
>       vulnerable to this attack."

Sounds good.

>
> 6) Further section 5.2:
> Should this statement be maybe upper case MUST:
> "The packetization layers must be notified about decreases in the PMTU.
> "

As I said in my message to ekr this is not intended to be normative
text. There is a general disclaimer in Section 5 that states

"This section discusses a number of issues related to the
implementation of Path MTU Discovery. This is not a specification, but
rather a set of notes provided as an aid for implementers."

Is there some text change that can help clarify the intent better?

>
> 7) Technical comment on section 5.3 in general:
> There is a difference between aging if a flow is active or not. While I
> maybe don't want to probe again for this connection because my
> application already decided to use a mode where it can live with the
> current pmtu and it's too much effect to switch, I really want to probe
> at the beginning of the next connection again to check if I can use a
> different mode now. While the IP layer does not have a notion of
> connection it can observe if packets are frequently send with the same
> 5-tuple and reset the cached pmtu after a certain idle time.

Can you suggest some text?

>
> 8) Section 5.4: should this maybe be normative, at least the last MUST
> NOT (be fragmented):
> "A packetization layer (e.g., TCP) must track the PMTU for the path(s)
>    in use by a connection; it should not send segments that would
> result
>    in packets larger than the PMTU, except to probe during PMTU
>    discovery (this probe packet must not be fragmented to the PMTU). "

Same as #6 above. Section not intended to be normative.

>
>
> Nit:
> The abbreviation PTB is only used once in section 4 (and never expanded).

Sounds good. This needs to be expanded.

Regards
Suresh