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 protected]>
>>>> To:<[email protected]>
>>>> CC:<[email protected]>
>>>>
>>>> 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 protected]
>>>> https://www.ietf.org/mailman/listinfo/mext
>>>
>>>
>>
>> _______________________________________________
>> MEXT mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/mext
>>
>
_______________________________________________
MEXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mext
