Re: [tram] A few comments on draft-ietf-tram-stun-pmtud-17.txt

[Magnus Westerlund <[e-mail]>]

Hi Felipe,

draft-ietf-tsvwg-datagram-plpmtud is in AUTH48 currently. Adding an
informational reference to your draft will result in it being published with a
draft reference. 

The expectation has always been that the RFC for tsvwg-datagram-plpmtud will be
referenced in the future by additional specific mechanism using what is
specified. 

So I am hesistant to add a reference in this stage as I see limited utility of
the reference that will require sufficient knowledge to find the future RFC for
the tram draft. 

Can you please provide a specific proposal for text for what you want to add if
you still think it is a good idea to add a informative reference. 

Cheers

Magnus Westerlund

On Wed, 2020-08-19 at 15:24 +0000, Felipe Garrido (fegarrid) wrote:
> Hi Gorry,
>  
> Version 18 has been published with the changes mentioned below.  To make sure
> readers are aware, can you add an informative reference to stun-pmtud in the
> tsvwg-datagram-plpmtud draft?
>  
> Thanks,
> -Felipe
>  
> From: Gorry Fairhurst <[e-mail]>
> Date: Tuesday, August 4, 2020 at 5:05 AM
> To: "Felipe Garrido (fegarrid)" <[e-mail]>, "[e-mail]" <
> [e-mail]>
> Cc: "[e-mail]" <[e-mail]>
> Subject: Re: [tram] A few comments on draft-ietf-tram-stun-pmtud-17.txt
>  
>  
> On 03/08/2020 14:39, Felipe Garrido (fegarrid) wrote:
> > Hi Gorry,
> >  
> > Thank you for the comments. Responses are in-line.
> >  
> > Thanks,
> > -Felipe
> >  
> > From: tram <[e-mail]> on behalf of Gorry Fairhurst <
> > [e-mail]>
> > Date: Tuesday, July 14, 2020 at 9:24 AM
> > To: "[e-mail]" <[e-mail]>
> > Cc: "[e-mail]" <[e-mail]>
> > Subject: [tram] A few comments on draft-ietf-tram-stun-pmtud-17.txt
> >  
> > I had a look at draft-ietf-tram-stun-pmtud-17 with respect to the last
> > comments, and saw some changes and I have a few comments. These comments are
> > sent to the TRAM mailing list,
> > Gorry
> > ---
> > Section 2 does not discuss the frequency of the probe. This is a congestion
> > control case, and the method needs to assert some guidance/requirements on
> > the probing. Do probe packets count against cwnd when using this method?
> > 
> > In section 4.1.
> > I think this is misleading, and not a feature of the simple method:
> > “   Note: Routers can be configured to clear the DF bit or ignore the DF
> >    bit which can be difficult or impossible to detect if reassembly
> >    occurs prior to receiving the packet, rendering PLPMTUD inaccurate.
> > “
> > - I wouldn’t call this inaccurate? If the path contains a link-layer (or
> > tunnel or anything) that fragments and reassembles - then the path MTU is
> > whatever size that assembly is performed to. It has always been this way, if
> > links fragment and reassemble, IP uses the reassembled size.
> > 
> > 
> > --
> > Updated the Note as follows.
> > “   Note: Routers can be configured to clear the DF bit or ignore the DF
> >    bit which can be difficult or impossible to detect if reassembly
> >    occurs prior to receiving the packet.”
> >  
> 
> Sure. I'd actually suggest /might be configured/ to /can be configured/... I'm
> not sure any RFC should do this according to the spec.
> 
> > In section 4.2.2.  Receiving an ICMP Packet
> > This ID currently recommends “ Validation SHOULD be performed on the ICMP
> >    packet as specified in [RFC8085].”
> > - Since this is a method above UDP, I think this implicitly also checks the
> > UDP port information, hence this recommendation actually is an unavoidable
> > consequence when using a normal stack - if you have one that forwards ICMP
> > to the socket.
> > This becomes a requirement (or is always true) in dplpmtud:
> > - “Any received PTB message MUST be validated before it is used to update
> > the PLPMTU discovery information”.
> > - Should this be a requirement in this spec, to avoid off-path attack?
> > 
> > _______________________________________________
> > tram mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tram
-- 
Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------