Re: [tcpm] Handling of malformed options

Fernando Gont <fernando@gont.com.ar> Wed, 01 July 2009 19:12 UTC

Return-Path: <fernando@gont.com.ar>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 448B828C531 for <tcpm@core3.amsl.com>; Wed, 1 Jul 2009 12:12:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.851
X-Spam-Level:
X-Spam-Status: No, score=-2.851 tagged_above=-999 required=5 tests=[AWL=0.748, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BaqPlZWCEDM1 for <tcpm@core3.amsl.com>; Wed, 1 Jul 2009 12:12:26 -0700 (PDT)
Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 6D13028C57F for <tcpm@ietf.org>; Wed, 1 Jul 2009 12:09:50 -0700 (PDT)
Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id C953D6B6673; Wed, 1 Jul 2009 16:10:12 -0300 (ART)
Received: from [192.168.0.138] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n61J9t3Q002499; Wed, 1 Jul 2009 16:09:56 -0300
Message-ID: <4A4BB48C.7070901@gont.com.ar>
Date: Wed, 01 Jul 2009 16:10:04 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Joe Touch <touch@ISI.EDU>
References: <C304DB494AC0C04C87C6A6E2FF5603DB2217B28763@NDJSSCC01.ndc.nasa.gov> <fc0ff13d0906241711k44de4f77u8ec825e1ea151a1e@mail.gmail.com> <4A4317ED.1040905@gont.com.ar> <4A48F60A.7020602@gmail.com> <4A49CA1A.6060702@gont.com.ar> <4A4A2A73.0@isi.edu> <4A4A5019.1080004@gont.com.ar> <4A4A5D02.2000402@isi.edu> <4A4B90F5.5060300@gont.com.ar> <4A4BA3BF.2020402@isi.edu>
In-Reply-To: <4A4BA3BF.2020402@isi.edu>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Wed, 01 Jul 2009 16:10:08 -0300 (ART)
Cc: Matt Mathis <mathis@psc.edu>, "tcpm-chairs@tools.ietf.org" <tcpm-chairs@tools.ietf.org>, tcpm Extensions WG <tcpm@ietf.org>, Matt Mathis <matt.mathis@gmail.com>
Subject: Re: [tcpm] Handling of malformed options
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jul 2009 19:12:27 -0000

Hello, Joe,

>>> Why don't you drop the segment or send a RST?
>> draft-gont-tcp-security recommends to silently drop the segment, *NOT*
>> to silently ignore the option.
> 
> OK, but why not make a more general recommendation for all options in
> this regard? 

Yes, I guess that such a general recommendation would make sense. The
reason for which I repeated this recommendation separately for each
option is that I wanted the option-specific checks to be within their
respective sections.

Had I made a general recommendation, it would have been something like
"if the option-length doesn't match the expected option length, the
corresponding segment should be silently dropped". But then that would
require the implementer to go back to the spec to check which value
should be checked, etc. Also, for some options there's more than one
check that you should perform on the option length (e.g., see SACK).

That said, there *is* a Section (3.10) with general recommendations for
handling TCP options. So I guess that one could keep the option-specific
checks in each of the different sections, but also add a general
recommendation in Section 3.10.. I have no problem with that.



> And why does the doc not indicate that this does differ
> from what is widely deployed, and discuss that issue?

It's just missing. As I said, I'm not saying there is not room for
improvement. And I agree that this discussion that you are suggesting
should be incorporated in the document (i.e., will do).



> Let's look at one other:
> 
> 3.6.7 present Ramaiah's suggestions on RST handling, but lacks the
> advice on which components were already standard (silently dropping RSTs
> out of window) 

Well, isn't this the case for any TCP segment? In-window checks are a
required part of RFC 793 itself. That's why I didn't include it here
explicitly.



> and the conditions under which Ramaiah's extensions are
> recommended.

Well, the document is about improving TCP's resiliency/security.
Therefore, it is assumed that at least from that pov, you will implement
Ramaiah's extensions.

Are are you meaning that I should state that IETF-wise, Ramaiah's
extensions come with an applicability statement, etc.?



> I continue to believe the doc needs a scrub on this point.
[...]

This may be necessary. However, I think the wg is currently making a
more meta-level decision, i.e., whether to adopt draft-gont-tcp-security
as a wg item.

That said, I have no problem with working on this particular point
you've raised.

Thanks!

Kind regards,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1