Re: [Hipsec] Using Next Header with IPv6

Jeff Ahrenholz <j.ahrenholz@temperednetworks.com> Tue, 20 September 2016 15:46 UTC

Return-Path: <j.ahrenholz@temperednetworks.com>
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 3EA6B12B21B for <hipsec@ietfa.amsl.com>; Tue, 20 Sep 2016 08:46:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 OcKREN0UH6eE for <hipsec@ietfa.amsl.com>; Tue, 20 Sep 2016 08:46:41 -0700 (PDT)
Received: from out.west.exch081.serverdata.net (cas081-co-1.exch081.serverdata.net [199.193.204.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29F7512B0CC for <hipsec@ietf.org>; Tue, 20 Sep 2016 08:46:41 -0700 (PDT)
Received: from MBX081-W5-CO-2.exch081.serverpod.net (10.224.129.85) by MBX081-W5-CO-1 (10.224.129.84) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 20 Sep 2016 08:46:39 -0700
Received: from MBX081-W5-CO-2.exch081.serverpod.net ([10.224.129.85]) by MBX081-W5-CO-2.exch081.serverpod.net ([10.224.129.85]) with mapi id 15.00.1178.000; Tue, 20 Sep 2016 08:46:39 -0700
From: Jeff Ahrenholz <j.ahrenholz@temperednetworks.com>
To: Tom Henderson <tomhend@u.washington.edu>, Robert Moskowitz <rgm@htt-consult.com>
Thread-Topic: [Hipsec] Using Next Header with IPv6
Thread-Index: AQHSCusji+yjMNngbUqn2BWXVVqMYKCCloQA
Date: Tue, 20 Sep 2016 15:46:39 +0000
Message-ID: <5A75F2FB-2131-49AA-A662-68F9AA213252@temperednetworks.com>
References: <alpine.LRH.2.01.1609091540170.29178@hymn01.u.washington.edu>
In-Reply-To: <alpine.LRH.2.01.1609091540170.29178@hymn01.u.washington.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [216.168.34.194]
Content-Type: multipart/mixed; boundary="_002_5A75F2FB213149AAA66268F9AA213252temperednetworkscom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/uQh2-2sVNJAx9R2UwVmS_OLQcnU>
Cc: "hipsec@ietf.org" <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: Tue, 20 Sep 2016 15:46:43 -0000

Hi Bob,
Adding to Tom’s comments...

>> 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

Yes, we haven’t really been using the Next Header field for payloads.
    
>> 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.

We’re using a userspace implementation plus UDP encapsulation.

So one UDP socket receives the port 10500 traffic. Both HIP control packets (having SPI=0) and ESP packets are received and demuxed on this socket. So it would be fairly straightforward to pick off an UPDATE and then process the ESP data that follows it.

If we were not using UDP encaps then yes it seems you’d have to write a new frame back to the stack.
    
>> 
>> 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

Here is what we have for an IPv4 re-address event over UDP. Attached is a pcap file (you can open in Wireshark).

The three UPDATE packets are 302, 286, 262 bytes in length. They look like this:
UPDATE(ESP_INFO, LOCATOR, SEQ, HMAC, HIP_SIGNATURE)
UPDATE(ESP_INFO, SEQ, ACK, HMAC, HIP_SIGNATURE, ECHO_REQUEST_UNSIGNED)
UPDATE(ESP_INFO, ACK, HMAC, HIP_SIGNATURE, ECHO_RESPONSE_UNSIGNED)

-Jeff