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:<internet-dra...@ietf.org>
To:<charl...@computer.org>
CC:<charl...@computer.org>
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
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext
_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext
