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

"Klaas Wierenga (kwiereng)" <kwiereng@cisco.com> Wed, 30 May 2012 18:50 UTC

Return-Path: <kwiereng@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A81411E80B6; Wed, 30 May 2012 11:50:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.78
X-Spam-Level:
X-Spam-Status: No, score=-6.78 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067, SARE_SUB_6CONS_WORD=0.356]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfSb4FMS0lys; Wed, 30 May 2012 11:50:46 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 8385311E8098; Wed, 30 May 2012 11:50:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kwiereng@cisco.com; l=3990; q=dns/txt; s=iport; t=1338403845; x=1339613445; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=HUGuqIhzlnNtpU5gJQRz/OpzYFdQx7UZHVD+eb7FyI4=; b=lXpZ87sFYC6kx+VsAT7aR5zzXV502VAiGjQEvaL9Ql+pK/UGyVSoyik/ jf3RbSl2B+Zt4t4aA+fb23vwSZFN56TzdzZ0HFRBXwyVycGcJsB9CMa1l y6CUGVGWMpiR/YfnTjov/0VyBSHxYzBVO4n68IzQVlRTMnLdT7kqb9o1Q o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhcHANZqxk+Q/khN/2dsb2JhbABEigaqCQKBB4IXAQEBAwESASc/BQsCAQgYLlcBAQQTIodkBZkyn3aLBRWEUWADlRiODSeBP4JigVUI
X-IronPort-AV: E=Sophos;i="4.75,686,1330905600"; d="scan'208";a="73828446"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 30 May 2012 18:50:42 +0000
Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q4UIogab022950; Wed, 30 May 2012 18:50:42 GMT
Received: from xmb-ams-101.cisco.com ([144.254.74.76]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 May 2012 20:50:41 +0200
Received: from 144.254.74.76 ([144.254.74.76]) by XMB-AMS-101.cisco.com ([144.254.74.76]) with Microsoft Exchange Server HTTP-DAV ; Wed, 30 May 2012 18:50:41 +0000
References: <4FC63731.7060409@cisco.com> <58B9B09F-ECA8-457E-B22C-34CE7A69CCFA@quantum.com> <B00101B3-C986-4283-87D4-EA125860F1C6@cisco.com> <EF0B56D9-99F2-49D0-AE22-457E6E1A7944@quantum.com>
Content-Transfer-Encoding: quoted-printable
From: "Klaas Wierenga (kwiereng)" <kwiereng@cisco.com>
Thread-Topic: secdir review of draft-ietf-tcpm-tcpmss-04
Thread-Index: Ac0+lRyHuZ+Gs4+uQ/K+RUrpYhx/zQ==
Content-Type: text/plain; charset="us-ascii"
In-Reply-To: <EF0B56D9-99F2-49D0-AE22-457E6E1A7944@quantum.com>
Message-ID: <B03F5033-542E-46F3-9A3F-25EAEA0CCA98@cisco.com>
Date: Wed, 30 May 2012 20:50:41 +0200
To: "David Borman" <David.Borman@quantum.com>
MIME-Version: 1.0 (1.0)
X-OriginalArrivalTime: 30 May 2012 18:50:41.0791 (UTC) FILETIME=[1CCDC8F0:01CD3E95]
Cc: draft-ietf-tcpm-tcpmss.all@tools.ietf.org, The IESG <iesg@ietf.org>, secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-tcpm-tcpmss-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 May 2012 18:50:47 -0000

David,

Your suggestion looks fine to me!

Klaas

Sent from my iPad

On 30 mei 2012, at 20:20, "David Borman" <David.Borman@quantum.com>; wrote:

> Klaas,
> 
> On May 30, 2012, at 12:39 PM, Klaas Wierenga (kwiereng) wrote:
>> On 30 mei 2012, at 19:29, "David Borman" <David.Borman@quantum.com>; wrote:
>>> On May 30, 2012, at 10:05 AM, Klaas Wierenga wrote:
> ...
>>>> - - "(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.
>> 
>> 
>> Ah, I thought you had listed all confusion in appendix A. Since that does not seem to be the case, can you say anything about the nature of the remaining confusion?
> 
> How about:
>    RFC 1122 [RFC1122] clarified the MSS option, which is discussed in
>    Appendix A, but because it didn't explicitly state how options
>    should be handled, 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..
>> 
>> Great minds..... ;-)
>> 
>>> 
>>>> 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.
>> 
>> I don't feel comfortable with a security consideration that isn't, so I would lean towards your alternative proposal.
> 
> Ok, I'll move the content to section 5, and leave "Security Considerations"
> empty, unless someone else objects to making that change.
> 
>            -David Borman
> 
> ----------------------------------------------------------------------
> 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.