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
