Re: [Hipsec] Using Next Header with IPv6

Tom Henderson <tomhend@u.washington.edu> Fri, 09 September 2016 22:44 UTC

Return-Path: <tomhend@u.washington.edu>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50D4F12B27B for <hipsec@ietfa.amsl.com>; Fri, 9 Sep 2016 15:44:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
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 y_mlQSwGXkza for <hipsec@ietfa.amsl.com>; Fri, 9 Sep 2016 15:44:06 -0700 (PDT)
Received: from mxout22.s.uw.edu (mxout22.s.uw.edu [128.95.242.222]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF9BA12B269 for <hipsec@ietf.org>; Fri, 9 Sep 2016 15:44:06 -0700 (PDT)
Received: from hymn01.u.washington.edu (hymn01.u.washington.edu [140.142.9.110]) by mxout22.s.uw.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u89MeM9b013084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Sep 2016 15:40:22 -0700
Received: from hymn01.u.washington.edu (localhost [127.0.0.1]) by hymn01.u.washington.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u89MeHUC028191; Fri, 9 Sep 2016 15:40:17 -0700
Received: from localhost (Unknown UID 21258@localhost) by hymn01.u.washington.edu (8.14.4+UW14.03/8.14.4+Submit-local) with ESMTP id u89MeHSM028182; Fri, 9 Sep 2016 15:40:17 -0700
X-Auth-Received: from [73.140.18.44] by hymn01.u.washington.edu via HTTP; Fri, 09 Sep 2016 15:40:17 PDT
Date: Fri, 9 Sep 2016 15:40:17 -0700 (PDT)
From: Tom Henderson <tomhend@u.washington.edu>
To: Robert Moskowitz <rgm@htt-consult.com>
Message-ID: <alpine.LRH.2.01.1609091540170.29178@hymn01.u.washington.edu>
User-Agent: Web Alpine 2.01 (LRH 1302 2010-07-20)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Transfer-Encoding: 8BIT
X-PMX-Version: 6.2.1.2493963, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.9.9.223616
X-PMX-Server: mxout22.s.uw.edu
X-Uwash-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1900_1999 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, LEGITIMATE_NEGATE 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, MULTIPLE_REAL_RCPTS 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_CC_HDR 0, __HAS_FROM 0, __HAS_MSGID 0, __HTTPS_URI 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MULTIPLE_URI_TEXT 0, __PHISH_PHRASE1_B 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __TO_NAME 0, __TO_NAME_DIFF_FROM_ACC 0, __TO_REAL_NAMES 0, __URI_IN_BODY 0, __URI_NS , __URI_WITH_PATH 0, __USER_AGENT 0'
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/I3xQ1bO8ZgiOejH6IRpNVZ7yzEU>
Cc: hipsec@ietf.org
Subject: Re: [Hipsec] Using Next Header with IPv6
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.17
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/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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: Fri, 09 Sep 2016 22:44:08 -0000


On 09/08/2016 01:16 PM, Robert Moskowitz wrote:
> This is more to implementors or people that understand network stacks...
> 
> We provided in 7401 a Next Header field as all good IPv6 payloads are
> suppose to do.  But we really have not used it in front of 'real' IPv6
> payloads like ESP, TCP, UDP, or IPnIP.  Or have we and I have just
> missed it?

The HICCUPS RFC describes a use of it.
https://tools.ietf.org/html/rfc6078

> 
> Anyway this is for faster mobility; looking at 5206-bis and IF the
> payload is small enough to fit in a HIP UPDATE, to send the Mobility
> UPDATE along with the actual first data from the moving host.
> 
> This question is primarily 'will the stack handle this'?  That is, HIP
> gets to payload first.  If validates the UPDATE, changes the necessary
> bindings the either:
> 
>     pushes a revised frame without the HIP UPDATE back into the IP
> interface
>     or sends the Next Header off to where it belongs.
> 
> I am not a person that has dealt with the insides of the OS(s) to know
> how this would be done or if it is really practical.

The data plane for HIP-supported sessions can be implemented in userspace
or kernel (reusing kernel IPsec handling). If purely userspace (all packets
are shunted to userspace) it seems like it would not be terribly difficult
to do.  If kernel space handling such as Linux XFRM, I'm guessing that a
stack modification would be needed.

> 
> Oh, and what is the length of the basic HIP UPDATE in 5206-bis?  I can
> do my best calculation in a bit, but if someone has it...

HIP header 40 bytes
ESP_INFO 16 bytes
LOCATOR_SET (minimal) ~32 bytes
SEQ parameter 8 bytes

so on the order of 96 bytes; more if more than one locator involved


> 
> thanks
> 
> Bob
> 
> _______________________________________________
> Hipsec mailing list
> Hipsec@ietf.org
> https://www.ietf.org/mailman/listinfo/hipsec