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