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

David Singer <singer@apple.com> Thu, 22 May 2014 13:36 UTC

Return-Path: <singer@apple.com>
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 388271A0147 for <ietf-privacy@ietfa.amsl.com>; Thu, 22 May 2014 06:36:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.851
X-Spam-Level:
X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 iRZzGUjT79o9 for <ietf-privacy@ietfa.amsl.com>; Thu, 22 May 2014 06:36:34 -0700 (PDT)
Received: from mail-in3.euro.apple.com (mail-in3.euro.apple.com [17.72.148.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7E581A001A for <ietf-privacy@ietf.org>; Thu, 22 May 2014 06:36:33 -0700 (PDT)
Received: from relay2.euro.apple.com ( [17.66.55.12]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail-in3.euro.apple.com (Symantec Mail Security) with SMTP id 22.D5.07340.E5DFD735; Thu, 22 May 2014 14:36:30 +0100 (BST)
X-AuditID: 1148940d-f79b96d000001cac-72-537dfd5e5d79
Received: from phonehome2 ( [17.72.133.82]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay2.euro.apple.com (Symantec Mail Security) with SMTP id F7.BD.07310.E5DFD735; Thu, 22 May 2014 14:36:30 +0100 (BST)
Received: from [192.168.0.27] ([151.42.15.61]) by phonehome2.euro.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0N5Z00BND9SQ1N20@phonehome2.euro.apple.com> for ietf-privacy@ietf.org; Thu, 22 May 2014 14:36:30 +0100 (IST)
Content-type: multipart/alternative; boundary=Apple-Mail-7BEEE6AF-7F98-4157-8FB2-0594A9B002F1
Content-transfer-encoding: 7bit
From: David Singer <singer@apple.com>
MIME-version: 1.0 (1.0)
Date: Thu, 22 May 2014 15:10:17 +0200
Message-id: <19D65F06-1335-4BC2-9604-A97F6353468C@apple.com>
References: <23b0454ae57f4350b49feaf42ecdb19f@BLUPR03MB424.namprd03.prod.outlook.com>
In-reply-to: <23b0454ae57f4350b49feaf42ecdb19f@BLUPR03MB424.namprd03.prod.outlook.com>
To: Christian Huitema <huitema@microsoft.com>
X-Mailer: iPad Mail (11D201)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUi6GTOoxv3tzbY4PtXa4vDVxvYHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV0TNzJ3vBAoOKzu0bGBsY32t2MXJySAiYSPR8O80EYYtJXLi3 nq2LkYtDSGAik8TmdYfYYIqO7FrODpFoYpK4OWMzI4Qzl0ni3ZUJLCBVzALxEsdWd7FC2PIS m9e8ZQax2QRUJR7MOcYIYvMKiEu8PjoFzBYWMJL4+PcsUD0HBwtQzYKFshAlNhJ3OmeCtQoJ hEu0P1rHDDHSWGLBlD6wVk6BCInHF2eBHScioCuxr+Ug2BgJARmJJ5+VIW5ewibx9nj0BEbh WUiOm4XkuFlIDpoF1M0soCMxeSEjRIm2xLKFr5khbA2Jzm8T4Vq3v53DvICRfRWjeG5iZo5u Zp6xXmppUb5eYkFBTqpecn7uJkZQtHhM4d3BeP2g4SFGAQ5GJR7equ+1wUKsiWXFlbmHGCU4 mJVEeOf/AgrxpiRWVqUW5ccXleakFh9ilOZgURLnPXPBLVhIID2xJDU7NbUgtQgmy8TBKdXA yLHpgPapskPzmXsdOVwX9u14Fr+SRXVaQc+U2nKRuP1XZC+KrVRKZ9Mxd9ku92IDX/u/N4wN CUHCvyf9ZT/bGP7weL/Hgdm7Fx60TTOocln1ZH3C7qdn85ZVC8tc/1IxMejkFYuHLwS1VPXn Tc0/nhZ9l+9ctHvxTL2fYtynj+trPTztdCqsWomlOCPRUIu5qDgRAIm9hfaSAgAA
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUi6NEapBv3tzbYYOskS4vDVxvYHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV0TNzJ3vBAoOKzu0bGBsY32t2MXJySAiYSBzZtZwdwhaTuHBv PVsXIxeHkEATk8TNGZsZIZy5TBLvrkxgAaliFoiXOLa6ixXClpfYvOYtM4jNJqAq8WDOMUYQ m1dAXOL10SlgtrCAkcTHv2eB6jk4WIBqFiyUhSixkbjTOROsVUggXKL90TpmiJHGEgum9IG1 cgpESDy+OIsNxBYR0JXY13IQbIyEgIzEk8/KExgFZiE5aBaSg2YhOWIWUAezgI7E5IWMECXa EssWvmaGsDUkOr9NhGvd/nYO8wJG9lWMokWpOYmVRnqppUX5eokFBTmpesn5uZsYQeHtZM6z g/HVQcNDjAIcjEo8vC3fa4OFWBPLiitzDzFKcDArifDO/wUU4k1JrKxKLcqPLyrNSS0+xCjN waIkzrtlt2GwkEB6YklqdmpqQWoRTJaJg1OqgZHxrOYcT65mO6b/dd+Nz2r+PhMXGtq+WfCt 2PyUQJ0GMYZZ5mVeZx7zM6kGnFKY+rbTz/nQtZXys63W5/82Vn1m9e9tu8bthvNPZvwSCCxn +yLQrRe9n2nNzcVvbH5dESx+XHdz55SzG9fmbjKLNeGTeSaZwvjVi+eDwvaSmJeBfgf32j+M E1diKc5INNRiLipOBACTV7pWawIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf-privacy/jPg6p_bqtVu55AU0CqQWoTZUZ6Q
Cc: "ietf-privacy@ietf.org" <ietf-privacy@ietf.org>
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 13:36:37 -0000


Sent from my iPad

> On May 21, 2014, at 9:47 PM, Christian Huitema <huitema@microsoft.com> wrote:
> 
> 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.
> 

And the security implications of a "look at me!" flag?
> 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.
> 

Or worse...

> _______________________________________________
> ietf-privacy mailing list
> ietf-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-privacy