Re: [ietf-privacy] PPM Review of RFC 1108

"Christian Huitema" <huitema@huitema.net> Thu, 22 May 2014 04:18 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: ietf-privacy@ietfa.amsl.com
Delivered-To: ietf-privacy@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07FC41A00B8 for <ietf-privacy@ietfa.amsl.com>; Wed, 21 May 2014 21:18:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EH0-QS1bVZkU for <ietf-privacy@ietfa.amsl.com>; Wed, 21 May 2014 21:18:38 -0700 (PDT)
Received: from xsmtp05.mail2web.com (xsmtp05.mail2web.com [168.144.250.245]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2192B1A00B0 for <ietf-privacy@ietf.org>; Wed, 21 May 2014 21:18:38 -0700 (PDT)
Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1WnKQO-0001DW-KJ for ietf-privacy@ietf.org; Thu, 22 May 2014 00:18:36 -0400
Received: (qmail 24878 invoked from network); 22 May 2014 04:16:11 -0000
Received: from unknown (HELO HUITEMA5) (Authenticated-user:_huitema@huitema.net@[72.235.170.205]) (envelope-sender <huitema@huitema.net>) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for <ietf-privacy@ietf.org>; 22 May 2014 04:16:11 -0000
From: "Christian Huitema" <huitema@huitema.net>
To: <ietf-privacy@ietf.org>
References: <02e501cf7573$c123ee40$436bcac0$@huitema.net>
In-Reply-To: <02e501cf7573$c123ee40$436bcac0$@huitema.net>
Date: Wed, 21 May 2014 21:16:10 -0700
Message-ID: <02ff01cf7574$90a74090$b1f5c1b0$@huitema.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0300_01CF7539.E44B00A0"
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQFMUPUaKyB5ggW/pZrOYoQHCxMSdJxSRqVg
Content-Language: en-us
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf-privacy/jZ0uX-bQvhPmKGfqEaYLvnoYByg
Subject: Re: [ietf-privacy] PPM Review of RFC 1108
X-BeenThere: ietf-privacy@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Internet Privacy Discussion List <ietf-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-privacy>, <mailto:ietf-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-privacy/>
List-Post: <mailto:ietf-privacy@ietf.org>
List-Help: <mailto:ietf-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-privacy>, <mailto:ietf-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 May 2014 04:18:40 -0000

That was my attempt at using the random lottery. I like using the issue page
better for input. Also, I prefer reading the html version of the RFC from
the IETF tools page. Maybe the lottery should just give you a suggestion of
an RFC number…

 

From: ietf-privacy [mailto:ietf-privacy-bounces@ietf.org] On Behalf Of
Christian Huitema
Sent: Wednesday, May 21, 2014 9:10 PM
To: ietf-privacy@ietf.org
Subject: [ietf-privacy] PPM Review of RFC 1108

 

This RFC defines an IP header option for "security options." The options
enable hosts to mark their traffic as belonging to a particular security
level. Presumably, secure routers will ensure that traffic marked with a
specific security option is contained within a network that meets the
corresponding security requirements.

The RFC was written in 1988, before we started writing security
considerations in RFC. A security consideration section would probably have
listed the two major issues with the option, use by unauthorized hosts and
use in unsecure networks.

If a network allows for traffic from both secure and unsecure sources,
unsecure sources can easily insert spoof IP addresses and insert options in
the IP header. This could be used for sending attack packets to secure
system, despite attempts at compartmenting the network. Ping of death and
variants come to mind.

A mobile host that is allowed to send secure traffic may inadvertently visit
an insecure network. In that case, using the option provides for easy
identification of the host as a potential target. Mobile hosts were not
common in 1988, and this threat was not envisaged in the RFC.

This was then. By now, IP options are very rarely used. The RFC should
probably be reclassified as historic.