Re: [MEXT] FW: New Version Notification for draft-bajko-mext-sod-02.txt

Julien Laganier <julien.ietf@gmail.com> Mon, 25 July 2011 19:38 UTC

Return-Path: <julien.ietf@gmail.com>
X-Original-To: mext@ietfa.amsl.com
Delivered-To: mext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B9C11E8098 for <mext@ietfa.amsl.com>; Mon, 25 Jul 2011 12:38:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.513
X-Spam-Level:
X-Spam-Status: No, score=-3.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6lNZdhZT4Aaa for <mext@ietfa.amsl.com>; Mon, 25 Jul 2011 12:38:53 -0700 (PDT)
Received: from mail-ey0-f176.google.com (mail-ey0-f176.google.com [209.85.215.176]) by ietfa.amsl.com (Postfix) with ESMTP id D60A411E8095 for <mext@ietf.org>; Mon, 25 Jul 2011 12:38:52 -0700 (PDT)
Received: by eya28 with SMTP id 28so4414141eya.21 for <mext@ietf.org>; Mon, 25 Jul 2011 12:38:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HyAVNjgy18Qg8fk4O5pSwpUavFstlI3nK8bQBWAW/fg=; b=u5wcENEvWCe0okpSyoixnctoszz2YuDmNt61egwaLdAl1P9RKhi/ueUHaDEzq4uVjp IwxqZGpRxbL7OUeJCqFXwKnoVViCI0Gn7ZE5SnVGjYt+kA1joq33K9oecNSg7oXZM9us zOn6Id7h96+BnAhOJE+hNk5BClnQxdRuxYinQ=
MIME-Version: 1.0
Received: by 10.213.28.133 with SMTP id m5mr335697ebc.87.1311622731807; Mon, 25 Jul 2011 12:38:51 -0700 (PDT)
Received: by 10.213.28.7 with HTTP; Mon, 25 Jul 2011 12:38:51 -0700 (PDT)
In-Reply-To: <CA4BB8E1.21E1E%sgundave@cisco.com>
References: <CA4B588B.1BE04%basavaraj.patil@nokia.com> <CA4BB8E1.21E1E%sgundave@cisco.com>
Date: Mon, 25 Jul 2011 12:38:51 -0700
Message-ID: <CAE_dhjvkbftYNs5hWuKoRaigyEg+Mv2Su_MSZPEM8SgN=ExCNQ@mail.gmail.com>
From: Julien Laganier <julien.ietf@gmail.com>
To: Sri Gundavelli <sgundave@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: mext@ietf.org, Basavaraj.Patil@nokia.com
Subject: Re: [MEXT] FW: New Version Notification for draft-bajko-mext-sod-02.txt
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mext>
List-Post: <mailto:mext@ietf.org>
List-Help: <mailto:mext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jul 2011 19:38:53 -0000

Following-up on one of the points:

>>> 2. Use of IKEv2/RFC 4877
>>>
>>> If the MN is in a location where it decides to enable security protection
>>> for the data traffic, it can certainly establish an IPsec SA for the
>>> tunnel
>>> mode ESP. Wondering, if this needs to be achieved over a MIP control plane
>>> and the advantages with that approach ? Even if this needs to be
>>> determined
>>> after the MIP session set up, still there needs to be IKEv2 protocol
>>> exchange for creating the SA ? Nothing stops either the HA or the MN to
>>> create an SA for the tunnel mode ESP.
>>
>> I guess you are missing the point. An MN may create an IPsec SA for the
>> data plane as well using IKEv2. But it is not required that traffic
>> actually flow via this SA. MIP6 does not have a policy or mechanism as to
>> when security for the data plane is applied. This I-D is addressing the
>> issue by providing a means by which security for traffic can be switched
>> on. An MN may create an Ipsec SA at the time of registration for the data
>> plane as well but it is not required that traffic be secured with that SA.
>> but it is not required that traffic be secured with that SA.

an SA for data traffic wouldn' t be created if the SPD doesn' t
require data traffic to be protected by an SA...

> I understood the principle of moving this nego (enable/disable to MIP
> control plane. But, I did not understand the last line. If there is SA for
> tunnel mode ESP, can the HA not drop the traffic not protected with the
> negotiated IPsec SA ?

As above, the SA wouldn' t be created if SPD doesn' t required data
traffic protection. If SPD requires data traffic protection, an SA
will be created.

--julien