Subject: Re: [MEXT] New Version Notification fordraft-perkins-mext-hatunaddr-01.txt

From: Romain KUNTZ <[email-masked]>
Date: Tue, 1 Nov 2011 11:19:11 -0700

Hello Charlie,

That's right, I believe the signaling still goes to the primary HA and thus can be secured as usual, and as mandated by the MIPv6 spec. 
Beside, the mobile node can choose to send the IPsec'd traffic through its primary HA if needed.

Thank you,
Romain

On Oct 31, 2011, at 15:16, Charles E. Perkins wrote:

> Hello again Romain,
> 
> I didn't have time to do the specification for any
> new extension for the suggested options revised from
> RFC 3957.  I'll try to do it later this week, but the
> result can't be officially submitted until I get to
> the IETF.
> 
> Anyway, traffic to/from the mobile node <--> home agent
> doesn't always have to be protected, especially looking
> at the relative proportion of data traffic today that
> is sent via IPsec.  It seems to me that the problem is
> important, and must be solved, but not a showstopper.
> 
> Regards,
> Charlie P.
> 
> 
> 
> On 10/28/2011 2:11 PM, Charles E. Perkins wrote:
>> Hello Romain,
>> 
>> Thank you for reminding me about this point. It had been
>> raised previously during some related discussions for DMM
>> late last year, and I plainly forgot to fill in any details
>> about the problem.
>> 
>> After looking over RFC 3957, I think the most efficient way
>> towards solution will be to define a new extension similar
>> to the Generalized MN-HA Key Generation Nonce Request and
>> Generalized MN-HA Key Generation Nonce Reply extensions.
>> It's not a perfect fit, but it's pretty close. If there is
>> any interest for an IPv4-based solution, I could easily
>> write up a new subtype for the RFC 3957 (IPv4) extensions.
>> 
>> The formula for calculating the key in Section 5 needs to be
>> updated, perhaps to the following:
>> key = HMAC-SHA1 (HA-key,
>> {Key Generation Nonce ||
>> mobile node identifier ||
>> HA-D IPv6_address})
>> 
>> A similar formula would apply for any specification
>> in which the key nonce was generated by AAA instead of
>> the [control-plane] Home Agent [HA-C].
>> 
>> The manner in which the HA-D get the corresponding
>> configuration information doesn't have to be specified
>> in the ...mext-hatunaddr... draft.
>> 
>> I'll try to get an updated draft out before the draft
>> deadline on Monday. Thanks for your comment. While
>> mostly straightforward, the update will take a pretty
>> good bit of carefully written text.
>> 
>> Regards,
>> Charlie P.
>> 
>> 
>> On 8/4/2011 11:39 AM, Romain KUNTZ wrote:
>>> Hello Charlie,
>>> 
>>> If the MN has to tunnel data to a different HA than the one to which
>>> it sends the BU, then it also needs an IPsec SA with that HA. How
>>> would the MN create such SA as it does not know in advance what HA it
>>> may use for tunneling? My guess is that the MN is supposed to trust
>>> the address received in the option and create the SA upon reception of
>>> the option. Similarly, all of the HA tunneling box would also need to
>>> be configured with the corresponding SA. Some considerations about
>>> that may be needed in the draft.
>>> 
>>> Regards,
>>> romain
>>> 
>>> 
>>> On Aug 3, 2011, at 12:20, Charles E. Perkins wrote:
>>> 
>>>> 
>>>> Hello folks,
>>>> 
>>>> My draft has now made it through the submission process.
>>>> Please excuse the repeat notification...
>>>> 
>>>> Comments will be appreciated.
>>>> 
>>>> Regards,
>>>> Charlie P.
>>>> 
>>>> 
>>>> -------- Original Message --------
>>>> Subject: New Version Notification for
>>>> draft-perkins-mext-hatunaddr-01.txt
>>>> Date: Wed, 03 Aug 2011 11:58:32 -0700
>>>> From:<[email-masked]>
>>>> To:<[email-masked]>
>>>> CC:<[email-masked]>
>>>> 
>>>> A new version of I-D, draft-perkins-mext-hatunaddr-01.txt has been
>>>> successfully submitted by Charles Perkins and posted to the IETF
>>>> repository.
>>>> 
>>>> Filename: draft-perkins-mext-hatunaddr
>>>> Revision: 01
>>>> Title: Alternate Tunnel Source Address for Home Agent
>>>> Creation date: 2011-08-03
>>>> WG ID: Individual Submission
>>>> Number of pages: 10
>>>> 
>>>> Abstract:
>>>> Widely deployed mobility management systems for wireless
>>>> communications have isolated the path for forwarding data from the
>>>> control plane signaling for mobility management. To realize this
>>>> requirement with Mobile IP requires that the control functions of the
>>>> home agent be addressable at a different IP address than the source
>>>> IP address of the tunnel between the home agent and mobile node.
>>>> Similar considerations hold for mobility anchors implementing
>>>> Hierarchical Mobile IP or PMIP.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> The IETF Secretariat
>>>> 
>>>> _______________________________________________
>>>> MEXT mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/mext
>>> 
>>> 
>> 
>> _______________________________________________
>> MEXT mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mext
>> 
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 1 Nov 2011 13:52:04 -0500

Hi Romain, Charlie,
  I added a new section in

draft-sarikaya-mext-multicastdmm-04.txt

on this. I don't think we need new types, more extensions.

Please check.

Regards,

Behcet
On Tue, Nov 1, 2011 at 1:19 PM, Romain KUNTZ <[email-masked]>wrote:

> Hello Charlie,
>
> That's right, I believe the signaling still goes to the primary HA and
> thus can be secured as usual, and as mandated by the MIPv6 spec.

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 1 Nov 2011 14:57:04 -0500

Hi Charlie,

On Tue, Nov 1, 2011 at 2:46 PM, Charles E. Perkins <[email-masked]>wrote:

> Hello Behcet,
>
>
>
> On 11/1/2011 11:52 AM, Behcet Sarikaya wrote:
>
>> Hi Romain, Charlie,
>>   I added a new section in
>>
>> draft-sarikaya-mext-**multicastdmm-04.txt
>>
> I don't think that the Alternate Care-of Address
> can be used, since Alt_CoA has to do with the
> addressability of the mobile node, not anything
> about the Home Agent [or HA-D].
>
> I understand your point. In the interest of minimizing extensions needed
for DMM, I had kept the option of using AltCoA which was already suggested
earlier by some people.
If we have to use extensions we have to use extensions, no escape.

Regards,

Behcet

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 01 Nov 2011 12:46:19 -0700

Hello Behcet,

Regards,
Charlie P.

PS. Thanks for citing my draft!