[Hipsec] draft-ietf-v6ops-cpe-simple-security last call

Robert Moskowitz <rgm@htt-consult.com> Tue, 20 April 2010 13:43 UTC

Return-Path: <rgm@htt-consult.com>
X-Original-To: hipsec@core3.amsl.com
Delivered-To: hipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7837B28C148 for <hipsec@core3.amsl.com>; Tue, 20 Apr 2010 06:43:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.39
X-Spam-Level:
X-Spam-Status: No, score=-0.39 tagged_above=-999 required=5 tests=[AWL=-0.991, BAYES_50=0.001, J_CHICKENPOX_13=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 513EtJb3wJPA for <hipsec@core3.amsl.com>; Tue, 20 Apr 2010 06:43:43 -0700 (PDT)
Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 6D1BD3A6A9A for <hipsec@ietf.org>; Tue, 20 Apr 2010 06:43:42 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 99BE468D16 for <hipsec@ietf.org>; Tue, 20 Apr 2010 13:37:53 +0000 (UTC)
Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tk9NM0bLrJF0 for <hipsec@ietf.org>; Tue, 20 Apr 2010 09:37:43 -0400 (EDT)
Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 80FFF68D2C for <hipsec@ietf.org>; Tue, 20 Apr 2010 09:37:39 -0400 (EDT)
Message-ID: <4BCDAF74.9090600@htt-consult.com>
Date: Tue, 20 Apr 2010 09:43:16 -0400
From: Robert Moskowitz <rgm@htt-consult.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4
MIME-Version: 1.0
To: HIP <hipsec@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [Hipsec] draft-ietf-v6ops-cpe-simple-security last call
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hipsec>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Apr 2010 13:43:44 -0000

This ID is in last call, and we kind of screwed up NOT getting on their 
plate long ago.

But I spoke with James Woodyatt at IETF 77 and he just said to send in 
REAL text during last call.  Here is the message I just posted to ipv6ops:

=====================================================================

I discussed this briefly with James during IETF 77.

HIP is on track to be reved for standards track.  It is assigned 
Protocol number 139, and should be treated by cpe-simple-security the 
same as IKE.  I will offer my best effort at text below.

I apologize for the few week delay, Passover came RIGHT after IETF.  And 
I SUPPOSE I should have pushed this 6 months ago while we were pushing 
to get HIP moving towards standards.  But that is water under the bridge...

On 03/29/2010 05:43 PM, james woodyatt wrote:
> concerned--
>
> This is to inform the chairs of the V6OPS working group that it is the 
> sense of the editor of draft-ietf-v6ops-cpe-simple-security and the 
> design team that worked most closely on it during its development, 
> that the latest posted revision, i.e. -10, is ready for Working Group 
> Last Call.

In sec 2.2 add at the end of the para:

HIP is also explicitly secured by definition, so this document 
recommends the DEFAULT operating mode permit Host Identity Protocol 
(HIP) flows to pass without filtering.

Add sec 3.2.6:

3.2.6  Host Identity Protocol (HIP)

Host Identity Protocol (HIP) offers greater flexibility and better 
overall security than the simple security of stateful packet filtering 
at network perimeters.  Therefore, residential IPv6 gateways need not 
prohibit HIP traffic flows.

REC-nn: In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit 
the forwarding of packets, to and from legitimate node addresses, with 
destination extension headers of type "Host Identity Protocol (HIP)" 
[RFC5201] in their outer IP extension header chain.

{note here, 5201-bis exists, but it will take a few months to finish 
this (we are NOT expecting a long process to add the agreed changes to 
5201).  The new RFC will be tagged as Standard, but will use the same 
protocol number.}

REC-nn: In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit 
the forwarding of packets, to and from legitimate node addresses, with 
an upper layer protocol of type "Encapsulating Security Payload (ESP)" 
[RFC4303] in their outer IP extension header chain.

{note this is the same text as REC-21, as HIP uses ESP in TRANSPORT mode.}

{note:  There is no easy equivalence of REC-23 with HIP due to its 
mobility.  In RFC 5206 we cover mobility and mid-box updating of moves.  
But do you want that here?  In HIP the SPI is all you can count on, as 
the IP address pair are mutable during the life of the SPI.}

In sec 8.1 add:

RFC 5201

Thank you.

====================================================================