Re: [secdir] secdir review of draft-ietf-tram-stun-pmtud

[Marc Petit-Huguenin <[e-mail]>]

Hi Carl,

Thank you for the review.  See my comments inline.

On 09/11/2018 05:43 AM, Carl Wallace wrote:
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
> These comments were written primarily for the benefit of the security area
> directors.  Document editors and WG chairs should treat these comments
> just like any other last call comments.
> 
> This document describes a Session Traversal Utilities for NAT (STUN) usage
> for Path MTU Discovery (PMTUD) between a client and a server.
> 
> A few comments (bearing in mind I am not versed in STUN specs):
> 
> - It may be worth highlighting the requirement for authentication when
> providing an overview of the Complete Probing mechanism in section 2.

I added the following paragraph at the end of the section:

"Because of the possibility of amplification attack, the Complete
 Probing mechanism must be authenticated.  Particular care must be
 taken to prevent amplification when an external mechanism is used to
 trigger the Complete Probing mechanism."

> - In section 4, replace "Simple Probing mechanism does not require
> authentication" with "Simple Probing mechanism does not require
> authentication except where used as an implicit signaling mechanism".

Applied.

> - Complete Probing and some uses of Simple Probing require authentication.
> Are there any authentication mechanisms that must be supported?

Any authentication mechanism defined for STUN can be used, there is no specific constraint to be added.

> - The second paragraph of the introduction and first paragraph of section
> 5 open the use of the spec to non-STUN-based protocols may not square with
> all of the MUSTs in the document, some of which require STUN (like section
> 4.1.x). 

I do not understand the problem here.  There is two protocols involved in this specification, the first one is any UDP based protocol that does not already have a PMTUD mechanism (and that includes STUN based protocols, as long as they use UDP as transport and they do not have a PMTUD mechanism baked-in).  The second protocol is one of the two STUN based protocols that are described in this document and used on top of the first protocol for the purpose of providing PMTUD.  The MUSTs are for these two protocols, not for the first protocol.

Let me give an example.  TFTP is a UDP protocol that does not have a PMTUD mechanism defined.  One can design an extension that is using this specification to add PMTUD and increase the size of the packets without triggered fragmentation.  None of the MUST applies to TFTP itself, only to the PMTUD mechanism.

Now lets imagine that someone designed a protocol similar to TFTP using STUN instead of an adhoc encoding for the packets, but still without a PMTUD mechanism.  Similarly to the previous example a PMTUD mechanism can be added on top of that protocol, but the MUSTs in this document still apply only to the STUN packets of the PMTUD mechanism, not to the STUN packets of the underlying protocol.

> - Why is 5780 marked as informative? Attributes from it are required.

Moved to the normative section.

-- 
Marc Petit-Huguenin
Email: [e-mail]
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug