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

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 28 Oct 2011 14:11:47 -0700

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
>
>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 31 Oct 2011 15:16:25 -0700

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:
>> 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
>>
>>
>>> 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.
>>>