[ietf-privacy] PPM Review of RFC 1108

Christian Huitema <huitema@microsoft.com> Wed, 21 May 2014 19:47 UTC

Return-Path: <huitema@microsoft.com>
X-Original-To: ietf-privacy@ietfa.amsl.com
Delivered-To: ietf-privacy@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 6278F1A0850 for <ietf-privacy@ietfa.amsl.com>; Wed, 21 May 2014 12:47:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Q5Li9-i2ioWt for <ietf-privacy@ietfa.amsl.com>; Wed, 21 May 2014 12:47:25 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0242.outbound.protection.outlook.com []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35C0E1A0830 for <ietf-privacy@ietf.org>; Wed, 21 May 2014 12:47:25 -0700 (PDT)
Received: from BLUPR03MB424.namprd03.prod.outlook.com ( by BLUPR03MB423.namprd03.prod.outlook.com ( with Microsoft SMTP Server (TLS) id 15.0.944.11; Wed, 21 May 2014 19:47:23 +0000
Received: from BLUPR03MB424.namprd03.prod.outlook.com ([]) by BLUPR03MB424.namprd03.prod.outlook.com ([]) with mapi id 15.00.0944.000; Wed, 21 May 2014 19:47:23 +0000
From: Christian Huitema <huitema@microsoft.com>
To: "ietf-privacy@ietf.org" <ietf-privacy@ietf.org>
Thread-Topic: PPM Review of RFC 1108
Thread-Index: Ac91LXQu4IQ46U1mQbeMFs6RpIxfaA==
Date: Wed, 21 May 2014 19:47:22 +0000
Message-ID: <23b0454ae57f4350b49feaf42ecdb19f@BLUPR03MB424.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-forefront-prvs: 0218A015FA
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(189002)(199002)(19580395003)(92566001)(19300405004)(16236675002)(21056001)(77096999)(33646001)(83322001)(77982001)(19625215002)(86612001)(81342001)(81542001)(46102001)(86362001)(50986999)(74662001)(80022001)(31966008)(74502001)(87936001)(76576001)(54356999)(74316001)(15202345003)(76482001)(99396002)(64706001)(4396001)(15975445006)(20776003)(99286001)(85852003)(79102001)(101416001)(83072002)(2656002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB423; H:BLUPR03MB424.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (: microsoft.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=huitema@microsoft.com;
Content-Type: multipart/alternative; boundary="_000_23b0454ae57f4350b49feaf42ecdb19fBLUPR03MB424namprd03pro_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf-privacy/sP4Zq5vRSbjU8laQS6S2Ryo5W0E
X-Mailman-Approved-At: Thu, 22 May 2014 02:18:23 -0700
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: Wed, 21 May 2014 19:47:27 -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.