Re: [Dime] Fwd: New Version Notification for draft-korhonen-dime-mip6-feature-bits-01

Vijay Devarapalli <dvijay@gmail.com> Tue, 16 June 2009 00:39 UTC

Return-Path: <dvijay@gmail.com>
X-Original-To: dime@core3.amsl.com
Delivered-To: dime@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E301C3A67E6 for <dime@core3.amsl.com>; Mon, 15 Jun 2009 17:39:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id po3QmaWS4e8m for <dime@core3.amsl.com>; Mon, 15 Jun 2009 17:39:50 -0700 (PDT)
Received: from mail-gx0-f214.google.com (mail-gx0-f214.google.com [209.85.217.214]) by core3.amsl.com (Postfix) with ESMTP id D081E3A6781 for <dime@ietf.org>; Mon, 15 Jun 2009 17:39:49 -0700 (PDT)
Received: by gxk10 with SMTP id 10so7193576gxk.13 for <dime@ietf.org>; Mon, 15 Jun 2009 17:39:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=VhQA43QqK9I34Sxnd43ZoyttD997x8rB0spD21z9zQM=; b=XlLVtrOTtE2k+MnNvULr8ctBzVp7mvMwg58dvar57aDmFR8jkTDi5M9TgpnULBN0Ur 0s0lV2M3ia8ALUTkUNvOCTRY6CoivSw0W2K/kPOjWiseV5vS/+mkrFZfI14e5I2QFoQT wmFfDkKCh8ON57mE79zNQh9xEgvhOHi7nt92k=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=a3HwRSWRwlgVrX6ct1mOTAsEcVxArKtLl6ywFInp9uvCXTNCt0rmrm6KXIHlMRwqg5 6WZ7hLup4ZNUJTTdOGweLqTwV+7ToAFFWWVMSZZHSqyh+svUtK5UfMIT/aZshZPZXhE3 4BvAj6byqQOcVTXIDKl4x2SzOJpilQP7c2SUg=
MIME-Version: 1.0
Received: by 10.151.72.9 with SMTP id z9mr14446710ybk.78.1245112796670; Mon, 15 Jun 2009 17:39:56 -0700 (PDT)
In-Reply-To: <AA130C11-6BBC-4755-B2C0-0CE3CB12B8A5@gmail.com>
References: <20090610092653.601A33A6E07@core3.amsl.com> <1CE00542-32BF-4344-884C-CCDC763FA853@gmail.com> <f1f4dcdc0906101451p16fcb6d0lccd7445eef85c7f6@mail.gmail.com> <AA130C11-6BBC-4755-B2C0-0CE3CB12B8A5@gmail.com>
Date: Mon, 15 Jun 2009 17:39:56 -0700
Message-ID: <f1f4dcdc0906151739l3178805ai1fa1bd880b80ef45@mail.gmail.com>
From: Vijay Devarapalli <dvijay@gmail.com>
To: jouni korhonen <jouni.nospam@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: dime@ietf.org
Subject: Re: [Dime] Fwd: New Version Notification for draft-korhonen-dime-mip6-feature-bits-01
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jun 2009 00:39:51 -0000

Hi Jouni,

On Wed, Jun 10, 2009 at 11:28 PM, jouni korhonen<jouni.nospam@gmail.com> wrote:
> Hi Vijay,
>
> On Jun 11, 2009, at 12:51 AM, Vijay Devarapalli wrote:
>
>> I have another question.
>>
>> Why does encrypting the payload traffic between the MN and the HA need
>> AAA authorization?
>
> IMHO payload traffic encryption is a potential place for a policy decision.
> An operator may want to control it depending on the deployment and the
> subscription in situations where the the same HA could be used for various
> types of deployments. As you know e.g. certain SDOs purposely forbid the use
> of payload encryption in their environment where as that might not make
> sense in other type of deployment.

Let me see if I understand this. Lets say the home operator (MSP) that
provides the home agent does not want the mobile node to use payload
encryption. Isn't this better enforced on the home agent itself? The
home agent can refuse create CHILD SAs for payload protection.

In another case, lets say the client is roaming and is attached to
some visited network and is accessing a home agent in the home
network. I can understand the visited network wanting to prevent
payload encryption. But how does this work if the home agent is
talking to the AAA server in the home network? Does the AAA server,
based on the fact that the client is coming from a specific visited
network, the payload traffic should not be encrypted?

Can you give me an example where this kind of control would help?

Vijay


>
> Jouni
>
>>
>>
>> Vijay
>>
>> On Wed, Jun 10, 2009 at 2:55 AM, jouni korhonen<jouni.nospam@gmail.com>
>> wrote:
>>>
>>> Hi all,
>>>
>>> I have updated the additional feature bits draft. I did remove some stuff
>>> so
>>> that the draft now only reserves MIP6-Feature-Vector flag bits and
>>> nothing
>>> more. I'll forward the draft soon to RFC editor so if anyone has
>>> comments,
>>> please be quick :)
>>>
>>> Cheers,
>>>       Jouni
>>>
>>> Begin forwarded message:
>>>
>>>> From: IETF I-D Submission Tool <idsubmission@ietf.org>
>>>> Date: June 10, 2009 12:26:53 PM GMT+03:00
>>>> To: jouni.nospam@gmail.com
>>>> Subject: New Version Notification for
>>>>  draft-korhonen-dime-mip6-feature-bits-01
>>>>
>>>>
>>>> A new version of I-D, draft-korhonen-dime-mip6-feature-bits-01.txt has
>>>> been successfuly submitted by Jouni Korhonen and posted to the IETF
>>>> repository.
>>>>
>>>> Filename:        draft-korhonen-dime-mip6-feature-bits
>>>> Revision:        01
>>>> Title:           Diameter MIP6 Feature Vector Additional Bit Allocations
>>>> Creation_date:   2009-06-10
>>>> WG ID:           Independent Submission
>>>> Number_of_pages: 5
>>>>
>>>> Abstract:
>>>> During the Mobile IPv6 Split Scenario bootstrapping the Mobile IPv6
>>>> Home Agent and the Authentication, Authorization, and Accounting
>>>> server may exchange a set of authorized mobility capabilities.  This
>>>> document defines new mobility capability flags that are used to
>>>> authorize per Mobile Node route optimization, Multiple Care-of
>>>> Address and user plane traffic encryption support.  Furthermore, this
>>>> document also defines a capability flag of indicating whether the
>>>> Home Agent is authorized to act as a stand alone Virtual Private
>>>> Network gateway.
>>>>
>>>>
>>>>
>>>> The IETF Secretariat.
>>>>
>>>>
>>>
>>> _______________________________________________
>>> DiME mailing list
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>>
>
>