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

jouni <jouni.nospam@gmail.com> Wed, 17 June 2009 20:31 UTC

Return-Path: <jouni.nospam@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 7C23E3A6C75 for <dime@core3.amsl.com>; Wed, 17 Jun 2009 13:31:57 -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 2FvKnFtpaJzU for <dime@core3.amsl.com>; Wed, 17 Jun 2009 13:31:56 -0700 (PDT)
Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) by core3.amsl.com (Postfix) with ESMTP id D3DC53A6C10 for <dime@ietf.org>; Wed, 17 Jun 2009 13:31:55 -0700 (PDT)
Received: from a88-112-142-249.elisa-laajakaista.fi (a88-112-142-249.elisa-laajakaista.fi [88.112.142.249]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw02.mail.saunalahti.fi (Postfix) with ESMTP id 7B119139792; Wed, 17 Jun 2009 23:32:01 +0300 (EEST)
Message-Id: <945B86A7-D1F9-4D78-8EDB-1402B273A94A@gmail.com>
From: jouni <jouni.nospam@gmail.com>
To: Behcet Sarikaya <sarikaya@ieee.org>
In-Reply-To: <505836.70599.qm@web111413.mail.gq1.yahoo.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Wed, 17 Jun 2009 23:32:00 +0300
References: <20090610092653.601A33A6E07@core3.amsl.com> <1CE00542-32BF-4344-884C-CCDC763FA853@gmail.com> <f1f4dcdc0906101449m6e72475s82ac408f9af15505@mail.gmail.com> <2FA145BF-2534-4A2A-A878-C50A6B3C0087@gmail.com> <f1f4dcdc0906151732l54a30412ubcbd6c4b883e74b5@mail.gmail.com> <5CC059D9-6113-49A3-9748-9F4562A248CC@gmail.com> <505836.70599.qm@web111413.mail.gq1.yahoo.com>
X-Mailer: Apple Mail (2.935.3)
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: Wed, 17 Jun 2009 20:31:57 -0000

Hi Behcet,

I-WLAN PDG is not exactly the same as ePDG. And one can implement  
boxes that are not entirely the same as drawn is some SDO architecture.

Cheers,
	Jouni


On Jun 17, 2009, at 10:39 PM, Behcet Sarikaya wrote:

>
> Hi Jouni,
>   I have no comment on your points below except this one:
> Well.. feature in a sense that you have both functionalities in the  
> same box anyway. Stretching my memory on the requirements, this came  
> from the cases where an I-WLAN PDG and a HA were to be bundled  
> together.
>
> I don't think ePDG and HA can be bundled together in 3GPP  
> architecture. HA is at the PDN Gateway an entity above PDG.
>
> Regards,
>
> Behcet
>
>
>
> ----- Original Message ----
> From: jouni korhonen <jouni.nospam@gmail.com>
> To: Vijay Devarapalli <dvijay@gmail.com>
> Cc: dime@ietf.org
> Sent: Tuesday, June 16, 2009 5:27:44 AM
> Subject: Re: [Dime] Fwd: New Version Notification for draft-korhonen- 
> dime-mip6-feature-bits-01
>
> Hi Vijay,
>
> On Jun 16, 2009, at 3:32 AM, Vijay Devarapalli wrote:
>
>> Hi Jouni,
>>
>> On Wed, Jun 10, 2009 at 11:03 PM, jouni korhonen<jouni.nospam@gmail.com 
>> > wrote:
>>> Hi Vijay,
>>>
>>>
>>> On Jun 11, 2009, at 12:49 AM, Vijay Devarapalli wrote:
>>>
>>>> Hi Jouni,
>>>>
>>>> I have a comment on the "VPN Gateway feature". There is no document
>>>> that describes what it means for a Mobile IPv6 home agent to act  
>>>> as a
>>>> VPN gateway. The IKEv2 exchange between the MN and the HA [RFC 4877
>>>> and 5026] already supports mutual authentication, address  
>>>> assignment
>>>> and setting up of tunnel mode ESP SAs. Are you referring to this as
>>>> VPN mode? But isn't this regular Home agent functionality?
>>>
>>> The "VPN mode" is when you use HA IKEv2/IPsec functionality purely  
>>> for
>>> conventional VPN remote access purposes without any mobility.
>>
>> Again, what does this mean? When you run IKEv2 as described in RFC
>> 4877 and 5026, you are creating tunnel mode security associations for
>> a *Mobile IPv6 tunnel*. In the "VPN" mode, does the mobile node  
>> switch
>> of the Mobile IPv6 stack?
>
> VPN mode is plain RFC4306 + 4303 etc. You end up implementing that  
> machinery there in any case, so why not allow using a HA as a VPN  
> gateway as well. In this case, there is no mobility involved.
>
>>
>> Or does the Home Agent behave an IPsec VPN gateway for pure IPsec
>> clients, i.e., there is no Mobile IPv6 stack on these clients.
>
> Yes.
>
>
>>
>>
>>> That type of
>>> deployment is shortly referenced in draft-ietf-dime-mip6-split  
>>> Section 4.1.
>>> I recall this functionality was originally requested by Gerardo..
>>
>> It doesn't make sense to me. :) This looks more like co-locating a
>> Mbile IPv6 home agent and an IPsec VPN gateway and supporting both
>> Mobile IPv6 mobile nodes and plain IPsec clients at the same time.
>
> Yes, it is about co-location. To me it makes sense as much as  
> IKEv2+IPsec with MIP6 ;)
>
>
>>
>>
>> There has to be more to this scenario than just the short paragraph  
>> in
>> draft-ietf-dime-mip6-split.
>
> Yes, agree.
>
>
>>
>>
>>>> Or is there a separate IPsec VPN that is first setup and then  
>>>> Mobile
>>>> IPv6 is run on top of the IPsec tunnels?
>>>
>>> As shortly described in split document:
>>>
>>>   In some deployment scenarios, the HA may also act as an IKEv2
>>>   Responder for a conventional IPsec VPN access.  The challenge in  
>>> this
>>>   case is that the IKEv2 responder may not know if IKEv2 is used for
>>>   Mobile IPv6 service or for IPsec VPN access service.  A network
>>>   operator needs to be aware of this limitation.  One solution  
>>> already
>>>   supported by IKEv2 is to use different responder identities when
>>>   operating as a conventional IPsec VPN gateway or as a HA.  The  
>>> MN can
>>>   then indicate the preferred responder type using the appropriate  
>>> IDr
>>>   payload in the IKE_AUTH message.
>>>
>>> But yeah, now that feature bits are taken into a separate  
>>> document, the
>>> connection between the above and the new feature bit is rather  
>>> weak. Either
>>> we need more text and/or reference in the draft-korhonen-dime- 
>>> feature-bits
>>> or just remove the bit all together. Since the difference between
>>> conventional IKEv2 IPsec VPN gateway part and HA's IKEv2 IPsec  
>>> functionality
>>> is rather small, I would keep the feature bit and enhance the text  
>>> instead.
>>
>> It is not "rather small" in my opinion. I don't understand how
>> supporting plain IPsec clients can be a feature on a Mobile IPv6 home
>> agent. :)
>
> Well.. feature in a sense that you have both functionalities in the  
> same box anyway. Stretching my memory on the requirements, this came  
> from the cases where an I-WLAN PDG and a HA were to be bundled  
> together.
>
> Jouni
>
>
>>
>>
>> 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
>>>>>
>>>
>>>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>
>
>
>
>