[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.
- [ietf-privacy] PPM Review of RFC 1108 Christian Huitema
- Re: [ietf-privacy] PPM Review of RFC 1108 Christian Huitema
- Re: [ietf-privacy] PPM Review of RFC 1108 S Moonesamy
- Re: [ietf-privacy] PPM Review of RFC 1108 Christian Huitema
- Re: [ietf-privacy] PPM Review of RFC 1108 S Moonesamy
- [ietf-privacy] PPM Review of RFC 1108 Christian Huitema
- Re: [ietf-privacy] PPM Review of RFC 1108 Stephen Farrell
- Re: [ietf-privacy] PPM Review of RFC 1108 David Singer
- Re: [ietf-privacy] PPM Review of RFC 1108 Elwyn Davies
- Re: [ietf-privacy] PPM Review of RFC 1108 Stephen Farrell