[ietf-privacy] PPM Review of RFC 1108

"Christian Huitema" <huitema@huitema.net> Thu, 22 May 2014 04:10 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 618FC1A00B7 for <ietf-privacy@ietfa.amsl.com>; Wed, 21 May 2014 21:10:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level:
X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 peUmX6V_hztA for <ietf-privacy@ietfa.amsl.com>; Wed, 21 May 2014 21:10:27 -0700 (PDT)
Received: from xsmtp02.mail2web.com (xsmtp22.mail2web.com [168.144.250.185]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 467A51A00B0 for <ietf-privacy@ietf.org>; Wed, 21 May 2014 21:10:27 -0700 (PDT)
Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1WnKKm-00027O-LK for ietf-privacy@ietf.org; Thu, 22 May 2014 00:10:25 -0400
Received: (qmail 32759 invoked from network); 22 May 2014 04:10:23 -0000
Received: from unknown (HELO HUITEMA5) (Authenticated-user:_huitema@huitema.net@[72.235.170.205]) (envelope-sender <huitema@huitema.net>) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for <ietf-privacy@ietf.org>; 22 May 2014 04:10:23 -0000
From: Christian Huitema <huitema@huitema.net>
To: ietf-privacy@ietf.org
References:
In-Reply-To:
Date: Wed, 21 May 2014 21:10:22 -0700
Message-ID: <02e501cf7573$c123ee40$436bcac0$@huitema.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_02E6_01CF7539.14C6EB00"
X-Mailer: Microsoft Outlook 15.0
Thread-Index: Ac91LXQu4IQ46U1mQbeMFs6RpIxfaAARiuGA
Content-Language: en-us
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf-privacy/KO7w-rP8CzW3oRPZrra3EIrbrmQ
Subject: [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:10:29 -0000

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.