Re: [Hipsec] some comments for mm-03: including ESP-INFO in all (relevant) UPDATES

Miika Komu <miika@iki.fi> Mon, 10 April 2006 09:35 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSsnh-0002qh-Ff; Mon, 10 Apr 2006 05:35:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSsnf-0002qc-Rn for hipsec@ietf.org; Mon, 10 Apr 2006 05:35:11 -0400
Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSsne-0000kz-Gj for hipsec@ietf.org; Mon, 10 Apr 2006 05:35:11 -0400
Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 13B482E48; Mon, 10 Apr 2006 12:35:10 +0300 (EEST)
X-Spam-Checker-Version: SpamAssassin 3.1.1-niksula20060321 (2006-03-10) on twilight.cs.hut.fi
X-Spam-Level:
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.1-niksula20060321
X-Spam-Niksula: No
Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 7E6802E1A; Mon, 10 Apr 2006 12:35:09 +0300 (EEST)
Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id k3A9Z8J28697; Mon, 10 Apr 2006 12:35:08 +0300 (EEST)
Date: Mon, 10 Apr 2006 12:35:08 +0300
From: Miika Komu <miika@iki.fi>
X-X-Sender: mkomu@kekkonen.cs.hut.fi
To: Pekka Nikander <pekka.nikander@nomadiclab.com>
Subject: Re: [Hipsec] some comments for mm-03: including ESP-INFO in all (relevant) UPDATES
In-Reply-To: <2D12A2F5-80F5-42D9-AA54-289B62F3EC3D@nomadiclab.com>
Message-ID: <Pine.GSO.4.58.0604101220070.26662@kekkonen.cs.hut.fi>
References: <77F357662F8BFA4CA7074B0410171B6D01A2EFB1@XCH-NW-5V1.nw.nos.boeing.com> <Pine.GSO.4.58.0604081428130.17314@kekkonen.cs.hut.fi> <2D12A2F5-80F5-42D9-AA54-289B62F3EC3D@nomadiclab.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Cc: hipsec@ietf.org
X-BeenThere: hipsec@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/hipsec>
List-Post: <mailto:hipsec@lists.ietf.org>
List-Help: <mailto:hipsec-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@lists.ietf.org?subject=subscribe>
Errors-To: hipsec-bounces@lists.ietf.org

On Mon, 10 Apr 2006, Pekka Nikander wrote:

> >>>> Figure 6: Basic multihoming scenario
> >>>
> >>> Is the ECHO_RESPONSE 100 % sure way to map the last incoming
> >>> UPDATE to certain SA? Why don't we just include the ESP_INFO? If
> >>> this is the case, why don't we do also for the other use cases
> >>> for generality's sake.
> >>
> >> I had always thought that the HIP daemon would use the SEQs and
> >> ACKs to map these packets.  I do not have a problem with including
> >> ESP_INFO, either as a MUST or a MAY, to help implementors
> >> (although it would have to be treated as a protocol error if it
> >> didn't match the original ESP_INFO). What do other implementors
> >> think?
>
> > Now rethinking this again, base draft says "The Update ID has scope
> > within a single HIP association, and not across multiple
> > associations or multiple hosts.". As a result, the update ID should
> > be enough information to map the incoming packet to a SA.
> >
> > However, requiring the use of ESP_INFO in all UPDATE packets would
> > be at least systematical and implementor friendlier. Less indexing
> > required in the implementation. Maybe it is also better for
> > middleboxes.
>
> I could imagine privacy reasons why you may not want to add ESP_INFO
> in those UPDATE packets that you use to verify address reachability.
> Not particularly strong privacy reasons, but still.

What are the privacy reasons in this case? The SPIs are already exposed in
the two first packets, so why not also in the third?

> Hence, IMHO including ESP_INFO in those packets should be at most
> SHOULD, and probably MAY, if people want it.

I'd like it to be MUST (or SHOULD) just to reduce the (probability of)
different combinations. Or as an alternative, leave it as it is now.

> On the other hand, I don't understand this issue from the implementers'
> point of view, and would be very interested in hearing counter
> arguments.

My point was to reduce the number of indexing mechanisms required in the
implementations. When you receive an UPDATE packet containing an ECHO
RESPONSE but without ESP_INFO, you need yet another index (the UPDATE ID)
to map the packet to the corresponding SA. However, if we had the the
ESP_INFO included, we'd find the SA just with the existing SPI search
mechanisms that are already required for base exchange.

-- 
Miika Komu              miika@iki.fi          http://www.iki.fi/miika/

_______________________________________________
Hipsec mailing list
Hipsec@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/hipsec