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
- [MEXT] FW: New Version Notification for draft-baj… Basavaraj.Patil
- Re: [MEXT] FW: New Version Notification for draft… Sri Gundavelli
- Re: [MEXT] FW: New Version Notification for draft… Julien Laganier
- Re: [MEXT] FW: New Version Notification for draft… Sri Gundavelli
- Re: [MEXT] FW: New Version Notification for draft… Julien Laganier
- Re: [MEXT] FW: New Version Notification for draft… Basavaraj.Patil
- Re: [MEXT] FW: New Version Notification for draft… Sri Gundavelli
- Re: [MEXT] FW: New Version Notification for draft… Sri Gundavelli
- Re: [MEXT] FW: New Version Notification for draft… Gabor.Bajko
- Re: [MEXT] FW: New Version Notification for draft… Sri Gundavelli
- Re: [MEXT] FW: New Version Notification for draft… Julien Laganier
- Re: [MEXT] FW: New Version Notification for draft… Julien Laganier