Re: [secdir] secdir review of draft-ietf-tcpm-tcpmss-04

David Borman <> Wed, 30 May 2012 17:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5145111E80D2; Wed, 30 May 2012 10:29:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.909
X-Spam-Status: No, score=-2.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_6CONS_WORD=0.356]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zCIzcl7c79Wm; Wed, 30 May 2012 10:29:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3DDC711E80BB; Wed, 30 May 2012 10:29:16 -0700 (PDT)
Received: from pps.filterd (m0001158 []) by (8.14.4/8.14.4) with SMTP id q4UHTAu6022595; Wed, 30 May 2012 10:29:15 -0700
Received: from ([]) by with ESMTP id 155me88amy-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 30 May 2012 10:29:15 -0700
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 30 May 2012 10:29:01 -0700
Received: from ([fe80::6081:f8af:54f6:10cc]) by ([fe80::e4fd:df34:99ee:ac5e%20]) with mapi id 14.01.0355.002; Wed, 30 May 2012 11:29:14 -0600
From: David Borman <>
To: Klaas Wierenga <>
Thread-Topic: secdir review of draft-ietf-tcpm-tcpmss-04
Thread-Index: AQHNPnXIPFIPS9owW0+7AUuNti9CaZbi+xyA
Date: Wed, 30 May 2012 17:29:13 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7580, 1.0.260, 0.0.0000 definitions=2012-05-30_02:2012-05-21, 2012-05-30, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1205300187
Content-Type: text/plain; charset="iso-8859-1"
X-Mailman-Approved-At: Wed, 30 May 2012 15:19:14 -0700
Cc: "<>" <>, The IESG <>, "<>" <>
Subject: Re: [secdir] secdir review of draft-ietf-tcpm-tcpmss-04
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 May 2012 17:29:18 -0000


Thanks for the review.

On May 30, 2012, at 10:05 AM, Klaas Wierenga wrote:

> Hash: SHA1
> Hi,
> 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.
> General comments:
> ==================
> This is a short, clear and to the point draft. I have only a few
> general comments
> 1 (introduction)
> - ----------------
> - - Please expand MSS on first use


> - - "(see appendix A)" and "but there still seems to be some confusion"
> This sounds pretty vague to me. I thought Appendix A would be a
> verbatim copy of the text from 1122, but it is much more, and I
> appreciated the discussion. I propose to make that explicit:
> "RFC1122 clarified the MSS option, but confusion remains as discussed
> in Appendix A"

I've changed it to:
   RFC 1122 [RFC1122] clarified the MSS
   option, which is discussed in Appendix A, but there still seems to be
   some confusion.
> Security Considerations:
> ========================
> I don't really think what you have written down here qualifies as
> security considerations. It sort of hints to a denial-of-service, but
> I don't see any evil, just an operational problem.

Another review said more or less the same thing..

> What I wonder about
> (but I am not knowledgable to judge) is whether wrong MSS size
> settings could be exploited for for example buffer overflow attacks.

There shouldn't be any problem.  The MSS is just an upper bound
for the size of packets that can be reassembled by the receiving
hosts; in theory most IPv4 hosts should be using 65535 because they
don't have a fixed limit, and then just let Path MTU discovery sort
it out.  In practice, though, the MSS is used as an upper bound for what
size of packet can be received without the need for fragmentation,
avoiding PMTU from probing for larger sizes that will never succeed.

I don't have a strong opinion about the current content of the
Security Considerations section.  My leaning is to just leave it
as is, but I'd be fine with moving the content up to section 5.4
as an "Additional Consideration", and then have section 6, "Security
Considerations" just have a comment that there are no security
considerations, if folks generally feel that would be better.
		-David Borman

> Cheers,
> Klaas
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools -
> Comment: Using GnuPG with Mozilla -
> iEYEARECAAYFAk/GNzAACgkQH2Wy/p4XeFJQrACdEZggKbo9y+3p3W35N7FBzpho
> izcAoIl1J9o04ymIXyYmEZP+IiHRH18I
> =aIb0

The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum. Quantum reserves the right to have electronic communications, including email and attachments, sent across its networks filtered through anti virus and spam software programs and retain such messages in order to comply with applicable data security and retention requirements. Quantum is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt.