Re: [Hipsec] Kathleen Moriarty's No Objection on draft-ietf-hip-multihoming-11: (with COMMENT)

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Wed, 21 September 2016 01:39 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.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 6331212B4D9; Tue, 20 Sep 2016 18:39:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 NFvXjDSkiff4; Tue, 20 Sep 2016 18:39:02 -0700 (PDT)
Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36C8D12B178; Tue, 20 Sep 2016 18:39:02 -0700 (PDT)
Received: by mail-yb0-x233.google.com with SMTP id 2so12937000ybv.0; Tue, 20 Sep 2016 18:39:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2+j8MIoEfD4gpcKcm9vZTF4AKbYXqLIEPK9U+9/QyrI=; b=tUfmTLmsr2CRreuFKDIh+fcH9MBUrniC6K/EyVFcGD400qaJ4VgkKGKR53Xc4c4PZk /GPQ1VTUw5DzfIJkyWHZcOMsfE9vexBg1/xuxdKcjxUcq2MHjrznth2BrxQYyel1B9I/ iFS/R8QrL+XcFFhraD2pYPRKcERC6i2U8TwNhJrCZwDJGTgbfgUc1B1OVadI3aY9eeCK dZtyhmeylfqWEw+EYWMm1YKeqYdftUKyfShfUrt12H6nXxOY0o65Sy+9ek/aClgR2yzW 3+wzmtLzH9Tr2/4JqvMuvEa9d2zuqEWONPktUVSV9sbPecpSyYJAzHkVxnyb0tCMVyWo dTGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=2+j8MIoEfD4gpcKcm9vZTF4AKbYXqLIEPK9U+9/QyrI=; b=B0b5Hibd/zFDDL24CPVigCJZFWfVzcU9l6XNB1T+SEqsHvJdREUp3tPWepvDeeCwQm Z+Li76N0h6rr2lRy5dMdzCRrQvL7RzzeKQ/CTMXkFIn2U8uV7RpxXVVBv6jiEkW4zk8G f4J4oJEQupiQcwgyunqUey4xKZHpLy/e2c2VGGFJBICiDauArrtSqxrm9nRpzaz+ofLB 8wgKaXvAlUJHk2BJRk6fTz3Lo8UxpqDLj44nQ+Imiy/5uspwwoM0rYSw7+G2Wq0e6YZi Zax3XgWXxISLZEEoED4rpI8mqUGqc1VVJEl9dL+gCbDdiIDZsKZCJ8s2yU++qkHLr20E PWvA==
X-Gm-Message-State: AE9vXwPws9Iral5haW75Z811mPExOxo6t/d0p9r869t3BODq0AWsYFmulhjq75G0WZFm9hM+CNTVO277eLZN0A==
X-Received: by 10.37.64.65 with SMTP id n62mr20859405yba.85.1474421941491; Tue, 20 Sep 2016 18:39:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.65.8 with HTTP; Tue, 20 Sep 2016 18:39:01 -0700 (PDT)
In-Reply-To: <alpine.LRH.2.01.1609180955270.32623@hymn04.u.washington.edu>
References: <alpine.LRH.2.01.1609180955270.32623@hymn04.u.washington.edu>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Tue, 20 Sep 2016 21:39:01 -0400
Message-ID: <CAHbuEH5Ti=EQY0EMcZ8Z-Pp7zMfnwJZVfRkGDNJAyWgL+aQHgw@mail.gmail.com>
To: Tom Henderson <tomhend@u.washington.edu>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/ZyvUhhfkVuL0Ul28kUwOBFEyIrY>
Cc: draft-ietf-hip-multihoming@ietf.org, hip-chairs@ietf.org, The IESG <iesg@ietf.org>, hipsec@ietf.org
Subject: Re: [Hipsec] Kathleen Moriarty's No Objection on draft-ietf-hip-multihoming-11: (with COMMENT)
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: Wed, 21 Sep 2016 01:39:04 -0000

Hi Tom,


On Sun, Sep 18, 2016 at 12:55 PM, Tom Henderson
<tomhend@u.washington.edu> wrote:
> Hi Kathleen, thank you for your comment.
>
> On 09/13/2016 12:22 PM, Kathleen Moriarty wrote:
>> Kathleen Moriarty has entered the following ballot position for
>> draft-ietf-hip-multihoming-11: No Objection
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> I'm wondering if split-tunneling should be listed as a security
>> consideration.  I see the following in section 4.1 that might be used to
>> help prevent split tunneling:
>>    In the outbound direction, as a result of SPD processing, when
>>    an outbound SA is selected, the correct IP destination address for
>>    the peer must also be assigned.
>>
>> Then also the entirety of section 4.3.
>>
>> I read this as split tunneling could be an issue in some circumstances
>> depending on policy and it might be good to mention this in the security
>> considerations section.  Or let me know if I am missing some background
>> that would prevent split tunneling so implementers don't need to be made
>> aware of this consideration.
>
> From my recollection, support (or prevention) of split tunneling was not a consideration of these parts of the text.  The first sentence you quote from 4.1 was intended as a hint to implementers that there is this additional level of indirection with HIP that must be managed (mapping of SA to IP address) when multihoming is in use.  Section 4.3 is mainly about how to manage the possibly large number of valid SA configurations that could arise from multihoming.
>
> My understanding of the common use of the term 'split tunneling' is that it pertains to VPN tunnel situations where some set of connections should be tunneled but others not.  In HIP, the security association is end-to-end and the same VPN scenario is not applicable, so by split tunnel, do you mean that some transport sessions between two hosts are within HIP/ESP protection and others not?

Thanks for your response.  Yes, I was poking to see if there was a
possibility of leakage to an unintended destination when multi-homing
was in place, like what is possible with split tunneling.  It might
not be split tunneling exactly, but if leakage is possible, it would
be good to note that as a consideration.

Thanks,
Kathleen

>
> - Tom
>
>
>
>



-- 

Best regards,
Kathleen