From mip6-bounces@ietf.org Mon Apr 03 12:39:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQS5e-00037L-Gk; Mon, 03 Apr 2006 12:39:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQS5d-00037G-Hw for mip6@ietf.org; Mon, 03 Apr 2006 12:39:41 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQS5c-0002FC-4c for mip6@ietf.org; Mon, 03 Apr 2006 12:39:41 -0400 Message-ID: <012e01c6573d$cd2ce190$026115ac@dcml.docomolabsusa.com> From: "James Kempf" To: Date: Mon, 3 Apr 2006 09:43:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Mip6] MOBIKE and MIP X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org There is some discussion going on in the MIP4 group about running MOBIKE and MIP together. The following drafts have been written on the topic: - draft-ietf-mip4-vpn-problem-solution-02 (this one is pre-MOBIKE) - draft-ietf-mip4-mobike-connectivity-00 - draft-meghana-mip4-mobike-optimizations-00 I haven't read the drafts, but I'm told that their recommendation is not to avoid using MIP and MOBIKE together, which seemed to be the conclusion of the discussion during the WG meeting at IETF 65. I don't know whether that conclusion would apply to MIP6, since IKE/IPsec is more tightly integrated with MIP6 and MOBIKE might have a larger effect on interoperation. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 03 14:26:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQTkS-0003r4-SO; Mon, 03 Apr 2006 14:25:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQTkR-0003qz-NY for mip6@ietf.org; Mon, 03 Apr 2006 14:25:55 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQTkR-0006I5-As for mip6@ietf.org; Mon, 03 Apr 2006 14:25:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] MOBIKE and MIP Date: Mon, 3 Apr 2006 11:25:53 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] MOBIKE and MIP Thread-Index: AcZXP8cuC+mbei5PS3mMcpqE2N6aZwACg7KQ From: "Vijay Devarapalli" To: "James Kempf" , X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org hi Jim, draft-ietf-mip4-vpn-problem-solution-02 assumes legacy VPNs. this would mean, the VPN GW cannot be touched while running Mobile IPv4. the=20 solution requires a external HA and an internal=20 HA so that the VPN gateways can be traversed without touching them and at the same time=20 provide mobility while crossing trust boundaries. draft-ietf-mip4-mobike-connectivity-00 addresses the same problem as=20 draft-ietf-mip4-vpn-problem-solution-02 but=20 assumes that the VPN GW on the path is actually=20 a VPN GW that uses IKEv2 and supports MOBIKE.=20 not a legacy VPN GW. then it is possible to setup a Mobile IPv4 tunnel inside the MOBIKE tunnel. both the above drafts assume the VPN GW and=20 the home agent are two separate boxes. draft-meghana-mip4-mobike-optimizations-00 takes the concept further and reduces the overhead by=20 having FA functionality or HA functionality on=20 the VPN GW in addition to IKEv2 and MOBIKE functionality. MIPv4 and MIPv6 are very different protocols. with MIPv6 you set up an IPsec protected Mobile IP tunnel between the mobile node and the HA. so you already have the VPN functionality. the=20 'K' bit also allows you to update the IKE SA=20 associated with the tunnel. this is what MOBIKE=20 tries to do too. so that's why I don't expect=20 someone to use MOBIKE and MIP6 at the same time=20 to the same box (or gateway). there was an email on this list from Jouni=20 Korhonen asking if we can write up something=20 for MIP6 and MOBIKE along the lines of=20 draft-ietf-mip4-mobike-connectivity-00. I=20 had told him yes. but this assumes the VPN GW and the home agent as two separate boxes,=20 with a MIP6 tunnel to the home agent inside=20 the IPsec tunnel to the VPN gateway. I have=20 already written up a draft on this, but didn't=20 submit it because I didn't see a need for it.=20 it is a very obvious solution. Vijay > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com]=20 > Sent: Monday, April 03, 2006 9:44 AM > To: mip6@ietf.org > Subject: [Mip6] MOBIKE and MIP >=20 > There is some discussion going on in the MIP4 group about=20 > running MOBIKE and=20 > MIP together. The following drafts have been written on the topic: >=20 > - draft-ietf-mip4-vpn-problem-solution-02 (this one is pre-MOBIKE) > - draft-ietf-mip4-mobike-connectivity-00 > - draft-meghana-mip4-mobike-optimizations-00 >=20 > I haven't read the drafts, but I'm told that their=20 > recommendation is not to=20 > avoid using MIP and MOBIKE together, which seemed to be the=20 > conclusion of=20 > the discussion during the WG meeting at IETF 65. I don't know=20 > whether that=20 > conclusion would apply to MIP6, since IKE/IPsec is more=20 > tightly integrated=20 > with MIP6 and MOBIKE might have a larger effect on interoperation. >=20 > jak >=20 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 03 15:53:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQV74-0003kq-KQ; Mon, 03 Apr 2006 15:53:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQV72-0003d6-Lj for mip6@ietf.org; Mon, 03 Apr 2006 15:53:20 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQV6x-00021Q-NS for mip6@ietf.org; Mon, 03 Apr 2006 15:53:20 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IX500J7LX63TX@szxga02-in.huawei.com> for mip6@ietf.org; Tue, 04 Apr 2006 04:06:04 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IX50028VX63YK@szxga02-in.huawei.com> for mip6@ietf.org; Tue, 04 Apr 2006 04:06:03 +0800 (CST) Received: from [10.124.8.220] by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IX500F0SX5R6Y@szxml02-in.huawei.com>; Tue, 04 Apr 2006 04:05:53 +0800 (CST) Date: Mon, 03 Apr 2006 14:52:17 -0500 From: Behcet Sarikaya Subject: Re: [Mip6] MOBIKE and MIP In-reply-to: To: Vijay Devarapalli Message-id: <44317CF1.4050403@yahoo.com> MIME-version: 1.0 X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) References: X-Spam-Score: 2.7 (++) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0122447092==" Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============0122447092== Content-type: multipart/alternative; boundary="Boundary_(ID_RXv8kubvtikjtYjfhDKNNw)" This is a multi-part message in MIME format. --Boundary_(ID_RXv8kubvtikjtYjfhDKNNw) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT Vijay Devarapalli wrote: >hi Jim, > >draft-ietf-mip4-vpn-problem-solution-02 assumes >legacy VPNs. this would mean, the VPN GW cannot >be touched while running Mobile IPv4. the >solution requires a external HA and an internal >HA so that the VPN gateways can be traversed >without touching them and at the same time >provide mobility while crossing trust boundaries. > >draft-ietf-mip4-mobike-connectivity-00 addresses >the same problem as >draft-ietf-mip4-vpn-problem-solution-02 but >assumes that the VPN GW on the path is actually >a VPN GW that uses IKEv2 and supports MOBIKE. >not a legacy VPN GW. then it is possible to setup >a Mobile IPv4 tunnel inside the MOBIKE tunnel. > >both the above drafts assume the VPN GW and >the home agent are two separate boxes. > >draft-meghana-mip4-mobike-optimizations-00 takes >the concept further and reduces the overhead by >having FA functionality or HA functionality on >the VPN GW in addition to IKEv2 and MOBIKE >functionality. > >MIPv4 and MIPv6 are very different protocols. >with MIPv6 you set up an IPsec protected Mobile >IP tunnel between the mobile node and the HA. >so you already have the VPN functionality. the >'K' bit also allows you to update the IKE SA >associated with the tunnel. this is what MOBIKE >tries to do too. so that's why I don't expect >someone to use MOBIKE and MIP6 at the same time >to the same box (or gateway). > >there was an email on this list from Jouni >Korhonen asking if we can write up something >for MIP6 and MOBIKE along the lines of >draft-ietf-mip4-mobike-connectivity-00. I >had told him yes. but this assumes the VPN GW >and the home agent as two separate boxes, >with a MIP6 tunnel to the home agent inside >the IPsec tunnel to the VPN gateway. I have >already written up a draft on this, but didn't >submit it because I didn't see a need for it. >it is a very obvious solution. > > > So you are saying that in fact MOBIKE does not introduce a new mobility architecture, it just carries MIP tunnels? What if there is no tunnel, i.e. RO case? Regards, Behcet >Vijay > > > >>-----Original Message----- >>From: James Kempf [mailto:kempf@docomolabs-usa.com] >>Sent: Monday, April 03, 2006 9:44 AM >>To: mip6@ietf.org >>Subject: [Mip6] MOBIKE and MIP >> >>There is some discussion going on in the MIP4 group about >>running MOBIKE and >>MIP together. The following drafts have been written on the topic: >> >>- draft-ietf-mip4-vpn-problem-solution-02 (this one is pre-MOBIKE) >>- draft-ietf-mip4-mobike-connectivity-00 >>- draft-meghana-mip4-mobike-optimizations-00 >> >>I haven't read the drafts, but I'm told that their >>recommendation is not to >>avoid using MIP and MOBIKE together, which seemed to be the >>conclusion of >>the discussion during the WG meeting at IETF 65. I don't know >>whether that >>conclusion would apply to MIP6, since IKE/IPsec is more >>tightly integrated >>with MIP6 and MOBIKE might have a larger effect on interoperation. >> >> jak >> >> >> >>_______________________________________________ >>Mip6 mailing list >>Mip6@ietf.org >>https://www1.ietf.org/mailman/listinfo/mip6 >> >> >> > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www1.ietf.org/mailman/listinfo/mip6 > > > --Boundary_(ID_RXv8kubvtikjtYjfhDKNNw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT Vijay Devarapalli wrote:
hi Jim,

draft-ietf-mip4-vpn-problem-solution-02 assumes
legacy VPNs. this would mean, the VPN GW cannot
be touched while running Mobile IPv4. the 
solution requires a external HA and an internal 
HA so that the VPN gateways can be traversed
without touching them and at the same time 
provide mobility while crossing trust boundaries.

draft-ietf-mip4-mobike-connectivity-00 addresses
the same problem as 
draft-ietf-mip4-vpn-problem-solution-02 but 
assumes that the VPN GW on the path is actually 
a VPN GW that uses IKEv2 and supports MOBIKE. 
not a legacy VPN GW. then it is possible to setup
a Mobile IPv4 tunnel inside the MOBIKE tunnel.

both the above drafts assume the VPN GW and 
the home agent are two separate boxes.

draft-meghana-mip4-mobike-optimizations-00 takes
the concept further and reduces the overhead by 
having FA functionality or HA functionality on 
the VPN GW in addition to IKEv2 and MOBIKE
functionality.

MIPv4 and MIPv6 are very different protocols.
with MIPv6 you set up an IPsec protected Mobile
IP tunnel between the mobile node and the HA.
so you already have the VPN functionality. the 
'K' bit also allows you to update the IKE SA 
associated with the tunnel. this is what MOBIKE 
tries to do too. so that's why I don't expect 
someone to use MOBIKE and MIP6 at the same time 
to the same box (or gateway).

there was an email on this list from Jouni 
Korhonen asking if we can write up something 
for MIP6 and MOBIKE along the lines of 
draft-ietf-mip4-mobike-connectivity-00. I 
had told him yes. but this assumes the VPN GW
and the home agent as two separate boxes, 
with a MIP6 tunnel to the home agent inside 
the IPsec tunnel to the VPN gateway. I have 
already written up a draft on this, but didn't 
submit it because I didn't see a need for it. 
it is a very obvious solution.
So you are saying that in fact MOBIKE does not introduce a new mobility architecture, it just carries MIP tunnels?
What if there is no tunnel, i.e. RO case?

Regards,

Behcet
Vijay

  
-----Original Message-----
From: James Kempf [mailto:kempf@docomolabs-usa.com] 
Sent: Monday, April 03, 2006 9:44 AM
To: mip6@ietf.org
Subject: [Mip6] MOBIKE and MIP

There is some discussion going on in the MIP4 group about 
running MOBIKE and 
MIP together. The following drafts have been written on the topic:

- draft-ietf-mip4-vpn-problem-solution-02 (this one is pre-MOBIKE)
- draft-ietf-mip4-mobike-connectivity-00
- draft-meghana-mip4-mobike-optimizations-00

I haven't read the drafts, but I'm told that their 
recommendation is not to 
avoid using MIP and MOBIKE together, which seemed to be the 
conclusion of 
the discussion during the WG meeting at IETF 65. I don't know 
whether that 
conclusion would apply to MIP6, since IKE/IPsec is more 
tightly integrated 
with MIP6 and MOBIKE might have a larger effect on interoperation.

            jak



_______________________________________________
Mip6 mailing list
Mip6@ietf.org
https://www1.ietf.org/mailman/listinfo/mip6

    

_______________________________________________
Mip6 mailing list
Mip6@ietf.org
https://www1.ietf.org/mailman/listinfo/mip6

--Boundary_(ID_RXv8kubvtikjtYjfhDKNNw)-- --===============0122447092== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0122447092==-- From mip6-bounces@ietf.org Mon Apr 03 17:01:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQWBA-000510-Rv; Mon, 03 Apr 2006 17:01:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQWB9-00050v-Ae for mip6@ietf.org; Mon, 03 Apr 2006 17:01:39 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQWB8-0005Qq-CC for mip6@ietf.org; Mon, 03 Apr 2006 17:01:39 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k33L1Vh1018816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 3 Apr 2006 14:01:32 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k33L1P82003072; Mon, 3 Apr 2006 14:01:31 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Apr 2006 14:01:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] MOBIKE and MIP Date: Mon, 3 Apr 2006 14:00:22 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB844873E4@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] MOBIKE and MIP Thread-Index: AcZXP8cuC+mbei5PS3mMcpqE2N6aZwACg7KQAAWBlKA= From: "Narayanan, Vidya" To: "Vijay Devarapalli" , "James Kempf" , X-OriginalArrivalTime: 03 Apr 2006 21:01:20.0982 (UTC) FILETIME=[C24BA760:01C65761] X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org James, Vijay, There are two cases with respect to MOBIKE and MIP6:=20 1. MOBIKE and MIP6 have different endpoints - i.e., MOBIKE between MN and VPN GW, MIP6 between MN and HA This is a valid model and has applicability in some markets (where data needs to be protected using IPsec in a VPN-over-MIP model). This would be a reason to write a draft similar to the MIP4-MOBIKE one.=20 2. MOBIKE and MIP6 endpoints are the same - i.e., both run between the MN and HA This is the model that may not make sense, depending on the applicability. From an architectural purity point of view, I could be convinced that this should replace the 'K' bit concept - since, MIP6 should not really be doing key management for IKE/IKEv2 in any shape or form. However, since the 'K' bit exists *and* the IKEv2 SA that it is updating is *solely* for the purpose of MIP6, I'm inclined to leave it in (gets the job done without additional signaling). However, when the IKEv2 SA does more than just MIP6 (i.e., the MIP6 IPsec SA is only one of the child SAs derived from it and the IKEv2 SA has broader scope, allowing other child SAs to be derived), I would like to see MOBIKE doing the address update to IKEv2 rather than MIP6. This is why I was saying in some earlier responses on this topic that we should not consciously disallow the co-existence of MIP6 and MOBIKE.=20 Regards, Vidya > -----Original Message----- > From: Vijay Devarapalli [mailto:Vijay.Devarapalli@azairenet.com]=20 > Sent: Monday, April 03, 2006 11:26 AM > To: James Kempf; mip6@ietf.org > Subject: RE: [Mip6] MOBIKE and MIP >=20 > hi Jim, >=20 > draft-ietf-mip4-vpn-problem-solution-02 assumes legacy VPNs.=20 > this would mean, the VPN GW cannot be touched while running=20 > Mobile IPv4. the solution requires a external HA and an=20 > internal HA so that the VPN gateways can be traversed without=20 > touching them and at the same time provide mobility while=20 > crossing trust boundaries. >=20 > draft-ietf-mip4-mobike-connectivity-00 addresses the same problem as > draft-ietf-mip4-vpn-problem-solution-02 but assumes that the=20 > VPN GW on the path is actually a VPN GW that uses IKEv2 and=20 > supports MOBIKE.=20 > not a legacy VPN GW. then it is possible to setup a Mobile=20 > IPv4 tunnel inside the MOBIKE tunnel. >=20 > both the above drafts assume the VPN GW and the home agent=20 > are two separate boxes. >=20 > draft-meghana-mip4-mobike-optimizations-00 takes the concept=20 > further and reduces the overhead by having FA functionality=20 > or HA functionality on the VPN GW in addition to IKEv2 and=20 > MOBIKE functionality. >=20 > MIPv4 and MIPv6 are very different protocols. > with MIPv6 you set up an IPsec protected Mobile IP tunnel=20 > between the mobile node and the HA. > so you already have the VPN functionality. the 'K' bit also=20 > allows you to update the IKE SA associated with the tunnel.=20 > this is what MOBIKE tries to do too. so that's why I don't=20 > expect someone to use MOBIKE and MIP6 at the same time to the=20 > same box (or gateway). >=20 > there was an email on this list from Jouni Korhonen asking if=20 > we can write up something for MIP6 and MOBIKE along the lines=20 > of draft-ietf-mip4-mobike-connectivity-00. I had told him=20 > yes. but this assumes the VPN GW and the home agent as two=20 > separate boxes, with a MIP6 tunnel to the home agent inside=20 > the IPsec tunnel to the VPN gateway. I have already written=20 > up a draft on this, but didn't submit it because I didn't see=20 > a need for it.=20 > it is a very obvious solution. >=20 > Vijay >=20 > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Monday, April 03, 2006 9:44 AM > > To: mip6@ietf.org > > Subject: [Mip6] MOBIKE and MIP > >=20 > > There is some discussion going on in the MIP4 group about running=20 > > MOBIKE and MIP together. The following drafts have been=20 > written on the=20 > > topic: > >=20 > > - draft-ietf-mip4-vpn-problem-solution-02 (this one is pre-MOBIKE) > > - draft-ietf-mip4-mobike-connectivity-00 > > - draft-meghana-mip4-mobike-optimizations-00 > >=20 > > I haven't read the drafts, but I'm told that their=20 > recommendation is=20 > > not to avoid using MIP and MOBIKE together, which seemed to be the=20 > > conclusion of the discussion during the WG meeting at IETF=20 > 65. I don't=20 > > know whether that conclusion would apply to MIP6, since=20 > IKE/IPsec is=20 > > more tightly integrated with MIP6 and MOBIKE might have a larger=20 > > effect on interoperation. > >=20 > > jak > >=20 > >=20 > >=20 > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 03 17:13:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQWMf-00060C-4G; Mon, 03 Apr 2006 17:13:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQWMe-0005xn-6j for mip6@ietf.org; Mon, 03 Apr 2006 17:13:32 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQWMc-0005tQ-Sk for mip6@ietf.org; Mon, 03 Apr 2006 17:13:32 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] MOBIKE and MIP Date: Mon, 3 Apr 2006 14:13:27 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] MOBIKE and MIP Thread-Index: AcZXP8cuC+mbei5PS3mMcpqE2N6aZwACg7KQAAWBlKAAAJxDIA== From: "Vijay Devarapalli" To: "Narayanan, Vidya" , "James Kempf" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org =20 > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com]=20 > Sent: Monday, April 03, 2006 2:00 PM > To: Vijay Devarapalli; James Kempf; mip6@ietf.org > Subject: RE: [Mip6] MOBIKE and MIP >=20 > James, Vijay, > There are two cases with respect to MOBIKE and MIP6:=20 >=20 > 1. MOBIKE and MIP6 have different endpoints - i.e., MOBIKE between MN > and VPN GW, MIP6 between MN and HA >=20 > This is a valid model and has applicability in some markets=20 > (where data > needs to be protected using IPsec in a VPN-over-MIP model). This would > be a reason to write a draft similar to the MIP4-MOBIKE one.=20 I have the draft ready to go. there was a discussion on this on the MIP6 mailing list about a year ago. there wasn't much interest at that point. so it wasn't submitted. > 2. MOBIKE and MIP6 endpoints are the same - i.e., both run between the > MN and HA this is what was discussed at the last IETF meeting. the conclusion was that it would be redundant. > This is the model that may not make sense, depending on the > applicability. From an architectural purity point of view, I could be > convinced that this should replace the 'K' bit concept - since, MIP6 > should not really be doing key management for IKE/IKEv2 in=20 > any shape or > form. However, since the 'K' bit exists *and* the IKEv2 SA that it is > updating is *solely* for the purpose of MIP6, I'm inclined to leave it > in (gets the job done without additional signaling).=20 yes. > However, when the > IKEv2 SA does more than just MIP6 (i.e., the MIP6 IPsec SA is only one > of the child SAs derived from it and the IKEv2 SA has broader scope, > allowing other child SAs to be derived),=20 its the other way around. sending a binding update triggers the IKEv2 stack to setup a transport mode SA for the BU. sending a HoTi message triggers the IKEv2 stack to setup a tunnel mode SA for the HoTi message. when MIP6 is used, MIP6 would be your mobility management protocol. > I would like to see MOBIKE > doing the address update to IKEv2 rather than MIP6. This is why I was > saying in some earlier responses on this topic that we should not > consciously disallow the co-existence of MIP6 and MOBIKE.=20 nobody is disallowing anything. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 03 21:00:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQZtw-00058U-ML; Mon, 03 Apr 2006 21:00:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQZtv-00057p-F2 for mip6@ietf.org; Mon, 03 Apr 2006 21:00:07 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQZtv-0007xX-42 for mip6@ietf.org; Mon, 03 Apr 2006 21:00:07 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k34102te010177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 3 Apr 2006 18:00:03 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k34100XQ009118; Mon, 3 Apr 2006 18:00:01 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Apr 2006 18:00:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] MOBIKE and MIP Date: Mon, 3 Apr 2006 18:00:03 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB84487485@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] MOBIKE and MIP Thread-Index: AcZXP8cuC+mbei5PS3mMcpqE2N6aZwACg7KQAAWBlKAAAJxDIAAH3scg From: "Narayanan, Vidya" To: "Vijay Devarapalli" , "James Kempf" , X-OriginalArrivalTime: 04 Apr 2006 01:00:00.0696 (UTC) FILETIME=[19829B80:01C65783] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org >=20 > > However, when the > > IKEv2 SA does more than just MIP6 (i.e., the MIP6 IPsec SA=20 > is only one=20 > > of the child SAs derived from it and the IKEv2 SA has=20 > broader scope,=20 > > allowing other child SAs to be derived), >=20 > its the other way around. sending a binding update triggers=20 > the IKEv2 stack to setup a transport mode SA for the BU.=20 > sending a HoTi message triggers the > IKEv2 stack to setup a tunnel mode SA for the HoTi message.=20 > when MIP6 is used, MIP6 would be your mobility management protocol. >=20 I'm not sure how it is the other way around :) The IKEv2 SA can lead to an IPsec transport mode SA for the BU and an IPsec tunnel mode SA for the HoTi message. If that is all the IKEv2 SA is doing, it makes sense for the 'K' bit to control the address change on that. However, the IKEv2 SA may be deriving other IPsec SAs - say, a tunnel mode IPsec SA for data traffic protection between the MN and HA. In such cases, MOBIKE should be in control of updating the IKEv2 SA.=20 > > I would like to see MOBIKE > > doing the address update to IKEv2 rather than MIP6. This is=20 > why I was=20 > > saying in some earlier responses on this topic that we should not=20 > > consciously disallow the co-existence of MIP6 and MOBIKE. >=20 > nobody is disallowing anything. >=20 Well, current definitions are insufficient to allow this behavior. If MOBIKE needs to be used to update the IKEv2 SA, the 'K' bit must be ignored in MIP6 signaling (or always set to 0) - this isn't specified anywhere right now.=20 Vidya _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 03 21:05:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQZzI-00038l-Id; Mon, 03 Apr 2006 21:05:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQZzH-00038g-20 for mip6@ietf.org; Mon, 03 Apr 2006 21:05:39 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQZzF-000889-QW for mip6@ietf.org; Mon, 03 Apr 2006 21:05:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] MOBIKE and MIP Date: Mon, 3 Apr 2006 18:05:35 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] MOBIKE and MIP Thread-Index: AcZXP8cuC+mbei5PS3mMcpqE2N6aZwACg7KQAAWBlKAAAJxDIAAH3scgAAB6m9A= From: "Vijay Devarapalli" To: "Narayanan, Vidya" , "James Kempf" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > However, the > IKEv2 SA may be deriving other IPsec SAs - say, a tunnel mode IPsec SA > for data traffic protection between the MN and HA.=20 why would you do this? and if you want to do this, use the MIP tunnel, which is already setup. better use the IPsec protected MIP tunnel. why would there be a separate IPsec tunnel? Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 03 21:56:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQamn-0001se-12; Mon, 03 Apr 2006 21:56:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQaml-0001sZ-UK for mip6@ietf.org; Mon, 03 Apr 2006 21:56:47 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQamj-0001vS-IP for mip6@ietf.org; Mon, 03 Apr 2006 21:56:47 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k341ufkD017360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 3 Apr 2006 18:56:41 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k341ueSE019042; Mon, 3 Apr 2006 18:56:40 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Apr 2006 18:56:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] MOBIKE and MIP Date: Mon, 3 Apr 2006 18:56:37 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB84487489@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] MOBIKE and MIP Thread-Index: AcZXP8cuC+mbei5PS3mMcpqE2N6aZwACg7KQAAWBlKAAAJxDIAAH3scgAAB6m9AAAL2PgA== From: "Narayanan, Vidya" To: "Vijay Devarapalli" , "James Kempf" , X-OriginalArrivalTime: 04 Apr 2006 01:56:40.0540 (UTC) FILETIME=[03F9A1C0:01C6578B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org >=20 > > However, the > > IKEv2 SA may be deriving other IPsec SAs - say, a tunnel=20 > mode IPsec SA=20 > > for data traffic protection between the MN and HA. >=20 > why would you do this? and if you want to do this, use the=20 > MIP tunnel, which is already setup. better use the IPsec=20 > protected MIP tunnel. why would there be a separate IPsec tunnel? >=20 That was an example. Key separation is one reason I can think of as a motivation to do a separate IPsec SA for data protection. I'm not saying all implementations will/need to do this. The goal of the IPsec SA derived for MIP6 is really to protect MIP6 signaling and its lifetime, etc. may be governed by that use. It is a matter of policy whether that does or does not fit the requirements for data protection.=20 Also, other examples exist. If the MIP6 HA is also, say a SIP server and you want to use IPsec to protect the SIP signaling between the SIP client and server, that can be another child SA from IKEv2. Of course, this holds true for any other applications running over IP. All I'm saying is that IKEv2 potentially has broader applicability and the MIP6 IPsec SA may only be *one* of the child SAs that is being derived.=20 Also note that the same IPsec SA could be protecting a bunch of applications (MIP6, SIP, whatever signaling)- in this case, the IKEv2 SA may only lead to one IPsec SA. Even so, the fact that the IKEv2 and IPsec SAs have an applicability that is broader than MIP6 in this case says that MIP6 should not be updating those SAs. It would be an architectural limitation that could hurt us later, even if we can't come up with a good reason now.=20 Vidya _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 04 03:48:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQgHM-0003Hj-0b; Tue, 04 Apr 2006 03:48:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQgHK-0003ED-6u for mip6@ietf.org; Tue, 04 Apr 2006 03:48:42 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQgHF-0000Ll-T3 for mip6@ietf.org; Tue, 04 Apr 2006 03:48:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] MOBIKE and MIP Date: Tue, 4 Apr 2006 00:48:35 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] MOBIKE and MIP Thread-Index: AcZXP8cuC+mbei5PS3mMcpqE2N6aZwACg7KQAAWBlKAAAJxDIAAH3scgAAB6m9AAAL2PgAANRL8g From: "Vijay Devarapalli" To: "Narayanan, Vidya" , "James Kempf" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > That was an example.=20 I would love to see a realistic scenario. I=20 haven't seen one so far. if there is an issue, don't worry, I would be the first one to jump on it and start working on a solution. > Also, other examples exist. If the MIP6 HA is also, say a SIP=20 > server and a P-CSCF? or a media gateway? > you want to use IPsec to protect the SIP signaling between the SIP > client and server, that can be another child SA from IKEv2.=20 now why would there be a tunnel mode IPsec SA for SIP signaling between the MN and the HA? > Of course, > this holds true for any other applications running over IP.=20 again, please come up with a realistic scenario. this is my last email on this thread until=20 someone comes with an issue that needs to be=20 fixed. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 04 13:16:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQp8e-0003Sq-VC; Tue, 04 Apr 2006 13:16:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQp8d-0003Ow-Gf for mip6@ietf.org; Tue, 04 Apr 2006 13:16:19 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQp8d-0008WL-55 for mip6@ietf.org; Tue, 04 Apr 2006 13:16:19 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k34HGDRs032589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Apr 2006 10:16:14 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k34HG3fr011758; Tue, 4 Apr 2006 10:16:12 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Apr 2006 10:16:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] MOBIKE and MIP Date: Tue, 4 Apr 2006 10:16:13 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF001AF2A1C@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] MOBIKE and MIP Thread-Index: AcZXP8cuC+mbei5PS3mMcpqE2N6aZwACg7KQAAWBlKAAAJxDIAAH3scgAAB6m9AAAL2PgAANRL8gABOoJoA= From: "Soliman, Hesham" To: "Vijay Devarapalli" , "Narayanan, Vidya" , "James Kempf" , X-OriginalArrivalTime: 04 Apr 2006 17:16:12.0569 (UTC) FILETIME=[79112890:01C6580B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org =20 > > Also, other examples exist. If the MIP6 HA is also, say a SIP=20 > > server and >=20 > a P-CSCF? or a media gateway? =3D> I don't think the nature of the application is an important factor here. On a conceptual level, it's limiting to assume that the node handling mobility management (e.g. HA) is the same=20 one that will handle the IPsec termination point.=20 One possible scenario is a case where my HA and my VPN GW are=20 administered by 2 different entities. For instance, I might have=20 an IPsec tunnel to a corporate network, while being offered mobility by a telco. In this case there is a clear separation between the two SAs. Whether this requires MOBIKE or not is a different=20 story. My HoA might be the address used to setup the IPsec SA=20 with the corporate GW and that never changes. Alternatively, I might use my RCoA to setup the SA with the corporate GW, when my RCoA changes (rare event) I could then use MOBIKE or re-establish the=20 SA.=20 Personally, I do think the K bit works for the collocated case=20 (IPsec and HA in the same node). At the same time, there are realistic scenarios where the two termination points are separated, but even then I believe the current specs work today as long as the traffic passes=20 through the HA first, which should always be the case.=20 Hesham >=20 > > you want to use IPsec to protect the SIP signaling between the SIP > > client and server, that can be another child SA from IKEv2.=20 >=20 > now why would there be a tunnel mode IPsec SA > for SIP signaling between the MN and the HA? >=20 > > Of course, > > this holds true for any other applications running over IP.=20 >=20 > again, please come up with a realistic scenario. > this is my last email on this thread until=20 > someone comes with an issue that needs to be=20 > fixed. >=20 > Vijay >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 04 13:25:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQpHi-00071x-Um; Tue, 04 Apr 2006 13:25:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQpHi-00071s-6T for mip6@ietf.org; Tue, 04 Apr 2006 13:25:42 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQpHg-0000t5-Sp for mip6@ietf.org; Tue, 04 Apr 2006 13:25:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] MOBIKE and MIP Date: Tue, 4 Apr 2006 10:25:38 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] MOBIKE and MIP Thread-Index: AcZXP8cuC+mbei5PS3mMcpqE2N6aZwACg7KQAAWBlKAAAJxDIAAH3scgAAB6m9AAAL2PgAANRL8gABOoJoAAAGKpIA== From: "Vijay Devarapalli" To: "Soliman, Hesham" , "Narayanan, Vidya" , "James Kempf" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > =3D> I don't think the nature of the application is an important > factor here. On a conceptual level, it's limiting to assume that > the node handling mobility management (e.g. HA) is the same=20 > one that will handle the IPsec termination point.=20 > One possible scenario is a case where my HA and my VPN GW are=20 > administered by 2 different entities. For instance, I might have=20 > an IPsec tunnel to a corporate network, while being offered mobility > by a telco. In this case there is a clear separation between > the two SAs. Whether this requires MOBIKE or not is a different=20 > story. My HoA might be the address used to setup the IPsec SA=20 > with the corporate GW and that never changes. Alternatively, I might > use my RCoA to setup the SA with the corporate GW, when my RCoA > changes (rare event) I could then use MOBIKE or re-establish the=20 > SA.=20 when the MIP6 HA and the VPN GW are separated with the IPsec tunnel terminating on the VPN GW and the MIP tunnel terminating on the HA, then we have a scenario/use case. something along the lines of=20 draft-ietf-mip4-mobike-connectivity-00.txt should work for this scenario. we are in=20 agreement here. > Personally, I do think the K bit works for the collocated case=20 > (IPsec and HA in the same node). At the same time, there are realistic > scenarios where the two termination points are separated.... agreed. Vidya and Jim are trying to show us a scenario where the IPsec tunnel and MIP tunnel terminate=20 on the same box and MOBIKE is used along with=20 MIPv6 signaling messages.=20 Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 04 13:30:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQpMD-0003xN-HT; Tue, 04 Apr 2006 13:30:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQpMC-0003wB-Jj for mip6@ietf.org; Tue, 04 Apr 2006 13:30:20 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQpMB-00014B-9t for mip6@ietf.org; Tue, 04 Apr 2006 13:30:20 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k34HU8c2001717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Apr 2006 10:30:10 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k34HU3HT011992; Tue, 4 Apr 2006 10:30:07 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Apr 2006 10:30:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] MOBIKE and MIP Date: Tue, 4 Apr 2006 10:30:06 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF001AF2A47@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] MOBIKE and MIP Thread-Index: AcZXP8cuC+mbei5PS3mMcpqE2N6aZwACg7KQAAWBlKAAAJxDIAAH3scgAAB6m9AAAL2PgAANRL8gABOoJoAAAGKpIAAAUZJw From: "Soliman, Hesham" To: "Vijay Devarapalli" , "Narayanan, Vidya" , "James Kempf" X-OriginalArrivalTime: 04 Apr 2006 17:30:04.0431 (UTC) FILETIME=[68E539F0:01C6580D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > Vidya and Jim are trying to show us a scenario > where the IPsec tunnel and MIP tunnel terminate=20 > on the same box and MOBIKE is used along with=20 > MIPv6 signaling messages.=20 =3D> I think this is a scenario that should be avoided.=20 Hesham >=20 > Vijay >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 04 13:40:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQpVd-0006MO-4S; Tue, 04 Apr 2006 13:40:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQpVc-0006LR-08 for mip6@ietf.org; Tue, 04 Apr 2006 13:40:04 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQpVb-0001Fr-L8 for mip6@ietf.org; Tue, 04 Apr 2006 13:40:03 -0400 Message-ID: <029301c6580f$621d5100$026115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Soliman, Hesham" , "Vijay Devarapalli" , "Narayanan, Vidya" References: <1487A357FD2ED544B8AD29E528FF9DF001AF2A47@NAEX06.na.qualcomm.com> Subject: Re: [Mip6] MOBIKE and MIP Date: Tue, 4 Apr 2006 10:44:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Then maybe that's what the document needs to say. jak ----- Original Message ----- From: "Soliman, Hesham" To: "Vijay Devarapalli" ; "Narayanan, Vidya" ; "James Kempf" Cc: Sent: Tuesday, April 04, 2006 10:30 AM Subject: RE: [Mip6] MOBIKE and MIP > Vidya and Jim are trying to show us a scenario > where the IPsec tunnel and MIP tunnel terminate > on the same box and MOBIKE is used along with > MIPv6 signaling messages. => I think this is a scenario that should be avoided. Hesham > > Vijay > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 04 13:56:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQplp-0007Hn-SI; Tue, 04 Apr 2006 13:56:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQplp-0007Hi-GH for mip6@ietf.org; Tue, 04 Apr 2006 13:56:49 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQplp-0001YI-5p for mip6@ietf.org; Tue, 04 Apr 2006 13:56:49 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k34HugBx005940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Apr 2006 10:56:43 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k34HuXJ1001227; Tue, 4 Apr 2006 10:56:42 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Apr 2006 10:56:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] MOBIKE and MIP Date: Tue, 4 Apr 2006 10:56:23 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB8448757F@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] MOBIKE and MIP Thread-Index: AcZYDtf4jHrDLSqKRcaIP2blwgq+3AAAYLtw From: "Narayanan, Vidya" To: "James Kempf" , "Soliman, Hesham" , "Vijay Devarapalli" X-OriginalArrivalTime: 04 Apr 2006 17:56:25.0150 (UTC) FILETIME=[1713CDE0:01C65811] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org This approach is taking the view that in the presence of MIP6, it supercedes everything else and has control over key management for applications beyond MIP6. I don't think this is the right view at all. It is quite practical to envision other applications having the same endpoints (MN and HA) wanting to use the IKEv2 SA for protecting other signaling. Avoiding that just makes us short-sighted.=20 Vidya > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com]=20 > Sent: Tuesday, April 04, 2006 10:44 AM > To: Soliman, Hesham; Vijay Devarapalli; Narayanan, Vidya > Cc: mip6@ietf.org > Subject: Re: [Mip6] MOBIKE and MIP >=20 > Then maybe that's what the document needs to say. >=20 > jak >=20 > ----- Original Message ----- > From: "Soliman, Hesham" > To: "Vijay Devarapalli" ;=20 > "Narayanan, Vidya" ; "James Kempf"=20 > > Cc: > Sent: Tuesday, April 04, 2006 10:30 AM > Subject: RE: [Mip6] MOBIKE and MIP >=20 >=20 >=20 >=20 > > Vidya and Jim are trying to show us a scenario > where=20 > the IPsec tunnel and MIP tunnel terminate > on the same box=20 > and MOBIKE is used along with > MIPv6 signaling messages. >=20 > =3D> I think this is a scenario that should be avoided. >=20 > Hesham >=20 >=20 > > > > Vijay > > >=20 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 04 14:00:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQpp1-0000Fe-Ao; Tue, 04 Apr 2006 14:00:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQpp0-0000FO-Ii for mip6@ietf.org; Tue, 04 Apr 2006 14:00:06 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQpp0-0001k6-02 for mip6@ietf.org; Tue, 04 Apr 2006 14:00:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 4 Apr 2006 11:00:04 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MIPv6-SHIM6 interaction Thread-Index: AcZYEPYF80BSPPQMRQ6YSm+JXrd3uwAADG2Q From: "Vijay Devarapalli" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Subject: [Mip6] FW: MIPv6-SHIM6 interaction X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0071350237==" Errors-To: mip6-bounces@ietf.org --===============0071350237== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 RllJLg0KDQp0aGUgZm9sbG93aW5nIGRlc2NyaWJlcyBob3cgTUlQNiBhbmQgc2hpbTYgY291bGQN CndvcmsgdG9nZXRoZXIuIHBsZWFzZSBkb24ndCByZXNwb25kIHRvIHRoaXMgbWFpbC4NCmFueSBk aXNjdXNzaW9uIHNob3VsZCBoYXBwZW4gb24gdGhlIHNoaW02IG1haWxpbmcgDQpsaXN0Lg0KDQpW aWpheQ0KIA0KPiAtLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLS0NCj4gRnJv bTogbWFyY2VsbyBiYWdudWxvIGJyYXVuIDxtYXJjZWxvQGl0LnVjM20uZXM+DQo+IERhdGU6IEFw ciAzLCAyMDA2IDExOjIzIFBNDQo+IFN1YmplY3Q6IE1JUHY2LVNISU02IGludGVyYWN0aW9uICh3 YXMgUmU6IFNISU02IFdvcmtpbmcgR3JvdXAgTGFzdA0KPiBDYWxsIG9uIGRyYWZ0LWlldGYtc2hp bTYtcHJvdG8tMDQudHh0DQo+IFRvOiBzaGltNi13ZyA8c2hpbTZAcHNnLmNvbT4NCj4gDQo+IA0K PiBIaSBhbGwsDQo+IA0KPiBJbiB0aGUgU0hJTTYgd2cgbWVldGluZyBpbiBEYWxsYXMsIHNvbWUg cGVvcGxlIHBvaW50ZWQgb3V0IA0KPiB0aGF0IHdlIG5lZWQNCj4gdG8gdmVyaWZ5IHRoYXQgU0hJ TSBhbmQgTUlQdjYgd29ya2VkIHRvZ2V0aGVyIGluIGEgcmVhc29uYWJsZSB3YXkNCj4gd2l0aG91 dCBpbnRlcmZlcmluZyB3aXRoIGVhY2ggb3RoZXIuIEluIG9yZGVyIHRvIHZlcmlmeSB0aGF0LCAN Cj4gdGhlIGZpcnN0DQo+IHRoaW5nIHRvIGRvIGlzIHRvIGlkZW50aWZ5IHRoZSBzY2VuYXJpb3Mg d2hlcmUgdGhleSBhcmUgbGlrZWx5IHRvDQo+IGludGVyb3BlcmF0ZSBpLmUuIHdoZXJlIHRoZXJl IHNlZW1zIHRvIG1ha2UgbW9yZSBzZW5zZSB0byBydW4gTUlQIGFuZA0KPiBzaGltIHRvZ2VldGhl ci4gQWZ0ZXIgZGlzY3Vzc2luZyB0aGlzIHBvaW50IHdpdGggc2V2ZXJhbCBwZW9wbGUNCj4gaW5j bHVkaW5nIEVyaWssIEhlc2hhbSwgVmlqYXkgYW5kIERhdmUsIHRoZSBzY2VuYXJpb3MgYW5kIHVz ZSBjYXNlcw0KPiBkZXNjcmliZWQgYmVsb3cgZm9yIGEgam9pbnQgTUlQdjYtU2hpbTYgb3BlcmF0 aW9uIGhhdmUgYmVlbiANCj4gaWRlbnRpZmllZC4NCj4gDQo+IChOb3RlIHRoYXQgdGhpcyBpcyBt ZXJlbHkgbXkgdW5kZXJzdGFuZGluZyBvZiB0aGUgdG9waWMsIHNvIA0KPiBvbmx5IGkgaGF2ZQ0K PiB0aGUgcmVzcG9uc2liaWxpdHkgZm9yIGFueSBtaXN0YWtlIGhlcmUpDQo+IA0KPiBJbiBnZW5l cmFsIHRlcm1zLCBpdCBpcyBteSB1bmRlcnN0YW5kaW5nIHRoYXQgTUlQIGFuZCBTSElNIGludGVy YWN0DQo+IHByb3Blcmx5IGluIHRoZSB0aGUgaWRlbnRpZmllZCB2YWx1YWJsZSBzY2VuYXJpb3Ms IHdoaWxlIHNvbWUgZGV0YWlscw0KPiBtYXkgcmVxdWlyZSBzb21lIGFkZGl0aW9uYWwgdGhvdWdo dCwgZXNwZWNpYWxseSBpbiB0aGUgbGFzdCBzY2VuYXJpby4NCj4gDQo+IDEpLSBNdWx0aWhvbWVk IGhvbWUgbmV0d29yay4gSW4gdGhpcyBjYXNlLCB0aGUgSG9tZSBOZXR3b3JrIA0KPiBvZiBhIG1v YmlsZQ0KPiBub2RlIGlzIG11bHRpaG9tZWQuIFRoaXMgYmFzaWNhbGx5IG1lYW5zIHRoYXQgdGhl IGhvbWUgbmV0d29yayBoYXMNCj4gbXVsdGlwbGUgcHJlZml4ZXMvSVNQcyBhdmFpbGFibGUsIHJl c3VsdGluZyBpbiB0aGUgTU4gaGF2aW5nIG11bHRpcGxlDQo+IEhvQXMsIG9uZSBwZXIgYXZhaWxh YmxlIHByZWZpeC4gSW4gdGhpcyBjYXNlLCBpdCBzZWVtcyByZWFzb25hYmxlIHRvDQo+IGV4cGVj dCB0aGF0IHRoZSBNTiBjYW4gYmVuZWZpdCBmcm9tIHRoZSBtdWx0aWhvbWluZyBmZWF0dXJlcyAN Cj4gd2hlbiBpdCBpcw0KPiByb2FtaW5nLiBTbywgdGhpcyBiYXNpY2FsbHkgbWVhbnMgdGhhdCB0 aGUgTUlQdjYgcHJvdG9jb2wgaXMgdXNlZCB0bw0KPiBzdXBwb3J0IG1vYmlsaXR5IG9mIHRoZSBN TiB3aGVuIGl0IGlzIGF3YXkgZnJvbSBob21lIGFuZCB0aGUgU2hpbTYNCj4gcHJvdG9jb2wgaXMg dXNlZCB0byBwcm92aWRlIG11bHRpaG9taW5nIHN1cHBvcnQgdG8gYWxsIHRoZSANCj4gbm9kZXMg aW4gdGhlDQo+IG11bHRpaG9tZWQgc2l0ZSwgaW4gcGFydGljdWxhciB0byB0aGUgTU4uIEluIG90 aGVyIHdvcmRzLCANCj4gZWFjaCBwcm90b2NvbA0KPiBpcyB1c2VkIGZvciBpdHMgb3JpZ2luYWwg cHVycG9zZS4gVGhpcyB1c2UgY2FzZSBNVVNUIHdvcmsgcHJvcGVybHksDQo+IHNpbmNlIGl0IGlz IGp1c3QgdGhlIG5hdHVyYWwgY29uanVuY3Rpb24gb2YgYm90aCB0ZWNobm9sb2dpZXMuIEluIHRo aXMNCj4gY2FzZSwgc2hpbTYgaXMgbGF5ZXJlZCBhYm92ZSBNSVB2NiBhbmQgYmVsb3cgSVBTZWMu IFNvIHdoZW4gYSANCj4gcGFja2V0IGlzDQo+IGNvbWluZyBmcm9tIHRoZSBhcHBsaWNhdGlvbiBs YXllciwgaXQgaXMgZmlyc3RseSBwcm9jZXNzZWQgYnkgSVBTZWMsDQo+IHRoZW4gYnkgdGhlIFNI SU0gYW5kIGZpbmFsbHkgYnkgdGhlIE1JUHY2LiBNSVB2NiBzcGVjIGhhcyBzb21lIHdvcmRpbmcN Cj4gYWJvdXQgaG93IElQU2VjIGlzIHByb2Nlc3NpbmcsIHN0YXRpbmcgYmFzaWNhbGx5IHRoYXQg SVBTZWMgaXMgYWJvdmUNCj4gTUlQdjYsIHdoaWNoIGlzIGFyY2hpdGVjdHVyYWxseSBjb2hlcmVu dCB3aXRoIHRoaXMgc3RhY2sgbGF5b3V0DQo+IGNvbnNpZGVyZWQgaGVyZS4gUHJvYmFibHkgc29t ZSBhZGRpdGlvbmFsIGNvbnNpZGVyYXRpb24gYXJlIHJlcXVpcmVkLA0KPiBzaW5jZSB0aGUgU0hJ TSB3aWxsIGxheSBiZXR3ZWVuIElQU2VjIGFuZCBNSVB2NiwgYnV0IGl0IGlzIGV4cGVjdGVkDQo+ IHRoYXQgdGhlIGludGVyYWN0aW9uIGNhbiB3b3JrIHByb3Blcmx5LiBJbiB0aGlzIGNhc2UsIHRo ZSBhdmFpbGFibGUNCj4gSG9BcyBjYW4gZm9ybSBhIEhCQSBzZXQgc28gdGhhdCBhIGdpdmVuIGNv bW11bmljYXRpb24gY2FuIA0KPiBtb3ZlIGZyb20gb25lDQo+IEhvQSB0byBhbm90aGVyLg0KPiBP dmVyYWxsLCB0aGUgbWFwcGluZyB3b3VsZCBiZSBsaWtlIHRoaXM6IHRoZSBhcHBsaWNhdGlvbiAN Cj4gc2VuZHMgYSBwYWNrZXQNCj4gdXNpbmcgdGhlIFVMSUQgcGFpciAocHJvYmFibHkgaW5jbHVk aW5nIGEgSG9BKS4gVGhlIHBhY2tldCBpcyB0aGVuDQo+IHByb2Nlc3NlZCBieSB0aGUgc2hpbSBs YXllciwgd2hpY2ggaXQgbWF5IG1hcCB0aGUgVUxJRCB0byBhbg0KPiBhbHRlcm5hdGl2ZSBwYWly IGlmIGEgb3V0YWdlIGhhcyBvY2N1cnJlZC4gVGhlIGFsdGVybmF0aXZlIGFkZHJlc3MsDQo+IHdp bGwgYWxzbyBiZSBhIEhvQS4gdGhlbiwgdGhlIHBhY2tldCBpcyBwYXNzZWQgdG8gdGhlIE1JUHY2 IGxheWVyLA0KPiB3aGljaCB3aWxsIHBlcmZvcm0gdGhlIEhvQSBDb0EgbWFwcGluZyAoQlQgb3Ig Uk8gbW9kZXMpDQo+IA0KPiAyKS0gSEEtTU4gdHVubmVsIGZhdWx0IHRvbGVyYW5jZS4gQ29uc2lk ZXIgdGhlIGNhc2Ugd2hlcmUgdGhlIEhBIGhhcw0KPiBtdWx0aXBsZSBhZGRyZXNzZXMsIHdoZXRo ZXIgYmVjYXVzZSBtdWx0aXBsZSBwcmVmaXhlcyBhcmUgYXZhaWxhYmxlIG9yDQo+IG11bHRpcGxl IGludGVyZmFjZXMuIEluIGFkZGl0aW9uLCB0aGUgTU4gbWF5IGFsc28gaGF2ZSBtdWx0aXBsZQ0K PiBhZGRyZXNzZXMsIGJlY2F1c2UgdGhlIHZpc2l0ZWQgbmV0d29yayBpcyBtdWx0aWhvbWVkIGFu ZC9vciANCj4gYmVjYXVzZSB0aGUNCj4gTU4gaGFzIG11bHRpcGxlIGludGVyZmFjZXMuIEluIHRo aXMgY2FzZSwgdGhlIHNoaW0gaXMgdXNlZCB0byBwcm92aWRlDQo+IGFkZGl0aW9uYWwgZmF1bHQg dG9sZXJhbmNlIHRvIHRoZSB0dW5uZWwgcGF0aCwgdGhlIHNoaW0gaXMgdXNlZCBpbiB0aGUNCj4g dHVubmVsIGludGVyZmFjZS4gSW4gdGhpcyBjYXNlLCB0aGUgc2hpbSBpcyBhc3NvY2lhdGVkIHRv IHRoZSB0dW5uZWwNCj4gaW50ZXJmYWNlIGFuZCBub3QgdG8gdGhlIElQIGludGVyZmFjZSB0aGF0 IGlzIHJ1bm5pbmcgTUlQdjYuIEluIHRoaXMNCj4gY2FzZSwgU2hpbSBpcyBsb2NhdGVkIGJlbG93 IElQU2VjIGxheWVyIG9mIHRoZSB0dW5uZWwgaW50ZXJmYWNlLiBBZ2Fpbg0KPiB0aGUgaW50ZXJh Y3Rpb24gaW4gdGhpcyBjYXNlIGlzIGFyY2hpdGVjdHVyYWxseSBjbGVhbi4gSXQgbWF5IGJlDQo+ IHBvc3NpYmxlIHRvIHByb3ZpZGUgc3VwcG9ydCBmb3IgdGhpcyBjYXNlIHdpdGhvdXQgdXNpbmcg dGhlIHNoaW0uDQo+IEhvd2V2ZXIsIGV2ZW4gaW4gdGhpcyBjYXNlLCBpdCBtYXkgbWFrZSBzZW5z ZSB0byByZXVzZSBzb21lIA0KPiBvZiB0aGUgc2hpbQ0KPiBtZWNoYW5pc21zIGxpa2UgdGhlIGZh aWx1cmUgZGV0ZWN0aW9uIGFuZCBwYXRoIGV4cGxvcmF0aW9uIG1lY2hhbmlzbXMNCj4gaW4gYW4g YWx0ZXJuYXRpdmUgTUlQdjYgYmFzZWQgc29sdXRpb24uIFNvLCB0aGlzIGNhc2UgTUFZIGJlIHN1 cHBvcnRlZA0KPiBidXQgb3RoZXIgY29uZmlndXJhdGlvbnMgdGhhdCByZWx5IG9ubHkgaW4gTUlQ IG1heSByZXN1bHQgbW9yZQ0KPiBhdHRyYWN0aXZlIHRvIHByb3ZpZGUgdGhlIHJlcXVpcmVkIGZl YXR1cmVzLCByZXVzaW5nIGV4aXN0aW5nIHNoaW02DQo+IG1lY2hhbmlzbXMNCj4gDQo+IDMpLSBT aGltNiBiYXNlZCBSTy4gVGhpcyBjYXNlIGlzIHNpbWlsYXIgdG8gdGhlIGZpcnN0IHNjZW5hcmlv LCBvbmx5DQo+IHRoYXQgQ29BcyBhcmUgYWxzbyBwcmVzZW50ZWQgdG8gdGhlIHNoaW0uIFNvIGlu IGNhc2Ugb2YgYSBmYWlsdXJlLCB0aGUNCj4gc2hpbSBtYXkgc2VsZWN0IGEgQ29BIGFzIGFuIGFs dGVybmF0aXZlIGxvY2F0b3IgcmF0aGVyIHRoYW4gYSANCj4gSG9BLiBJZiBhDQo+IENvQSBpcyBz ZWxlY3RlZCwgdGhlbiB0aGUgb3V0Z29pbmcgcGFja2V0IG5lZWRzIG5vdCB0byBiZSBwcm9jZXNz ZWQgYnkNCj4gdGhlIE1JUHY2IGxheWVyIChubyBCQ0UgaXMgYXZhaWxhYmxlKSBhbmQgdGhlIHJl c3VsdCBpcyBhIHNoaW02IGJhc2VkDQo+IFJPIG1vZGUsIHdoZXJlIHBhY2tldCBmbG93cyBkaXJl Y3RseSBiZXR3ZWVuIHRoZSBNTiBhbmQgdGhlIENOLiBXaGlsZQ0KPiBpdCBzZWVtcyB0byB1cyB0 aGF0IHRoaXMgaXMgd29ya2FibGUsIGF0IHRoaXMgcG9pbnQgaXQgaXMgbm90IGNsZWFyIHRvDQo+ IHVzIGhvdyB2YWx1YWJsZSBpcyB0aGlzIGNvbmZpZ3VyYXRpb24uDQo+IA0KPiBFbCAyMy8wMy8y MDA2LCBhIGxhcyAxNzoyOSwgR2VvZmYgSHVzdG9uIGVzY3JpYmnDszoNCj4gDQo+ID4gRm9sa3Ms DQo+ID4NCj4gPiAgICAgICAgIFRoaXMgbm90ZSBzdGFydHMgdGhlIFdHIExhc3QgQ2FsbCBmb3Ig Y29tbWVudHMgb24NCj4gPiAgICAgICAgIGRyYWZ0LWlldGYtc2hpbTYtcHJvdG8tMDQudHh0LCAi TGV2ZWwgMyBtdWx0aS1ob21pbmcgc2hpbQ0KPiA+ICAgICAgICAgcHJvdG9jb2wiLg0KPiA+DQo+ ID4gICAgICAgICBJdCBjYW4gYmUgZm91bmQgYXQ6DQo+ID4NCj4gPiBmdHA6Ly9mdHAuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtc2hpbTYtcHJvdG8tMDQudHh0DQo+ID4NCj4g PiAgICAgICAgIFRoZSBkb2N1bWVudCBpcyBpbnRlbmRlZCB0byBiZSBzdWJtaXR0ZWQgYnkgdGhl IA0KPiBXb3JraW5nIEdyb3VwDQo+ID4gICAgICAgICB0byB0aGUgSUVTRyBmb3IgcHVibGljYXRp b24gYXMgYSBQcm9wb3NlZCBTdGFuZGFyZC4NCj4gPg0KPiA+ICAgICAgICAgUGxlYXNlIHJldmll dyB0aGUgZG9jdW1lbnQgY2FyZWZ1bGx5LCBhbmQgc2VuZCB5b3VyIGZlZWRiYWNrDQo+ID4gdG8g dGhlDQo+ID4gICAgICAgICBTSElNNiBsaXN0LiAgUGxlYXNlIGFsc28gaW5kaWNhdGUgaW4geW91 ciByZXNwb25zZSANCj4gd2hldGhlciBvcg0KPiA+IG5vdA0KPiA+ICAgICAgICAgeW91IGJlbGll dmUgdGhhdCB0aGlzIGRvY3VtZW50IGlzIHJlYWR5IHRvIGdvIHRvIHRoZSBJRVNHLg0KPiA+DQo+ ID4gICAgICAgICBUaGlzIExhc3QgQ2FsbCB3aWxsIGVuZCBvbiBGcmlkYXkgMTQgQXByIDIwMDYg YXQgMDgwMCBBRVNUDQo+ID4gICAgICAgICAoVVRDKzEwKS4NCj4gPg0KPiA+ICAgICAgICAgVGhh bmtzLA0KPiA+DQo+ID4NCj4gPiAgICAgICAgICAgICAgIEdlb2ZmICYgS3VydGlzDQo+ID4NCj4g PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+ID4NCj4gPiBBZGRpdGlvbmFsIGNvbW1lbnRzIHRvIHRoaXMgTGFzdCBDYWxsOg0KPiA+ DQo+ID4gbyBUaGUgdGhyZWUgd2VlayBwZXJpb2QgZm9yIHRoZSBXRyBMYXN0IENhbGwgaXMgdG8g YWxsb3cgc29tZSBsZWV3YXkNCj4gPiBmb3INCj4gPiAgIHBvc3QtSUVURiByZWNvdmVyeSENCj4g Pg0KPiA+IG8gV2UgYWxzbyBub3RlIHRoYXQgd2UgaGF2ZSBhbiBvdXRzdGFuZGluZyB0b3BpYyBv ZiANCj4gY29tcGF0aWJpbGl0eSB3aXRoDQo+ID4gICBNb2JpbGUgSVB2NiBhbmQgU0hJTTYgYXMg ZGlzY3Vzc2VkIGluIHRoZSBXb3JraW5nIEdyb3VwIA0KPiBtZWV0aW5nIHRoaXMNCj4gPiAgIHdl ZWsuIFRoaXMgbGFzdCBjYWxsIGhhcyBiZWVuIGdlbmVyYXRlZCBvbiB0aGUgYmFzaXMgb2YgDQo+ IHZlcmJhbCBhZHZpY2UNCj4gPiAgIHByb3ZpZGVkIGJ5IHRoZSBkb2N1bWVudCdzIGVkaXRvcnMg dGhhdCB0aGlzIG1hdHRlciBoYXMgYmVlbg0KPiA+IGRpc2N1c3NlZA0KPiA+ICAgd2l0aCBNb2Jp bGUgSVB2NiBmb2xrIGFuZCB0aGF0IHRoZXJlIGFyZSBubyBzZXJpb3VzIGlzc3VlcyBvZg0KPiA+ ICAgaW5jb21wYXRpYmlsaXR5IGFudGljaXBhdGVkLiBJIGV4cGVjdCBhIG5vdGUgdG8gdGhpcyBl ZmZlY3QgZnJvbQ0KPiA+IE1hcmNlbG8NCj4gPiAgIEJhZ251bG8gc3VtbWFyaXppbmcgdGhlIG91 dGNvbWVzIG9mIHRoaXMgZGlzY3Vzc2lvbiB0byBiZSANCj4gcG9zdGVkIHRvDQo+ID4gdGhlDQo+ ID4gICBTSElNNiBXRyBkdXJpbmcgdGhpcyBMYXN0IENhbGwgcGVyaW9kLg0KPiA+DQo+ID4gbyBX ZSBoYXZlIGNvbnN1bHRlZCB3aXRoIHRoZSB0ZWNobmljYWwgYWR2aXNvcnMgdG8gdGhpcyANCj4g V29ya2luZyBHcm91cA0KPiA+IGFuZA0KPiA+ICAgdGhleSBoYXZlIGluZGljYXRlZCB0aGF0IGFy ZSBoYXBweSBmb3IgdXMgdG8gcHJvY2VlZCB3aXRoIA0KPiB0aGlzIGxhc3QNCj4gPiBjYWxsIGF0 DQo+ID4gICB0aGlzIHRpbWUuDQo+ID4NCj4gPg0KPiA+DQo+IA0K --===============0071350237== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0071350237==-- From mip6-bounces@ietf.org Tue Apr 04 14:51:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQqco-0000oy-O7; Tue, 04 Apr 2006 14:51:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQqcn-0000on-1e for mip6@ietf.org; Tue, 04 Apr 2006 14:51:33 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQqcl-0003ju-N0 for mip6@ietf.org; Tue, 04 Apr 2006 14:51:33 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k34IpK1N011225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Apr 2006 11:51:22 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k34Ip8pw004029; Tue, 4 Apr 2006 11:51:20 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Apr 2006 11:51:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] MOBIKE and MIP Date: Tue, 4 Apr 2006 11:51:14 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF001AF2B5C@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] MOBIKE and MIP Thread-Index: AcZYDtf4jHrDLSqKRcaIP2blwgq+3AAAYLtwAAH9JpA= From: "Soliman, Hesham" To: "Narayanan, Vidya" , "James Kempf" , "Vijay Devarapalli" X-OriginalArrivalTime: 04 Apr 2006 18:51:18.0837 (UTC) FILETIME=[C2448E50:01C65818] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > This approach is taking the view that in the presence of=20 > MIP6, it supercedes everything else and has control over key=20 > management for applications beyond MIP6.=20 =3D> Could you translate that into a more detailed scenario? I don't see how this conclusion can be made based on this discussion. Controlling key management was never the issue here. I don't think this=20 > is the right view at all. It is quite practical to envision=20 > other applications having the same endpoints (MN and HA)=20 > wanting to use the IKEv2 SA for protecting other signaling.=20 =3D> I still don't see how that leads to using MOBIKE. No one=20 excluded this scenario, but it does *not* imply using MOBIKE.=20 Hesham > Avoiding that just makes us short-sighted.=20 >=20 > Vidya >=20 > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com]=20 > > Sent: Tuesday, April 04, 2006 10:44 AM > > To: Soliman, Hesham; Vijay Devarapalli; Narayanan, Vidya > > Cc: mip6@ietf.org > > Subject: Re: [Mip6] MOBIKE and MIP > >=20 > > Then maybe that's what the document needs to say. > >=20 > > jak > >=20 > > ----- Original Message ----- > > From: "Soliman, Hesham" > > To: "Vijay Devarapalli" ;=20 > > "Narayanan, Vidya" ; "James Kempf"=20 > > > > Cc: > > Sent: Tuesday, April 04, 2006 10:30 AM > > Subject: RE: [Mip6] MOBIKE and MIP > >=20 > >=20 > >=20 > >=20 > > > Vidya and Jim are trying to show us a scenario > where=20 > > the IPsec tunnel and MIP tunnel terminate > on the same box=20 > > and MOBIKE is used along with > MIPv6 signaling messages. > >=20 > > =3D> I think this is a scenario that should be avoided. > >=20 > > Hesham > >=20 > >=20 > > > > > > Vijay > > > > >=20 > >=20 > >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 04 16:06:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQrn3-0004iy-6o; Tue, 04 Apr 2006 16:06:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQrn1-0004it-UL for mip6@ietf.org; Tue, 04 Apr 2006 16:06:11 -0400 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQrn1-0006vf-H9 for mip6@ietf.org; Tue, 04 Apr 2006 16:06:11 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.10.03) with ESMTP id k34JxxXI004042; Tue, 4 Apr 2006 21:59:59 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [192.44.77.29]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.09.01) with ESMTP id k34JxuX0004038; Tue, 4 Apr 2006 21:59:56 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id k34JxtJE006830; Tue, 4 Apr 2006 21:59:56 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200604041959.k34JxtJE006830@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Soliman, Hesham" Subject: Re: [Mip6] MOBIKE and MIP In-reply-to: Your message of Tue, 04 Apr 2006 10:30:06 PDT. <1487A357FD2ED544B8AD29E528FF9DF001AF2A47@NAEX06.na.qualcomm.com> Date: Tue, 04 Apr 2006 21:59:55 +0200 X-Virus-Scanned: amavisd-new at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: mip6@ietf.org, James Kempf , Vijay Devarapalli X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org In your previous mail you wrote: > Vidya and Jim are trying to show us a scenario > where the IPsec tunnel and MIP tunnel terminate > on the same box and MOBIKE is used along with > MIPv6 signaling messages. => I think this is a scenario that should be avoided. => I agree: this is the scenario I said about it that "it doesn't make sense". Regards Francis.Dupont@point6.net _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 05 19:29:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRHRI-0006QM-MD; Wed, 05 Apr 2006 19:29:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRHRH-0006QH-FR for mip6@ietf.org; Wed, 05 Apr 2006 19:29:27 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRHRG-0002hW-5o for mip6@ietf.org; Wed, 05 Apr 2006 19:29:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Apr 2006 16:29:21 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Changes to draft-ietf-mip6-ikev2-ipsec Thread-Index: AcZZCMQM8BCnPZoERMiwqpaB+2jStw== From: "Vijay Devarapalli" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Mip6] Changes to draft-ietf-mip6-ikev2-ipsec X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hello all, I want to add some more text to=20 draft-ietf-mip6-ikev2-ipsec to clarify the use of "tunnel all" mode. a pre-06 version of the draft is at http://www.dvijay.com/ietf/internet-drafts/mip6/mip6_ikev2.txt a diff from version 05 to 06 is at http://www.dvijay.com/ietf/internet-drafts/mip6/diff-05to06.html the current status for this draft is "AD=20 Evaluation". it was felt that the changes are=20 significant enough to refer the changes to the working group before making the changes. there will be a short working group call later on on these changes. the tunnel mode was already introduced with=20 the addition of the section on IPsec granularity=20 considerations in version 04. the new text is only for better clarity. comments are welcome. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Apr 06 00:53:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRMUp-0002uL-9h; Thu, 06 Apr 2006 00:53:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRMUm-0002sQ-FK for mip6@ietf.org; Thu, 06 Apr 2006 00:53:24 -0400 Received: from f.csce.kyushu-u.ac.jp ([133.5.33.1]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FRMUg-0006ro-JB for mip6@ietf.org; Thu, 06 Apr 2006 00:53:24 -0400 Received: (qmail 9138 invoked from network); 6 Apr 2006 04:53:16 -0000 Received: from unknown (HELO ?172.17.3.211?) (192.168.77.254) by 192.168.77.101 with SMTP; 6 Apr 2006 04:53:16 -0000 Date: Thu, 06 Apr 2006 13:53:16 +0900 From: Teruaki Kitasuka To: manet@ietf.org, mip4@ietf.org, mip6@ietf.org, mipshop@ietf.org, monami6@ietf.org, nemo@ietf.org Message-Id: <20060406135026.5228.KITASUKA@f.csce.kyushu-u.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.24.02 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: Subject: [Mip6] CfP - 3rd Int. Conf. on Mobile Computing and Ubiquitous Networking (ICMU2006) at London, UK X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org (Apologies if you receive multiple copies of this message) 2 weeks left for submission. ======================================================================== C A L L F O R P A P E R S ======================================================================== The Third International Conference on Mobile Computing and Ubiquitous Networking (ICMU2006) October 11-13, 2006 BCS London Office, London, UK http://www.icmu.org/icmu2006/ Sponsored by: IPSJ SIG-MBL (Information Processing Society of Japan, Special Interest Group of Mobile Computing and Ubiquitous Networking) Technically co-sponsored by: BCS (British Computer Society), IEE (Institution of Electrical Engineers), and IEEE ITS Society, Technical Committee on Mobile Commuications & Applications Supported by: ICF (International Communications Foundation) SCOPE: Mobile computing aims at ubiquitous user access to computer application. To make it possible, networking technology which enables Internet access anytime and everywhere, i.e. ubiquitous networking is necessary. It is obvious that with the accelerating trends towards mobile networks, ad-hoc networks, and wireless networks, mobile computing and ubiquitous networking will play an important role in future network. This conference is aimed at providing researchers and practitioners in this hot research area a forum for discussion and collaboration. Authors are invited to submit papers addressing, but not limited to, the following topics: - Network management for ubiquitous networking - Data management for mobile computing - Mobile device management - Performance evaluation for mobile computing and ubiquitous networking systems - Broadcast communications - Network architectures, protocols, or service models for ubiquitous networking - Security in mobile computing and ubiquitous networking - Mobile OS - Wireless and mobile communications - 4G wireless communications - Mobile Internetworking - Ad-hoc networks - Network mobility - Mesh networks - Sensor networks - Location-based services SUBMISSION INSTRUCTIONS: Papers are solicited as full papers of no more than 8 pages, each of which will be subject to a full review process. Submission should already follow the author guidelines as specified in the web site below. An electronic, PDF-based submission of papers is mandatory. Please check the web site of the conference http://www.icmu.org/icmu2006/ for further submission instructions. After the conference, a selected number of papers will be published as special issues in IPSJ journal and IPSJ Digital Courier. Please check the web site of IPSJ http://www.ipsj.or.jp/08editt/dc/index.html for the details of IPSJ Digital Coulier. IMPORTANT DATES: ########################################################## # Deadline for submissions: April 22, 2006 # # Notification of acceptance: July 8, 2006 # # Camera ready due: July 31, 2006 # ########################################################## ORGANIZING COMMITTEE: General Chair: Chai-Keong Toh (Queen Mary University of London, UK) Technical Program Committee Co-Chairs: Susumu Ishihara (Shizuoka University, Japan) Eiji Kamioka (National Institute of Informatics, Japan) Publication Co-Chairs: Gen Kitagata (Tohoku University, Japan) Yang Yang (University College London, UK) Publicity Co-Chairs: Teruaki Kitasuka (Kyushu University, Japan) Kun Yang (University of Essex, UK) Local Arrangement Chair: David Martland (Kingston University London, UK) Treasurers: David Martland (Kingston University London, UK) Tomohiko Yagyu (NEC, Japan) Registration Co-Chairs: Jindong Hou (France Telecom, UK) Homare Murakami (NICT, Japan) ICMU STEERING COMMITTEE: Tadanori Mizuno (Shizuoka University, Japan) Osamu Takahashi (Future University-Hakodate, Japan) Takashi Watanabe (Shizuoka University, Japan) Miki Yamamoto (Kansai University, Japan) TECHNICAL PROGRAM COMMITTEE: Mohammed Atiquzzaman (University of Oklahoma, USA) Xiuzhen Cheng (George Washington University, USA) We Duke Cho (Ajou University, Korea) John Gardiner (Bradford University, UK) Teruo Higashino (Osaka University, Japan) Choong Seon Hong (Kyung Hee University, Korea) Russell Hsing (Telcordia Technologies, USA) Chung Ming Huang (National Cheng Kung University, Taiwan) Joseph Hui (Arizona State University, USA) Masugi Inoue (NICT, Japan) Masahiro Ishiyama (Toshiba Corporation, Japan) Holger Karl (University of Paderborn, Germany) Hughes Kester (Qinetiq Ltd, UK) Dongkyun Kim (Kyungpook National University, Korea) Peter Langendoerfer (IHP Microelectronics, Germany) Madjid Merabti (Liverpool John Moores University, UK) Isabelle Moreau (Mitsubishi Electric ITE, France) Hiroyuki Morikawa (University of Tokyo, Japan) Yasuto Nakanishi (Keio University, Japan) Ken Ohta (NTT DoCoMo, Japan) Ryouji Ono (Mitsubishi Electric, Japan) Mohamed Ould-Khaoua (University of Glasgow, UK) Antonio Pescape (University of Napoli, Italy) Petar Popovski (Aalborg University, Denmark) Jeremy Randles (British Telecom, UK) Ichiro Satoh (National Institute of Informatics, Japan) Winston Seah (Institute for Infocomm Research, Singapore) Hiroshi Shigeno (Keio University, Japan) Biplab Sikdar (Rensselaer Polytechnic Institute, USA) David Simplot-Ryl (University of Lille 1, France) Tatsuya Suda (University of California Irvine, USA) Shinta Sugimoto (Nippon Ericsson, Japan) Keisuke Suwa (Musashi Institute of Technology, Japan) Kevin W. Tsai (University of California, Irvine, USA) Xin Wang (Fudan University, China) Neil Williams (ERA Technology Ltd, UK) Nik Van den Wingaert (University of Antwerp, Belgium) Hirozumi Yamaguchi (Osaka University, Japan) Kun Yang (Essex University, UK) Yang Yang (University College London, UK) Masashi Yano (Hitachi Ltd, Japan) Hidetoshi Yokota (KDDI R&D Laboratories, Japan) Ekio Yoneki (Cambridge University, UK) Qing-An Zeng (University of Cincinnati, USA) ======================================================================== _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Apr 06 15:25:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRa6q-0008RZ-UQ; Thu, 06 Apr 2006 15:25:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRa6p-0008RU-GV for mip6@ietf.org; Thu, 06 Apr 2006 15:25:35 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRa6o-0004Av-4L for mip6@ietf.org; Thu, 06 Apr 2006 15:25:35 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k36JPWbw021923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 6 Apr 2006 12:25:33 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k36JPVT3020282 for ; Thu, 6 Apr 2006 12:25:32 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 12:25:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Apr 2006 12:25:29 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB846567E4@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Bootstrapping on the home link Thread-Index: AcZZr92C55IMm5nlRSKEAKDuchT/gw== From: "Narayanan, Vidya" To: X-OriginalArrivalTime: 06 Apr 2006 19:25:31.0994 (UTC) FILETIME=[DEDEF3A0:01C659AF] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [Mip6] Bootstrapping on the home link X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org All, Currently, none of the bootstrapping documents seem to address the scenario of bootstrapping of the MN on the home link. Here is the scenario:=20 MN powers up on the home link. It has no means of knowing it is on the home link. Hence, it configures an IP address that it thinks is a CoA (say, statelessly). It then goes about doing IKEv2 and trying to get a home address, at which point, it realizes that the home prefix is the same as the prefix on which it just got an IP address. MN and HA behavior in this scenario needs to be addressed.=20 There are multiple ways in which this could work. I walked through a few different options and here is one that I think would probably work best: 1. MN configures CoA 2. MN performs IKEv2 - HA realizes from the CoA that the MN is home 3. If the CoA is acceptable as HoA, HA returns the same address in the CFG_REPLY.=20 4. If not, HA proposes a HoA in the INTERNAL_IP6_ADDRESS attribute of the CFG_REPLY.=20 5. Either way, MN realizes it is home, based on prefix matching 6. If the CoA was accepted as the HoA, MN uses that. If not, it gives up the CoA and uses the HA proposed address as the HoA.=20 7. MN may send BU to de-register (so that other things like DNS updates, etc. can happen and doesn't need to wait till handoff time).=20 If this behavior is already discussed somewhere, please point me to it - apologies in advance for not doing my homework in that case :) If it is not described anywhere, thoughts on this?=20 Regards, Vidya _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Apr 09 05:57:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSWfc-0003KG-Uy; Sun, 09 Apr 2006 05:57:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSWfa-0003I9-TC for mip6@ietf.org; Sun, 09 Apr 2006 05:57:22 -0400 Received: from maile.telecomitalia.it ([156.54.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSWfX-0005aN-TC for mip6@ietf.org; Sun, 09 Apr 2006 05:57:22 -0400 Received: from ptpxch007ba020.idc.cww.telecomitalia.it ([156.54.240.50]) by maile.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Sun, 9 Apr 2006 11:57:18 +0200 Received: from PTPEVS108BA020.idc.cww.telecomitalia.it ([156.54.241.228]) by ptpxch007ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.211); Sun, 9 Apr 2006 11:57:18 +0200 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mip6] Bootstrapping on the home link Importance: normal Date: Sun, 9 Apr 2006 11:56:58 +0200 Priority: normal Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Bootstrapping on the home link thread-index: AcZZr92C55IMm5nlRSKEAKDuchT/gwCCUpcA From: "Giaretta Gerardo" To: "Narayanan, Vidya" X-OriginalArrivalTime: 09 Apr 2006 09:57:18.0021 (UTC) FILETIME=[FC84C750:01C65BBB] X-Spam-Score: 0.5 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1911899014==" Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============1911899014== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----=_NextPart_000_53880_01C65BCC.C02F5020" This is a multi-part message in MIME format. ------=_NextPart_000_53880_01C65BCC.C02F5020 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Vidya, some comments on this, inline. One more general comment: this scenario seems not applicable to the split scenario document since the base assumption is that there is not relationship between access service and mobility service. It may be in the scope of the integrated scenario, as a local HA assignment case. > All, > Currently, none of the bootstrapping documents seem to address the > scenario of bootstrapping of the MN on the home link. Here is the > scenario:=20 >=20 > MN powers up on the home link. It has no means of knowing it is on the > home link.=20 We cannot say that the MN is on the home link or not until a HA assignment is performed. I think you are addressing the case of a HA in the same link of the MN and the MN tries to bootstrap with that HA. In this scenario, based on RFC3775, the HA sends RAs with H bit set and therefore the DNS discovery may not be performed, but this is already defined in rfc3775.=20 > Hence, it configures an IP address that it thinks is a CoA > (say, statelessly). It then goes about doing IKEv2 and trying to get a > home address, at which point, it realizes that the home prefix is the > same as the prefix on which it just got an IP address. MN and HA > behavior in this scenario needs to be addressed.=20 >=20 Ideally, the MN does not need any SA if it is still in the home link. The IPsec SA is needed only when the MN hands over to a foreign link.=20 I guess there are two options here: - the MN performs IKEv2 and establishes an IPsec SA even if it is in the home link. Note that this may be useless (since the MN may always remain in the home link) and this SA must not be used until the MN moves to another link - the MN does not perform IKev2 as soon as it stays in the home link. At the time of the first handover, it runs IKEv2. This has one drawback since it implies a higher handover latency for the first handover. Another issue to be considered is that the HoA assigned in IKEv2 exchange must be the same used before by the MN in the home link.=20 > There are multiple ways in which this could work. I walked=20 > through a few > different options and here is one that I think would probably=20 > work best: >=20 >=20 > 1. MN configures CoA > 2. MN performs IKEv2 - HA realizes from the CoA that the MN is home As mentioned, the MN itself should realize it is at home based on H bit set in the Router Advertisements. Moreover the MN technically does not need an IPsec SA while at home. > 3. If the CoA is acceptable as HoA, HA returns the same address in the > CFG_REPLY.=20 The possibility to ask for an explicit address is already present in the current specification. > 4. If not, HA proposes a HoA in the INTERNAL_IP6_ADDRESS attribute of > the CFG_REPLY.=20 > 5. Either way, MN realizes it is home, based on prefix matching If it is performing bootstrapping with a specific HA, it has already realized it is at home, IMO. > 6. If the CoA was accepted as the HoA, MN uses that. If not,=20 > it gives up > the CoA and uses the HA proposed address as the HoA.=20 > 7. MN may send BU to de-register (so that other things like=20 > DNS updates, > etc. can happen and doesn't need to wait till handoff time).=20 >=20 > If this behavior is already discussed somewhere, please point=20 > me to it - > apologies in advance for not doing my homework in that case :) >=20 > If it is not described anywhere, thoughts on this?=20 >=20 One more thought: there are no current deployments of MIP (3GPP2, WiMAX) where this scenario can occur. The home links are always virtual links. Are there real deployments where this may occur? Or are we mainly considering an academic issue? Regards, --Gerardo > Regards, > Vidya >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons = above and may contain confidential information. If you have received the = message in error, be informed that any use of the content hereof is = prohibited. Please return it immediately to the sender and delete the = message. Should you have any questions, please contact us by replying to = webmaster@telecomitalia.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- ------=_NextPart_000_53880_01C65BCC.C02F5020 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi = Vidya,

some comments on this, inline. One more general comment: = this scenario
seems not applicable to the split scenario document = since the base
assumption is that there is not relationship between = access service and
mobility service. It may be in the scope of the = integrated scenario, as
a local HA assignment case.

> = All,
> Currently, none of the bootstrapping documents seem to address = the
> scenario of bootstrapping of the MN on the home link. Here is = the
> scenario:
>
> MN powers up on the home link. It has no = means of knowing it is on the
> home link.

We cannot say that = the MN is on the home link or not until a HA
assignment is performed. = I think you are addressing the case of a HA in
the same link of the = MN and the MN tries to bootstrap with that HA. In
this scenario, = based on RFC3775, the HA sends RAs with H bit set and
therefore the = DNS discovery may not be performed, but this is already
defined in = rfc3775.

> Hence, it configures an IP address that it thinks is = a CoA
> (say, statelessly). It then goes about doing IKEv2 and trying = to get a
> home address, at which point, it realizes that the home = prefix is the
> same as the prefix on which it just got an IP = address. MN and HA
> behavior in this scenario needs to be addressed. =
>

Ideally, the MN does not need any SA if it is still in the = home link.
The IPsec SA is needed only when the MN hands over to a = foreign link.
I guess there are two options here:
- the MN = performs IKEv2 and establishes an IPsec SA even if it is in the
home = link. Note that this may be useless (since the MN may always = remain
in the home link) and this SA must not be used until the MN = moves to
another link
- the MN does not perform IKev2 as soon as = it stays in the home link. At
the time of the first handover, it runs = IKEv2. This has one drawback
since it implies a higher handover = latency for the first handover.
Another issue to be considered is = that the HoA assigned in IKEv2
exchange must be the same used before = by the MN in the home link.

> There are multiple ways in which = this could work. I walked
> through a few
> different options and = here is one that I think would probably
> work best:
>
> =
> 1. MN configures CoA
> 2. MN performs IKEv2 - HA realizes from = the CoA that the MN is home

As mentioned, the MN itself should = realize it is at home based on H bit
set in the Router = Advertisements. Moreover the MN technically does not
need an IPsec SA = while at home.

> 3. If the CoA is acceptable as HoA, HA returns = the same address in the
> CFG_REPLY.

The possibility to ask = for an explicit address is already present in the
current = specification.

> 4. If not, HA proposes a HoA in the = INTERNAL_IP6_ADDRESS attribute of
> the CFG_REPLY.
> 5. Either = way, MN realizes it is home, based on prefix matching

If it is = performing bootstrapping with a specific HA, it has already
realized = it is at home, IMO.

> 6. If the CoA was accepted as the HoA, MN = uses that. If not,
> it gives up
> the CoA and uses the HA = proposed address as the HoA.
> 7. MN may send BU to de-register (so = that other things like
> DNS updates,
> etc. can happen and = doesn't need to wait till handoff time).
>
> If this behavior is = already discussed somewhere, please point
> me to it -
> = apologies in advance for not doing my homework in that case :)
> =
> If it is not described anywhere, thoughts on this?
> =

One more thought: there are no current deployments of MIP = (3GPP2, WiMAX)
where this scenario can occur. The home links are = always virtual links.
Are there real deployments where this may = occur? Or are we mainly
considering an academic = issue?

Regards,
--Gerardo

> Regards,
> Vidya
> =
> _______________________________________________
> Mip6 mailing = list
> Mip6@ietf.org
> = https://www1.ietf.org/mailman/listinfo/mip6
>
--------------------------------------------------------------------=
CONFIDENTIALITY=20 NOTICE
This message and its attachments are addressed solely to the=20 persons
above and may contain confidential information. If you have=20 received
the message in error, be informed that any use of the = content=20 hereof
is prohibited. Please return it immediately to the sender and=20 delete
the message. Should you have any questions, please contact us=20 by
replying to webmaster@telecomitalia.it.
        = Thank=20 you
           =             &= nbsp;           &n= bsp;   =20 www.telecomitalia.it
--------------------------------------------------------------------=
------=_NextPart_000_53880_01C65BCC.C02F5020-- --===============1911899014== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1911899014==-- From mip6-bounces@ietf.org Sun Apr 09 14:01:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSeER-0002uD-E1; Sun, 09 Apr 2006 14:01:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSeEQ-0002u8-TQ for mip6@ietf.org; Sun, 09 Apr 2006 14:01:50 -0400 Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSeEO-0008CD-Nv for mip6@ietf.org; Sun, 09 Apr 2006 14:01:50 -0400 Received: from [212.149.115.94] (unknown [212.149.115.94]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 464F94D836; Mon, 10 Apr 2006 03:01:40 +0900 (JST) Date: Sun, 09 Apr 2006 21:01:34 +0300 From: Shinta Sugimoto To: "Vijay Devarapalli" Subject: Re: [Mip6] Changes to draft-ietf-mip6-ikev2-ipsec In-Reply-To: References: Message-Id: <20060409201752.662E.SHINTA@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.21.03 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hello Vijay, I've parsed the diff from 05 to 06 and had some comments/questions. In the "tunnel all" mode, do you assume that the IKEv2 takes the role of updating the outer endpoint address of the IPsec tunnel established between the MN and HA ? I mean, in my view, BU message meant to be the trigger for updating the endpoint address. In this sense, it is actually convinient for the MN and HA to have transport mode SA pair which is agnostic on MN's CoA. If we assume that all mobility signals (including BU) are sent over the IPsec tunnel, I believe MN and HA are required to run MOBIKE (or re-establish the IPsec SA) prior to the home registration. So, I think the draft should mention implications/side-effect that "tunnel all" mode have. Regards, Shinta On Wed, 5 Apr 2006 16:29:21 -0700 "Vijay Devarapalli" wrote: > Hello all, > > I want to add some more text to > draft-ietf-mip6-ikev2-ipsec to clarify the use > of "tunnel all" mode. a pre-06 version of the > draft is at > http://www.dvijay.com/ietf/internet-drafts/mip6/mip6_ikev2.txt > a diff from version 05 to 06 is at > http://www.dvijay.com/ietf/internet-drafts/mip6/diff-05to06.html > > the current status for this draft is "AD > Evaluation". it was felt that the changes are > significant enough to refer the changes to the > working group before making the changes. there > will be a short working group call later on > on these changes. > > the tunnel mode was already introduced with > the addition of the section on IPsec granularity > considerations in version 04. the new text is > only for better clarity. > > comments are welcome. > > Vijay > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 10 20:41:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT6ww-0005Lq-Cw; Mon, 10 Apr 2006 20:41:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT6wv-0005Ga-8J for mip6@ietf.org; Mon, 10 Apr 2006 20:41:41 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT6wt-0005U8-Rh for mip6@ietf.org; Mon, 10 Apr 2006 20:41:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Changes to draft-ietf-mip6-ikev2-ipsec Date: Mon, 10 Apr 2006 17:41:36 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Changes to draft-ietf-mip6-ikev2-ipsec Thread-Index: AcZb/6/RfElaiKrcT/aLfT3IXIMJLQA+x10g From: "Vijay Devarapalli" To: "Shinta Sugimoto" X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > I've parsed the diff from 05 to 06 and had some comments/questions. > In the "tunnel all" mode, do you assume that the IKEv2 takes the > role of updating the outer endpoint address of the IPsec tunnel > established between the MN and HA ? =20 it is still the binding update that updates the=20 outer address of the IPsec tunnel. when you=20 decapsulate the packet (or process the tunneled BU), you need to relax the check for the outer source address if the packet contains a BU that is updating the CoA. > I mean, in my view, BU message > meant to be the trigger for updating the endpoint address. In this > sense, it is actually convinient for the MN and HA to have transport > mode SA pair which is agnostic on MN's CoA. =20 true. it is harder for an implementation to=20 update the IPsec tunnel SA if the message that=20 is going to do the update is also coming=20 through the same tunnel. actually we had this=20 discussion just before Mobile IPv6 became an=20 RFC. I remember Tero Kivinen, Jari Arkko,=20 Santeri Paavolainen and myself discussing this.=20 I believe that discussion was one of the=20 triggers to form the MOBIKE WG. :)=20 > If we assume that all > mobility signals (including BU) are sent over the IPsec tunnel, > I believe MN and HA are required to run MOBIKE (or re-establish the > IPsec SA) prior to the home registration. =20 the goal is not to require MOBIKE. MOBIKE can be used if you want to. > So, I think the draft > should mention implications/side-effect that "tunnel all" mode have. sure. I will add some text.=20 Vijay >=20 >=20 > Regards, > Shinta >=20 > On Wed, 5 Apr 2006 16:29:21 -0700 > "Vijay Devarapalli" wrote: >=20 > > Hello all, > >=20 > > I want to add some more text to=20 > > draft-ietf-mip6-ikev2-ipsec to clarify the use > > of "tunnel all" mode. a pre-06 version of the > > draft is at > > http://www.dvijay.com/ietf/internet-drafts/mip6/mip6_ikev2.txt > > a diff from version 05 to 06 is at > > http://www.dvijay.com/ietf/internet-drafts/mip6/diff-05to06.html > >=20 > > the current status for this draft is "AD=20 > > Evaluation". it was felt that the changes are=20 > > significant enough to refer the changes to the > > working group before making the changes. there > > will be a short working group call later on > > on these changes. > >=20 > > the tunnel mode was already introduced with=20 > > the addition of the section on IPsec granularity=20 > > considerations in version 04. the new text is > > only for better clarity. > >=20 > > comments are welcome. > >=20 > > Vijay > >=20 > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 >=20 >=20 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 10 22:26:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT8ad-0001mf-SE; Mon, 10 Apr 2006 22:26:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT8ac-0001iM-5y for mip6@ietf.org; Mon, 10 Apr 2006 22:26:46 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT8aZ-0001zU-Nt for mip6@ietf.org; Mon, 10 Apr 2006 22:26:46 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3B2QfId025826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 10 Apr 2006 19:26:41 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3B2Qd2u021948; Mon, 10 Apr 2006 19:26:40 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Apr 2006 19:26:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mip6] Bootstrapping on the home link Date: Mon, 10 Apr 2006 19:26:38 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB84656D77@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Bootstrapping on the home link Thread-Index: AcZZr92C55IMm5nlRSKEAKDuchT/gwCCUpcAAE7oNyA= From: "Narayanan, Vidya" To: "Giaretta Gerardo" X-OriginalArrivalTime: 11 Apr 2006 02:26:39.0203 (UTC) FILETIME=[5CF41330:01C65D0F] X-Spam-Score: 0.1 (/) X-Scan-Signature: 23336e92cd9b2f166f17126afcdd84ec Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1606449770==" Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============1606449770== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65D0F.5CC7C970" This is a multi-part message in MIME format. ------_=_NextPart_001_01C65D0F.5CC7C970 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Gerardo, This is not an academic exercise. It is true that today, the home link is always virtual in 3gpp2 and other places. However, I am not sure that it should remain that way as networks evolve and that is the case under study.=20 =20 Having said that, I definitely do not want the IKEv2 SA establishment at handoff time - that latency must only be added to bootstrapping times. So, while I realize that there isn't a need for an IKEv2 and IPsec SA on the home link, I do want those to be established at bootstrapping time, regardless of whether the MN is on the home link or not.=20 =20 Also, I was not assuming that the MN knows its HA while powering up at home. Sure, that could be solved partially with the 'H' bit - although, it still doesn't solve the SA establishment part. This is more the case where the MN knows nothing at power up - acquires an IP address which it thinks is the CoA and then, when it gets an HA assigned, it happens to be "home". So, at the time of receiving an RA with the 'H' bit set, it has no idea that it is home - but, learns later after HA assignment (also, I'm not limiting HA assignment via DNS - the HA assignment may happen via other means, but that should be irrelevant to the problem under discussion).=20 =20 What should be the behavior there? I think this behavior should be captured.=20 =20 Thoughts?=20 Regards, Vidya ________________________________ From: Giaretta Gerardo [mailto:gerardo.giaretta@telecomitalia.it]=20 Sent: Sunday, April 09, 2006 2:57 AM To: Narayanan, Vidya Cc: mip6@ietf.org Subject: RE: [Mip6] Bootstrapping on the home link =09 =09 =20 Hi Vidya, =09 some comments on this, inline. One more general comment: this scenario seems not applicable to the split scenario document since the base assumption is that there is not relationship between access service and mobility service. It may be in the scope of the integrated scenario, as a local HA assignment case. =09 > All, > Currently, none of the bootstrapping documents seem to address the > scenario of bootstrapping of the MN on the home link. Here is the > scenario:=20 >=20 > MN powers up on the home link. It has no means of knowing it is on the > home link.=20 =09 We cannot say that the MN is on the home link or not until a HA assignment is performed. I think you are addressing the case of a HA in the same link of the MN and the MN tries to bootstrap with that HA. In this scenario, based on RFC3775, the HA sends RAs with H bit set and therefore the DNS discovery may not be performed, but this is already defined in rfc3775.=20 =09 > Hence, it configures an IP address that it thinks is a CoA > (say, statelessly). It then goes about doing IKEv2 and trying to get a > home address, at which point, it realizes that the home prefix is the > same as the prefix on which it just got an IP address. MN and HA > behavior in this scenario needs to be addressed.=20 >=20 =09 Ideally, the MN does not need any SA if it is still in the home link. The IPsec SA is needed only when the MN hands over to a foreign link.=20 I guess there are two options here: - the MN performs IKEv2 and establishes an IPsec SA even if it is in the home link. Note that this may be useless (since the MN may always remain in the home link) and this SA must not be used until the MN moves to another link - the MN does not perform IKev2 as soon as it stays in the home link. At the time of the first handover, it runs IKEv2. This has one drawback since it implies a higher handover latency for the first handover. Another issue to be considered is that the HoA assigned in IKEv2 exchange must be the same used before by the MN in the home link.=20 =09 > There are multiple ways in which this could work. I walked=20 > through a few > different options and here is one that I think would probably=20 > work best: >=20 >=20 > 1. MN configures CoA > 2. MN performs IKEv2 - HA realizes from the CoA that the MN is home =09 As mentioned, the MN itself should realize it is at home based on H bit set in the Router Advertisements. Moreover the MN technically does not need an IPsec SA while at home. =09 > 3. If the CoA is acceptable as HoA, HA returns the same address in the > CFG_REPLY.=20 =09 The possibility to ask for an explicit address is already present in the current specification. =09 > 4. If not, HA proposes a HoA in the INTERNAL_IP6_ADDRESS attribute of > the CFG_REPLY.=20 > 5. Either way, MN realizes it is home, based on prefix matching =09 If it is performing bootstrapping with a specific HA, it has already realized it is at home, IMO. =09 > 6. If the CoA was accepted as the HoA, MN uses that. If not,=20 > it gives up > the CoA and uses the HA proposed address as the HoA.=20 > 7. MN may send BU to de-register (so that other things like=20 > DNS updates, > etc. can happen and doesn't need to wait till handoff time).=20 >=20 > If this behavior is already discussed somewhere, please point=20 > me to it - > apologies in advance for not doing my homework in that case :) >=20 > If it is not described anywhere, thoughts on this?=20 >=20 =09 One more thought: there are no current deployments of MIP (3GPP2, WiMAX) where this scenario can occur. The home links are always virtual links. Are there real deployments where this may occur? Or are we mainly considering an academic issue? =09 Regards, --Gerardo =09 > Regards, > Vidya >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 =09 =09 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to webmaster@telecomitalia.it . Thank you www.telecomitalia.it =20 =09 -------------------------------------------------------------------- ------_=_NextPart_001_01C65D0F.5CC7C970 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Gerardo,
This is not an academic exercise. It is true = that today,=20 the home link is always virtual in 3gpp2 and other places. However, I am = not=20 sure that it should remain that way as networks evolve and that is the = case=20 under study.
 
Having said that, I definitely do not want the = IKEv2 SA=20 establishment at handoff time - that latency must only be added to = bootstrapping=20 times. So, while I realize that there isn't a need for an IKEv2 and = IPsec SA on=20 the home link, I do want those to be established at bootstrapping time,=20 regardless of whether the MN is on the home link or not. =
 
Also, I was not assuming that the MN knows its = HA while=20 powering up at home. Sure, that could be solved partially with the 'H' = bit -=20 although, it still doesn't solve the SA establishment part. This is more = the=20 case where the MN knows nothing at power up - acquires an IP address = which it=20 thinks is the CoA and then, when it gets an HA assigned, it happens to = be=20 "home". So, at the time of receiving an RA with the 'H' bit set, it has = no idea=20 that it is home - but, learns later after HA assignment (also, I'm not = limiting=20 HA assignment via DNS - the HA assignment may happen via other means, = but that=20 should be irrelevant to the problem under discussion). =
 
What should be the behavior there? I think this = behavior=20 should be captured.
 
Thoughts?

Regards,
Vidya

From: Giaretta Gerardo=20 [mailto:gerardo.giaretta@telecomitalia.it]
Sent: Sunday, = April 09,=20 2006 2:57 AM
To: Narayanan, Vidya
Cc:=20 mip6@ietf.org
Subject: RE: [Mip6] Bootstrapping on the home=20 link

 
Hi Vidya,

some comments on this, inline. One = more=20 general comment: this scenario
seems not applicable to the split = scenario=20 document since the base
assumption is that there is not = relationship=20 between access service and
mobility service. It may be in the scope = of the=20 integrated scenario, as
a local HA assignment case.

>=20 All,
> Currently, none of the bootstrapping documents seem to = address=20 the
> scenario of bootstrapping of the MN on the home link. Here = is=20 the
> scenario:
>
> MN powers up on the home link. = It has=20 no means of knowing it is on the
> home link.

We cannot = say that=20 the MN is on the home link or not until a HA
assignment is = performed. I=20 think you are addressing the case of a HA in
the same link of the = MN and=20 the MN tries to bootstrap with that HA. In
this scenario, based on = RFC3775,=20 the HA sends RAs with H bit set and
therefore the DNS discovery may = not be=20 performed, but this is already
defined in rfc3775.

> = Hence, it=20 configures an IP address that it thinks is a CoA
> (say, = statelessly).=20 It then goes about doing IKEv2 and trying to get a
> home = address, at=20 which point, it realizes that the home prefix is the
> same as = the=20 prefix on which it just got an IP address. MN and HA
> behavior = in this=20 scenario needs to be addressed.
>

Ideally, the MN does = not need=20 any SA if it is still in the home link.
The IPsec SA is needed only = when=20 the MN hands over to a foreign link.
I guess there are two options = here:
- the MN performs IKEv2 and establishes an IPsec SA even if = it is in=20 the
home link. Note that this may be useless (since the MN may = always=20 remain
in the home link) and this SA must not be used until the MN = moves=20 to
another link
- the MN does not perform IKev2 as soon as it = stays in=20 the home link. At
the time of the first handover, it runs IKEv2. = This has=20 one drawback
since it implies a higher handover latency for the = first=20 handover.
Another issue to be considered is that the HoA assigned = in=20 IKEv2
exchange must be the same used before by the MN in the home = link.=20

> There are multiple ways in which this could work. I = walked=20
> through a few
> different options and here is one that = I think=20 would probably
> work best:
>
>
> 1. MN = configures=20 CoA
> 2. MN performs IKEv2 - HA realizes from the CoA that the = MN is=20 home

As mentioned, the MN itself should realize it is at home = based on=20 H bit
set in the Router Advertisements. Moreover the MN technically = does=20 not
need an IPsec SA while at home.

> 3. If the CoA is = acceptable=20 as HoA, HA returns the same address in the
> CFG_REPLY. =

The=20 possibility to ask for an explicit address is already present in=20 the
current specification.

> 4. If not, HA proposes a HoA = in the=20 INTERNAL_IP6_ADDRESS attribute of
> the CFG_REPLY.
> 5. = Either=20 way, MN realizes it is home, based on prefix matching

If it is=20 performing bootstrapping with a specific HA, it has = already
realized it is=20 at home, IMO.

> 6. If the CoA was accepted as the HoA, MN = uses that.=20 If not,
> it gives up
> the CoA and uses the HA proposed = address=20 as the HoA.
> 7. MN may send BU to de-register (so that other = things=20 like
> DNS updates,
> etc. can happen and doesn't need to = wait=20 till handoff time).
>
> If this behavior is already = discussed=20 somewhere, please point
> me to it -
> apologies in = advance for=20 not doing my homework in that case :)
>
> If it is not = described=20 anywhere, thoughts on this?
>

One more thought: there = are no=20 current deployments of MIP (3GPP2, WiMAX)
where this scenario can = occur.=20 The home links are always virtual links.
Are there real deployments = where=20 this may occur? Or are we mainly
considering an academic=20 issue?

Regards,
--Gerardo

> Regards,
> = Vidya
>=20
> _______________________________________________
> Mip6 = mailing=20 list
> Mip6@ietf.org
>=20 https://www1.ietf.org/mailman/listinfo/mip6
>
--------------------------------------------------------------------=
CONFIDENTIALITY=20 NOTICE
This message and its attachments are addressed solely to the = persons
above and may contain confidential information. If you have = received
the message in error, be informed that any use of the = content=20 hereof
is prohibited. Please return it immediately to the sender = and=20 delete
the message. Should you have any questions, please contact = us=20 by
replying to webmaster@telecomitalia.it.
        = Thank=20 = you
           =             &= nbsp;           &n= bsp;   =20 www.telecomitalia.it
--------------------------------------------------------------------=
------_=_NextPart_001_01C65D0F.5CC7C970-- --===============1606449770== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1606449770==-- From mip6-bounces@ietf.org Tue Apr 11 01:49:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTBjk-0001NO-KK; Tue, 11 Apr 2006 01:48:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTBjj-0001NJ-BP for mip6@ietf.org; Tue, 11 Apr 2006 01:48:23 -0400 Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTBje-0000UT-3L for mip6@ietf.org; Tue, 11 Apr 2006 01:48:23 -0400 Received: from [193.234.219.165] (w165.nomadiclab.com [193.234.219.165]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 205A04D8D1; Tue, 11 Apr 2006 14:48:13 +0900 (JST) Date: Tue, 11 Apr 2006 08:48:06 +0300 From: Shinta Sugimoto To: "Vijay Devarapalli" Subject: Re: [Mip6] Changes to draft-ietf-mip6-ikev2-ipsec In-Reply-To: References: Message-Id: <20060411083202.6646.SHINTA@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.21.03 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org On Mon, 10 Apr 2006 17:41:36 -0700 "Vijay Devarapalli" wrote: > > I've parsed the diff from 05 to 06 and had some comments/questions. > > In the "tunnel all" mode, do you assume that the IKEv2 takes the > > role of updating the outer endpoint address of the IPsec tunnel > > established between the MN and HA ? > > it is still the binding update that updates the > outer address of the IPsec tunnel. when you > decapsulate the packet (or process the tunneled > BU), you need to relax the check for the outer > source address if the packet contains a BU that > is updating the CoA. Ok, I see. So there should be exceptional handling to check inner packet when outer source address verification fails. > > > I mean, in my view, BU message > > meant to be the trigger for updating the endpoint address. In this > > sense, it is actually convinient for the MN and HA to have transport > > mode SA pair which is agnostic on MN's CoA. > > true. it is harder for an implementation to > update the IPsec tunnel SA if the message that > is going to do the update is also coming > through the same tunnel. actually we had this > discussion just before Mobile IPv6 became an > RFC. I remember Tero Kivinen, Jari Arkko, > Santeri Paavolainen and myself discussing this. > I believe that discussion was one of the > triggers to form the MOBIKE WG. :) I see. > > If we assume that all > > mobility signals (including BU) are sent over the IPsec tunnel, > > I believe MN and HA are required to run MOBIKE (or re-establish the > > IPsec SA) prior to the home registration. > > the goal is not to require MOBIKE. MOBIKE can > be used if you want to. Ok. > > So, I think the draft > > should mention implications/side-effect that "tunnel all" mode have. > > sure. I will add some text. Thnaks. Shinta _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 11 19:25:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTSF4-0005At-Ks; Tue, 11 Apr 2006 19:25:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTSF0-00052G-Vv; Tue, 11 Apr 2006 19:25:46 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTSEz-0001If-KL; Tue, 11 Apr 2006 19:25:46 -0400 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k3BNPjXl023601; Tue, 11 Apr 2006 16:25:45 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k3BNPj3d023600; Tue, 11 Apr 2006 16:25:45 -0700 Date: Tue, 11 Apr 2006 16:25:45 -0700 Message-Id: <200604112325.k3BNPj3d023600@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: mip6@ietf.org, rfc-editor@rfc-editor.org Subject: [Mip6] RFC 4295 on Mobile IPv6 Management Information Base X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4295 Title: Mobile IPv6 Management Information Base Author: G. Keeni, K. Koide, K. Nagami, S. Gundavelli Status: Standards Track Date: April 2006 Mailbox: glenn@cysols.com, koide@shiratori.riec.tohoku.ac.jp, nagami@inetcore.com, sgundave@cisco.com Pages: 109 Characters: 209038 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mip6-mipv6-mib-07.txt URL: http://www.rfc-editor.org/rfc/rfc4295.txt This memo defines a portion of the Management Information Base (MIB), the Mobile-IPv6 MIB, for use with network management protocols in the Internet community. In particular, the Mobile-IPv6 MIB will be used to monitor and control the mobile node, home agent, and correspondent node functions of a Mobile IPv6 (MIPv6) entity. [STANDARDS TRACK] This document is a product of the Mobility for IPv6 Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 11 20:00:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTSmJ-0002Gc-NT; Tue, 11 Apr 2006 20:00:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTSmI-0002GW-P3 for mip6@ietf.org; Tue, 11 Apr 2006 20:00:10 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTSmH-0003BD-5o for mip6@ietf.org; Tue, 11 Apr 2006 20:00:10 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Changes to draft-ietf-mip6-ikev2-ipsec Date: Tue, 11 Apr 2006 17:00:03 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Changes to draft-ietf-mip6-ikev2-ipsec Thread-Index: AcZdK4hNaa3swAc0SwSCDuO+4bFcEwAl7whQ From: "Vijay Devarapalli" To: "Shinta Sugimoto" X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi, I added some text to section 5. the latest text is at=20 http://www.dvijay.com/ietf/internet-drafts/mip6/mip6_ikev2.txt and the diff at http://www.dvijay.com/ietf/internet-drafts/mip6/diff-05to06.html Vijay > -----Original Message----- > From: Shinta Sugimoto [mailto:shinta@sfc.wide.ad.jp]=20 > Sent: Monday, April 10, 2006 10:48 PM > To: Vijay Devarapalli > Cc: mip6@ietf.org > Subject: Re: [Mip6] Changes to draft-ietf-mip6-ikev2-ipsec >=20 > On Mon, 10 Apr 2006 17:41:36 -0700 > "Vijay Devarapalli" wrote: >=20 > > > I've parsed the diff from 05 to 06 and had some=20 > comments/questions. > > > In the "tunnel all" mode, do you assume that the IKEv2 takes the > > > role of updating the outer endpoint address of the IPsec tunnel > > > established between the MN and HA ? =20 > >=20 > > it is still the binding update that updates the=20 > > outer address of the IPsec tunnel. when you=20 > > decapsulate the packet (or process the tunneled > > BU), you need to relax the check for the outer > > source address if the packet contains a BU that > > is updating the CoA. >=20 > Ok, I see. So there should be exceptional handling to check inner > packet when outer source address verification fails. >=20 > >=20 > > > I mean, in my view, BU message > > > meant to be the trigger for updating the endpoint=20 > address. In this > > > sense, it is actually convinient for the MN and HA to=20 > have transport > > > mode SA pair which is agnostic on MN's CoA. =20 > >=20 > > true. it is harder for an implementation to=20 > > update the IPsec tunnel SA if the message that=20 > > is going to do the update is also coming=20 > > through the same tunnel. actually we had this=20 > > discussion just before Mobile IPv6 became an=20 > > RFC. I remember Tero Kivinen, Jari Arkko,=20 > > Santeri Paavolainen and myself discussing this.=20 > > I believe that discussion was one of the=20 > > triggers to form the MOBIKE WG. :)=20 >=20 > I see. >=20 > > > If we assume that all > > > mobility signals (including BU) are sent over the IPsec tunnel, > > > I believe MN and HA are required to run MOBIKE (or=20 > re-establish the > > > IPsec SA) prior to the home registration. =20 > >=20 > > the goal is not to require MOBIKE. MOBIKE can > > be used if you want to. >=20 > Ok. >=20 > > > So, I think the draft > > > should mention implications/side-effect that "tunnel all"=20 > mode have. > >=20 > > sure. I will add some text.=20 >=20 > Thnaks. >=20 >=20 > Shinta >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 11 21:04:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTTmV-0002ht-2T; Tue, 11 Apr 2006 21:04:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTTmU-0002ho-02 for mip6@ietf.org; Tue, 11 Apr 2006 21:04:26 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTTmT-0005uW-Ly for mip6@ietf.org; Tue, 11 Apr 2006 21:04:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Bootstrapping on the home link Date: Tue, 11 Apr 2006 18:04:22 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Bootstrapping on the home link Thread-Index: AcZZr92C55IMm5nlRSKEAKDuchT/gwEHKqUg From: "Vijay Devarapalli" To: "Narayanan, Vidya" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org >=20 > MN powers up on the home link. It has no means of knowing it is on the > home link. Hence, it configures an IP address that it thinks is a CoA > (say, statelessly). It then goes about doing IKEv2 and trying to get a > home address, at which point, it realizes that the home prefix is the > same as the prefix on which it just got an IP address.=20 before that the MN should get a router advertisement=20 from the HA with the H bit set and the 128 bit address of the HA in the prefix information option. if this address matches the HA's IP address the MN gets by DNS=20 lookup, then the MN realizes it is at home. Vijay MN and HA > behavior in this scenario needs to be addressed.=20 >=20 > There are multiple ways in which this could work. I walked=20 > through a few > different options and here is one that I think would probably=20 > work best: >=20 >=20 > 1. MN configures CoA > 2. MN performs IKEv2 - HA realizes from the CoA that the MN is home > 3. If the CoA is acceptable as HoA, HA returns the same address in the > CFG_REPLY.=20 > 4. If not, HA proposes a HoA in the INTERNAL_IP6_ADDRESS attribute of > the CFG_REPLY.=20 > 5. Either way, MN realizes it is home, based on prefix matching > 6. If the CoA was accepted as the HoA, MN uses that. If not,=20 > it gives up > the CoA and uses the HA proposed address as the HoA.=20 > 7. MN may send BU to de-register (so that other things like=20 > DNS updates, > etc. can happen and doesn't need to wait till handoff time).=20 >=20 > If this behavior is already discussed somewhere, please point=20 > me to it - > apologies in advance for not doing my homework in that case :) >=20 > If it is not described anywhere, thoughts on this?=20 >=20 > Regards, > Vidya >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 11 21:12:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTTu7-0005Rk-2w; Tue, 11 Apr 2006 21:12:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTTu5-0005RX-Q4 for mip6@ietf.org; Tue, 11 Apr 2006 21:12:17 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTTu5-0006Do-H1 for mip6@ietf.org; Tue, 11 Apr 2006 21:12:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Bootstrapping on the home link Date: Tue, 11 Apr 2006 18:12:15 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Bootstrapping on the home link Thread-Index: AcZZr92C55IMm5nlRSKEAKDuchT/gwCCUpcAAE7oNyAANhGGMA== From: "Vijay Devarapalli" To: "Narayanan, Vidya" , "Giaretta Gerardo" X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com]=20 > Having said that, I definitely do not want the IKEv2 SA=20 > establishment at handoff time - that latency must only be=20 > added to bootstrapping times. So, while I realize that there=20 > isn't a need for an IKEv2 and IPsec SA on the home link, I do=20 > want those to be established at bootstrapping time,=20 > regardless of whether the MN is on the home link or not.=20 well, when the MN is at home, it is supposed to be on its own. no help from the HA. > Also, I was not assuming that the MN knows its HA while=20 > powering up at home.=20 it is supposed to know the HA's FQDN. > Sure, that could be solved partially=20 > with the 'H' bit - although, it still doesn't solve the SA=20 > establishment part.=20 typically the IPsec SA setup is triggered by the MN=20 wanting to send a BU. if the MN does not send a BU=20 while at home, IPsec SA setup wont get triggered. one could still configure the mobile node to create an IPsec SA while at home. the IPsec SA is not tied to the existence of a binding cache entry at the home agent. but thats just configuration on the=20 mobile node. not a protocol issue. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 12 01:58:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTYMo-00011g-MM; Wed, 12 Apr 2006 01:58:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTYMn-00011b-L3 for mip6@ietf.org; Wed, 12 Apr 2006 01:58:13 -0400 Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTYMj-0007TJ-6s for mip6@ietf.org; Wed, 12 Apr 2006 01:58:13 -0400 Received: from [193.234.219.165] (w165.nomadiclab.com [193.234.219.165]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id D1A834D8F0; Wed, 12 Apr 2006 14:58:04 +0900 (JST) Date: Wed, 12 Apr 2006 08:57:56 +0300 From: Shinta Sugimoto To: "Vijay Devarapalli" Subject: Re: [Mip6] Changes to draft-ietf-mip6-ikev2-ipsec In-Reply-To: References: Message-Id: <20060412083507.6660.SHINTA@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.21.03 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org On Tue, 11 Apr 2006 17:00:03 -0700 "Vijay Devarapalli" wrote: > Hi, > > I added some text to section 5. the latest text > is at > http://www.dvijay.com/ietf/internet-drafts/mip6/mip6_ikev2.txt > and the diff at > http://www.dvijay.com/ietf/internet-drafts/mip6/diff-05to06.html > o The receipt of a Binding Update from the new care-of address > updates the tunnel end point of the IPsec SA as described in > Section 4.3. Since the Binding Update that updates the tunnel end > point is received through the same tunnel interface that needs to > be updated, special care should be taken on the home agent to > ensure that the Binding Update is not dropped. This can be > achieved by either performing the source address check on the > outer IPv6 header after the binding update is processed or have > exception handling to check the inner packet for a Binding Update > when the source address match on the outer source address fails. > Typical IPsec processing does not check the outer source address. Above text looks good to me. Thanks. Regards, Shinta _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 12 15:50:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTlMX-0007Cq-Nt; Wed, 12 Apr 2006 15:50:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTlLp-0005dx-Q5; Wed, 12 Apr 2006 15:50:05 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTlLp-0002Dc-Nv; Wed, 12 Apr 2006 15:50:05 -0400 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=oak.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FTlLm-0005i0-R5; Wed, 12 Apr 2006 15:50:05 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k3CJo2BX029553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Apr 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FTlLm-0002hT-DZ; Wed, 12 Apr 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 12 Apr 2006 15:50:02 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-ikev2-ipsec-06.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture Author(s) : F. Dupont, V. Devarapalli Filename : draft-ietf-mip6-ikev2-ipsec-06.txt Pages : 25 Date : 2006-4-12 This document describes Mobile IPv6 operation with the revised IPsec architecture and IKEv2. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-ikev2-ipsec-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip6-ikev2-ipsec-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip6-ikev2-ipsec-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-4-12145345.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-ikev2-ipsec-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-ikev2-ipsec-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-12145345.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Wed Apr 12 18:56:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FToG6-0002YV-TX; Wed, 12 Apr 2006 18:56:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FToG5-0002YH-3O for mip6@ietf.org; Wed, 12 Apr 2006 18:56:21 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FToG4-0003nx-O3 for mip6@ietf.org; Wed, 12 Apr 2006 18:56:21 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3CMtiYO018938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Apr 2006 15:55:45 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3CMtYWN007223; Wed, 12 Apr 2006 15:55:44 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Apr 2006 15:55:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Bootstrapping on the home link Date: Wed, 12 Apr 2006 15:55:35 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB846571D3@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Bootstrapping on the home link Thread-Index: AcZZr92C55IMm5nlRSKEAKDuchT/gwCCUpcAAE7oNyAANhGGMAAtTCJA From: "Narayanan, Vidya" To: "Vijay Devarapalli" , "Giaretta Gerardo" X-OriginalArrivalTime: 12 Apr 2006 22:55:43.0206 (UTC) FILETIME=[3A37B060:01C65E84] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Right, I understand that per RFC3775, the MN is supposed to be on its own when it is at home and hence doesn't need an IKEv2/IPsec SA. But, in the interest of reducing handoff latency, don't we want to recommend that the MN set up the SA even if it detected being at home? Actually, there are a few things to mention here:=20 1. The MN may first obtain an IP address and then discover it is home, after HA discovery/assignment.=20 2. If it wants to set up the IKEv2 SA, it must request the configured IP address to be its home address.=20 3. If the HA assigned a different HoA for whatever reason, the MN must use that and may release the address it configured earlier.=20 4. The IKEv2 SA in this case can be created with the HoA - hence, the address on that SA may not change when the MN hands off.=20 It would be good to capture these in the document.=20 Regards, Vidya > -----Original Message----- > From: Vijay Devarapalli [mailto:Vijay.Devarapalli@azairenet.com]=20 > Sent: Tuesday, April 11, 2006 6:12 PM > To: Narayanan, Vidya; Giaretta Gerardo > Cc: mip6@ietf.org > Subject: RE: [Mip6] Bootstrapping on the home link >=20 > > -----Original Message----- > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] >=20 > > Having said that, I definitely do not want the IKEv2 SA=20 > establishment=20 > > at handoff time - that latency must only be added to bootstrapping=20 > > times. So, while I realize that there isn't a need for an IKEv2 and=20 > > IPsec SA on the home link, I do want those to be established at=20 > > bootstrapping time, regardless of whether the MN is on the=20 > home link=20 > > or not. >=20 > well, when the MN is at home, it is supposed to be on its=20 > own. no help from the HA. >=20 > > Also, I was not assuming that the MN knows its HA while=20 > powering up at=20 > > home. >=20 > it is supposed to know the HA's FQDN. >=20 > > Sure, that could be solved partially > > with the 'H' bit - although, it still doesn't solve the SA=20 > > establishment part. >=20 > typically the IPsec SA setup is triggered by the MN wanting=20 > to send a BU. if the MN does not send a BU while at home,=20 > IPsec SA setup wont get triggered. >=20 > one could still configure the mobile node to create an IPsec=20 > SA while at home. the IPsec SA is not tied to the existence=20 > of a binding cache entry at the home agent. but thats just=20 > configuration on the mobile node. not a protocol issue. >=20 > Vijay >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 12 19:12:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FToVC-00066h-Dw; Wed, 12 Apr 2006 19:11:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FToVB-00066c-OI for mip6@ietf.org; Wed, 12 Apr 2006 19:11:57 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FToVB-0004LI-Dm for mip6@ietf.org; Wed, 12 Apr 2006 19:11:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Bootstrapping on the home link Date: Wed, 12 Apr 2006 16:11:56 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Bootstrapping on the home link Thread-Index: AcZZr92C55IMm5nlRSKEAKDuchT/gwCCUpcAAE7oNyAANhGGMAAtTCJAAAC5/jA= From: "Vijay Devarapalli" To: "Narayanan, Vidya" , "Giaretta Gerardo" X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > Right, I understand that per RFC3775, the MN is supposed to be on its > own when it is at home and hence doesn't need an IKEv2/IPsec=20 > SA. But, in > the interest of reducing handoff latency, don't we want to recommend > that the MN set up the SA even if it detected being at home?=20 its a configuration issue on the mobile node. it can setup an IPsec SA with the home agent if it wants to. since the IPsec SA is not tied to the existence of a binding cache entry, the HA wouldnt reject the MN's request to setup an IPsec SA. > Actually, > there are a few things to mention here:=20 >=20 > 1. The MN may first obtain an IP address and then discover it is home, > after HA discovery/assignment.=20 > > 2. If it wants to set up the IKEv2 SA, it must request the=20 > configured IP > address to be its home address.=20 > > 3. If the HA assigned a different HoA for whatever reason, the MN must > use that and may release the address it configured earlier.=20 > > 4. The IKEv2 SA in this case can be created with the HoA - hence, the > address on that SA may not change when the MN hands off.=20 >=20 > It would be good to capture these in the document.=20 this is standard behavior. in a typical IKEv2 implementation, the initiator can propose an=20 address in the INTERNAL_IP6_ADDRESS attribute.=20 the responder can honor that or propose a new=20 address. if there is a new address in the=20 config reply, the initiator starts using the new address. Vijay >=20 > Regards, > Vidya >=20 > > -----Original Message----- > > From: Vijay Devarapalli [mailto:Vijay.Devarapalli@azairenet.com]=20 > > Sent: Tuesday, April 11, 2006 6:12 PM > > To: Narayanan, Vidya; Giaretta Gerardo > > Cc: mip6@ietf.org > > Subject: RE: [Mip6] Bootstrapping on the home link > >=20 > > > -----Original Message----- > > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > >=20 > > > Having said that, I definitely do not want the IKEv2 SA=20 > > establishment=20 > > > at handoff time - that latency must only be added to=20 > bootstrapping=20 > > > times. So, while I realize that there isn't a need for an=20 > IKEv2 and=20 > > > IPsec SA on the home link, I do want those to be established at=20 > > > bootstrapping time, regardless of whether the MN is on the=20 > > home link=20 > > > or not. > >=20 > > well, when the MN is at home, it is supposed to be on its=20 > > own. no help from the HA. > >=20 > > > Also, I was not assuming that the MN knows its HA while=20 > > powering up at=20 > > > home. > >=20 > > it is supposed to know the HA's FQDN. > >=20 > > > Sure, that could be solved partially > > > with the 'H' bit - although, it still doesn't solve the SA=20 > > > establishment part. > >=20 > > typically the IPsec SA setup is triggered by the MN wanting=20 > > to send a BU. if the MN does not send a BU while at home,=20 > > IPsec SA setup wont get triggered. > >=20 > > one could still configure the mobile node to create an IPsec=20 > > SA while at home. the IPsec SA is not tied to the existence=20 > > of a binding cache entry at the home agent. but thats just=20 > > configuration on the mobile node. not a protocol issue. > >=20 > > Vijay > >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 12 19:36:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTot2-0002r0-I9; Wed, 12 Apr 2006 19:36:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTot1-0002qv-Mv for mip6@ietf.org; Wed, 12 Apr 2006 19:36:35 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTot0-0004zq-Vm for mip6@ietf.org; Wed, 12 Apr 2006 19:36:35 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3CNaFvb023109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Apr 2006 16:36:15 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3CNaEUC007971; Wed, 12 Apr 2006 16:36:14 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Apr 2006 16:36:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Bootstrapping on the home link Date: Wed, 12 Apr 2006 16:36:10 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB846571F6@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Bootstrapping on the home link Thread-Index: AcZZr92C55IMm5nlRSKEAKDuchT/gwCCUpcAAE7oNyAANhGGMAAtTCJAAAC5/jAAAHDkQA== From: "Narayanan, Vidya" To: "Vijay Devarapalli" , "Giaretta Gerardo" X-OriginalArrivalTime: 12 Apr 2006 23:36:14.0314 (UTC) FILETIME=[E34554A0:01C65E89] X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org >=20 > > Right, I understand that per RFC3775, the MN is supposed to=20 > be on its=20 > > own when it is at home and hence doesn't need an=20 > IKEv2/IPsec SA. But,=20 > > in the interest of reducing handoff latency, don't we want to=20 > > recommend that the MN set up the SA even if it detected=20 > being at home? >=20 > its a configuration issue on the mobile node. > it can setup an IPsec SA with the home agent if it wants to.=20 > since the IPsec SA is not tied to the existence of a binding=20 > cache entry, the HA wouldnt reject the MN's request to setup=20 > an IPsec SA. >=20 How is this just a configuration issue? This is about the MN triggering the set up of an IKEv2 and IPsec SA even when it knows it is home from a MIP6 perspective - are you saying that MIP6 implementations must allow configuration of this behavior? There is not clear guidance to implementors on what triggers the set up of IKEv2/IPsec SA at the MN with the HA - for one, it could be that the need for sending a BU is what does that, which would preclude setting up the SA while at home.=20 > > Actually, > > there are a few things to mention here:=20 > >=20 > > 1. The MN may first obtain an IP address and then discover=20 > it is home,=20 > > after HA discovery/assignment. > > > > 2. If it wants to set up the IKEv2 SA, it must request the=20 > configured=20 > > IP address to be its home address. > > > > 3. If the HA assigned a different HoA for whatever reason,=20 > the MN must=20 > > use that and may release the address it configured earlier. > > > > 4. The IKEv2 SA in this case can be created with the HoA -=20 > hence, the=20 > > address on that SA may not change when the MN hands off. > >=20 > > It would be good to capture these in the document.=20 >=20 > this is standard behavior. in a typical IKEv2 implementation,=20 > the initiator can propose an address in the=20 > INTERNAL_IP6_ADDRESS attribute.=20 > the responder can honor that or propose a new address. if=20 > there is a new address in the config reply, the initiator=20 > starts using the new address. >=20 I understand standard IKEv2 behavior. This is about a recommended behavior for the MN when it is home - an implementation may be implemented such that it *never* proposes an address in the INTERNAL_IP6_ADDRESS attribute - in this case, the MN benefits from requesting the configured address, due to the fact that it realized it is home.=20 Vidya > Vijay >=20 > >=20 > > Regards, > > Vidya > >=20 > > > -----Original Message----- > > > From: Vijay Devarapalli [mailto:Vijay.Devarapalli@azairenet.com] > > > Sent: Tuesday, April 11, 2006 6:12 PM > > > To: Narayanan, Vidya; Giaretta Gerardo > > > Cc: mip6@ietf.org > > > Subject: RE: [Mip6] Bootstrapping on the home link > > >=20 > > > > -----Original Message----- > > > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > >=20 > > > > Having said that, I definitely do not want the IKEv2 SA > > > establishment > > > > at handoff time - that latency must only be added to > > bootstrapping > > > > times. So, while I realize that there isn't a need for an > > IKEv2 and > > > > IPsec SA on the home link, I do want those to be established at=20 > > > > bootstrapping time, regardless of whether the MN is on the > > > home link > > > > or not. > > >=20 > > > well, when the MN is at home, it is supposed to be on its own. no=20 > > > help from the HA. > > >=20 > > > > Also, I was not assuming that the MN knows its HA while > > > powering up at > > > > home. > > >=20 > > > it is supposed to know the HA's FQDN. > > >=20 > > > > Sure, that could be solved partially with the 'H' bit -=20 > although,=20 > > > > it still doesn't solve the SA establishment part. > > >=20 > > > typically the IPsec SA setup is triggered by the MN=20 > wanting to send=20 > > > a BU. if the MN does not send a BU while at home, IPsec SA setup=20 > > > wont get triggered. > > >=20 > > > one could still configure the mobile node to create an IPsec SA=20 > > > while at home. the IPsec SA is not tied to the existence of a=20 > > > binding cache entry at the home agent. but thats just=20 > configuration=20 > > > on the mobile node. not a protocol issue. > > >=20 > > > Vijay > > >=20 > >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 12 20:41:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTpu6-000390-JA; Wed, 12 Apr 2006 20:41:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTpu5-000387-3z for mip6@ietf.org; Wed, 12 Apr 2006 20:41:45 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTpu2-00076N-Os for mip6@ietf.org; Wed, 12 Apr 2006 20:41:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Bootstrapping on the home link Date: Wed, 12 Apr 2006 17:41:43 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Bootstrapping on the home link Thread-Index: AcZZr92C55IMm5nlRSKEAKDuchT/gwCCUpcAAE7oNyAANhGGMAAtTCJAAAC5/jAAAHDkQAACvobw From: "Vijay Devarapalli" To: "Narayanan, Vidya" , "Giaretta Gerardo" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > > > Right, I understand that per RFC3775, the MN is supposed to=20 > > be on its=20 > > > own when it is at home and hence doesn't need an=20 > > IKEv2/IPsec SA. But,=20 > > > in the interest of reducing handoff latency, don't we want to=20 > > > recommend that the MN set up the SA even if it detected=20 > > being at home? > >=20 > > its a configuration issue on the mobile node. > > it can setup an IPsec SA with the home agent if it wants to.=20 > > since the IPsec SA is not tied to the existence of a binding=20 > > cache entry, the HA wouldnt reject the MN's request to setup=20 > > an IPsec SA. > >=20 >=20 > How is this just a configuration issue? This is about the MN=20 > triggering > the set up of an IKEv2 and IPsec SA even when it knows it is=20 > home from a > MIP6 perspective - are you saying that MIP6 implementations must allow > configuration of this behavior? There is not clear guidance to > implementors on what triggers the set up of IKEv2/IPsec SA at the MN > with the HA - for one, it could be that the need for sending a BU is > what does that, which would preclude setting up the SA while at home.=20 the mobile node as a regular IPv6 host can=20 setup any number of IPsec SAs it wants. it is=20 a matter of configuring the mobile node to=20 setup an IPsec SA for protecting protocol 135,=20 mh type 6 to the HA as soon as it boots up or=20 as soon as it configures a home agent. you can=20 do this for any protocol in your stack. > > > Actually, > > > there are a few things to mention here:=20 > > >=20 > > > 1. The MN may first obtain an IP address and then discover=20 > > it is home,=20 > > > after HA discovery/assignment. > > > > > > 2. If it wants to set up the IKEv2 SA, it must request the=20 > > configured=20 > > > IP address to be its home address. > > > > > > 3. If the HA assigned a different HoA for whatever reason,=20 > > the MN must=20 > > > use that and may release the address it configured earlier. > > > > > > 4. The IKEv2 SA in this case can be created with the HoA -=20 > > hence, the=20 > > > address on that SA may not change when the MN hands off. > > >=20 > > > It would be good to capture these in the document.=20 > >=20 > > this is standard behavior. in a typical IKEv2 implementation,=20 > > the initiator can propose an address in the=20 > > INTERNAL_IP6_ADDRESS attribute.=20 > > the responder can honor that or propose a new address. if=20 > > there is a new address in the config reply, the initiator=20 > > starts using the new address. > >=20 >=20 > I understand standard IKEv2 behavior. This is about a recommended > behavior for the MN when it is home - an implementation may be > implemented such that it *never* proposes an address in the > INTERNAL_IP6_ADDRESS attribute - in this case, the MN benefits from > requesting the configured address, due to the fact that it realized it > is home.=20 that would be an implementation limitation. any IKEv2 implementation should be have this=20 configurable on the initiator. the initiator can=20 either a propose an address or request an address. there is nothing to recommend. it is one of the things that should be left configurable. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Apr 13 15:15:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU7Hj-0001QT-7R; Thu, 13 Apr 2006 15:15:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU7Hh-0001QL-M4 for mip6@ietf.org; Thu, 13 Apr 2006 15:15:17 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU7Hh-0007pC-1N for mip6@ietf.org; Thu, 13 Apr 2006 15:15:17 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3DJFDBt012520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 13 Apr 2006 12:15:14 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3DJF1kb001132; Thu, 13 Apr 2006 12:15:12 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Apr 2006 12:15:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Bootstrapping on the home link Date: Thu, 13 Apr 2006 12:13:49 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB8465735A@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Bootstrapping on the home link Thread-Index: AcZZr92C55IMm5nlRSKEAKDuchT/gwCCUpcAAE7oNyAANhGGMAAtTCJAAAC5/jAAAHDkQAACvobwACQrqnA= From: "Narayanan, Vidya" To: "Vijay Devarapalli" , "Giaretta Gerardo" X-OriginalArrivalTime: 13 Apr 2006 19:15:08.0644 (UTC) FILETIME=[94378A40:01C65F2E] X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Vijay, The bootstrapping documents specify some MUSTs for MIP6 bootstrapping and also specify recommended behavior of DNS or IKEv2 as applicable for MIP6. If we go by the same argument that we can "configure the MN to set up an SA as soon as it gets an HA assigned", then, there are other parts of the document that should receive similar treatment. For instance, going by your argument, what value does the following statements in section 9.5 of draft-ietf-mip6-bootstrapping-split add -=20 "A security association is required even if the DNS server is in the same administrative domain as the Home Agent. The security association SHOULD be separate from the security associations used for other purposes, such as AAA." One can claim that HA can be configured to say that the SA with the DNS server is a separate one. But, the statement is there because we believe it is good recommended behavior and hence, should really be part of the implementation and not a configuration.=20 Please see some specific comments inline below.=20 >=20 > > > > Right, I understand that per RFC3775, the MN is supposed to > > > be on its > > > > own when it is at home and hence doesn't need an > > > IKEv2/IPsec SA. But, > > > > in the interest of reducing handoff latency, don't we want to=20 > > > > recommend that the MN set up the SA even if it detected > > > being at home? > > >=20 > > > its a configuration issue on the mobile node. > > > it can setup an IPsec SA with the home agent if it wants to.=20 > > > since the IPsec SA is not tied to the existence of a=20 > binding cache=20 > > > entry, the HA wouldnt reject the MN's request to setup an=20 > IPsec SA. > > >=20 > >=20 > > How is this just a configuration issue? This is about the MN=20 > > triggering the set up of an IKEv2 and IPsec SA even when it=20 > knows it=20 > > is home from a > > MIP6 perspective - are you saying that MIP6 implementations=20 > must allow=20 > > configuration of this behavior? There is not clear guidance to=20 > > implementors on what triggers the set up of IKEv2/IPsec SA=20 > at the MN=20 > > with the HA - for one, it could be that the need for=20 > sending a BU is=20 > > what does that, which would preclude setting up the SA=20 > while at home. >=20 > the mobile node as a regular IPv6 host can setup any number=20 > of IPsec SAs it wants. it is a matter of configuring the=20 > mobile node to setup an IPsec SA for protecting protocol 135,=20 > mh type 6 to the HA as soon as it boots up or as soon as it=20 > configures a home agent. you can do this for any protocol in=20 > your stack. >=20 As for configuring the MN to set up an IKEv2 SA for protocol 135 upon HA assignment, it makes a lot more sense to me that a MIP6 implementation should trigger the IKEv2 SA set up upon HA assignment, without a need for this being a configuration.=20 > > > > Actually, > > > > there are a few things to mention here:=20 > > > >=20 > > > > 1. The MN may first obtain an IP address and then discover > > > it is home, > > > > after HA discovery/assignment. > > > > > > > > 2. If it wants to set up the IKEv2 SA, it must request the > > > configured > > > > IP address to be its home address. > > > > > > > > 3. If the HA assigned a different HoA for whatever reason, > > > the MN must > > > > use that and may release the address it configured earlier. > > > > > > > > 4. The IKEv2 SA in this case can be created with the HoA - > > > hence, the > > > > address on that SA may not change when the MN hands off. > > > >=20 > > > > It would be good to capture these in the document.=20 > > >=20 > > > this is standard behavior. in a typical IKEv2 implementation, the=20 > > > initiator can propose an address in the INTERNAL_IP6_ADDRESS=20 > > > attribute. > > > the responder can honor that or propose a new address. if=20 > there is a=20 > > > new address in the config reply, the initiator starts=20 > using the new=20 > > > address. > > >=20 > >=20 > > I understand standard IKEv2 behavior. This is about a recommended=20 > > behavior for the MN when it is home - an implementation may be=20 > > implemented such that it *never* proposes an address in the=20 > > INTERNAL_IP6_ADDRESS attribute - in this case, the MN benefits from=20 > > requesting the configured address, due to the fact that it=20 > realized it=20 > > is home. >=20 > that would be an implementation limitation. any > IKEv2 implementation should be have this configurable on the=20 > initiator. the initiator can either a propose an address or=20 > request an address. > there is nothing to recommend. it is one of the things that=20 > should be left configurable. >=20 This is not a blanket configuration. In this case, the MN would request an IP address in the attribute when it is on the home link, but not while bootstrapping on a visited link, for instance.=20 Vidya > Vijay >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Apr 13 15:24:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU7R4-0003Bs-EZ; Thu, 13 Apr 2006 15:24:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU7R3-0003Bn-0u for mip6@ietf.org; Thu, 13 Apr 2006 15:24:57 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU7R2-000876-HG for mip6@ietf.org; Thu, 13 Apr 2006 15:24:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Bootstrapping on the home link Date: Thu, 13 Apr 2006 12:24:53 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Bootstrapping on the home link Thread-Index: AcZZr92C55IMm5nlRSKEAKDuchT/gwCCUpcAAE7oNyAANhGGMAAtTCJAAAC5/jAAAHDkQAACvobwACQrqnAAAxzQgA== From: "Vijay Devarapalli" To: "Narayanan, Vidya" , "Giaretta Gerardo" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org =20 > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com]=20 > Sent: Thursday, April 13, 2006 12:14 PM > To: Vijay Devarapalli; Giaretta Gerardo > Cc: mip6@ietf.org > Subject: RE: [Mip6] Bootstrapping on the home link >=20 > Vijay, > The bootstrapping documents specify some MUSTs for MIP6 bootstrapping > and also specify recommended behavior of DNS or IKEv2 as=20 > applicable for > MIP6. If we go by the same argument that we can "configure=20 > the MN to set > up an SA as soon as it gets an HA assigned", then, there are=20 > other parts > of the document that should receive similar treatment. For instance, > going by your argument, what value does the following statements in > section 9.5 of draft-ietf-mip6-bootstrapping-split add -=20 >=20 > "A security association is required even if the DNS server is in the > same administrative domain as the Home Agent. The security association > SHOULD be separate from the security associations used for other > purposes, such as AAA." >=20 > One can claim that HA can be configured to say that the SA=20 > with the DNS > server is a separate one. But, the statement is there because=20 > we believe > it is good recommended behavior and hence, should really be=20 > part of the > implementation and not a configuration.=20 in this case a MUST is required because it would be a bad idea for the HA to perform a DNS update without authenticating itself to the DNS server. otherwise any malicious node in the home network=20 or a mobile node through the tunnel to its HA can=20 send a DNS update on behalf of another mobile node. therefore the 'MUST' is required for securing the DNS update between the HA and the DNS server. it is not a configuration issue on the HA in this=20 case. >=20 > Please see some specific comments inline below.=20 >=20 > >=20 > > > > > Right, I understand that per RFC3775, the MN is supposed to > > > > be on its > > > > > own when it is at home and hence doesn't need an > > > > IKEv2/IPsec SA. But, > > > > > in the interest of reducing handoff latency, don't we want to=20 > > > > > recommend that the MN set up the SA even if it detected > > > > being at home? > > > >=20 > > > > its a configuration issue on the mobile node. > > > > it can setup an IPsec SA with the home agent if it wants to.=20 > > > > since the IPsec SA is not tied to the existence of a=20 > > binding cache=20 > > > > entry, the HA wouldnt reject the MN's request to setup an=20 > > IPsec SA. > > > >=20 > > >=20 > > > How is this just a configuration issue? This is about the MN=20 > > > triggering the set up of an IKEv2 and IPsec SA even when it=20 > > knows it=20 > > > is home from a > > > MIP6 perspective - are you saying that MIP6 implementations=20 > > must allow=20 > > > configuration of this behavior? There is not clear guidance to=20 > > > implementors on what triggers the set up of IKEv2/IPsec SA=20 > > at the MN=20 > > > with the HA - for one, it could be that the need for=20 > > sending a BU is=20 > > > what does that, which would preclude setting up the SA=20 > > while at home. > >=20 > > the mobile node as a regular IPv6 host can setup any number=20 > > of IPsec SAs it wants. it is a matter of configuring the=20 > > mobile node to setup an IPsec SA for protecting protocol 135,=20 > > mh type 6 to the HA as soon as it boots up or as soon as it=20 > > configures a home agent. you can do this for any protocol in=20 > > your stack. > >=20 >=20 > As for configuring the MN to set up an IKEv2 SA for protocol=20 > 135 upon HA > assignment, it makes a lot more sense to me that a MIP6 implementation > should trigger the IKEv2 SA set up upon HA assignment, without a need > for this being a configuration.=20 why? it could just be a security policy which=20 triggers this.=20 >=20 > > > > > Actually, > > > > > there are a few things to mention here:=20 > > > > >=20 > > > > > 1. The MN may first obtain an IP address and then discover > > > > it is home, > > > > > after HA discovery/assignment. > > > > > > > > > > 2. If it wants to set up the IKEv2 SA, it must request the > > > > configured > > > > > IP address to be its home address. > > > > > > > > > > 3. If the HA assigned a different HoA for whatever reason, > > > > the MN must > > > > > use that and may release the address it configured earlier. > > > > > > > > > > 4. The IKEv2 SA in this case can be created with the HoA - > > > > hence, the > > > > > address on that SA may not change when the MN hands off. > > > > >=20 > > > > > It would be good to capture these in the document.=20 > > > >=20 > > > > this is standard behavior. in a typical IKEv2=20 > implementation, the=20 > > > > initiator can propose an address in the INTERNAL_IP6_ADDRESS=20 > > > > attribute. > > > > the responder can honor that or propose a new address. if=20 > > there is a=20 > > > > new address in the config reply, the initiator starts=20 > > using the new=20 > > > > address. > > > >=20 > > >=20 > > > I understand standard IKEv2 behavior. This is about a recommended=20 > > > behavior for the MN when it is home - an implementation may be=20 > > > implemented such that it *never* proposes an address in the=20 > > > INTERNAL_IP6_ADDRESS attribute - in this case, the MN=20 > benefits from=20 > > > requesting the configured address, due to the fact that it=20 > > realized it=20 > > > is home. > >=20 > > that would be an implementation limitation. any > > IKEv2 implementation should be have this configurable on the=20 > > initiator. the initiator can either a propose an address or=20 > > request an address. > > there is nothing to recommend. it is one of the things that=20 > > should be left configurable. > >=20 >=20 > This is not a blanket configuration. In this case, the MN=20 > would request > an IP address in the attribute when it is on the home link, but not > while bootstrapping on a visited link, for instance.=20 if you want to do this, just configure your MN=20 to always request an IP address when it is on=20 the home link but not while it is bootstrapping=20 from a visited link. or the other way around. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Apr 13 17:55:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU9ls-0008C5-1Q; Thu, 13 Apr 2006 17:54:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU9lq-0008AN-Cr for mip6@ietf.org; Thu, 13 Apr 2006 17:54:34 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU9ln-00054f-IA for mip6@ietf.org; Thu, 13 Apr 2006 17:54:32 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3DLsS2f007446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 13 Apr 2006 14:54:28 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3DLsRBo026791; Thu, 13 Apr 2006 14:54:27 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Apr 2006 14:54:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Bootstrapping on the home link Date: Thu, 13 Apr 2006 14:54:15 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB846573E1@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Bootstrapping on the home link Thread-Index: AcZZr92C55IMm5nlRSKEAKDuchT/gwCCUpcAAE7oNyAANhGGMAAtTCJAAAC5/jAAAHDkQAACvobwACQrqnAAAxzQgAAE2TaA From: "Narayanan, Vidya" To: "Vijay Devarapalli" , "Giaretta Gerardo" X-OriginalArrivalTime: 13 Apr 2006 21:54:26.0924 (UTC) FILETIME=[D56552C0:01C65F44] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org This discussion seems to be missing the point - nevertheless, some points below. > >=20 > > Vijay, > > The bootstrapping documents specify some MUSTs for MIP6=20 > bootstrapping=20 > > and also specify recommended behavior of DNS or IKEv2 as applicable=20 > > for MIP6. If we go by the same argument that we can=20 > "configure the MN=20 > > to set up an SA as soon as it gets an HA assigned", then, there are=20 > > other parts of the document that should receive similar=20 > treatment. For=20 > > instance, going by your argument, what value does the following=20 > > statements in section 9.5 of=20 > draft-ietf-mip6-bootstrapping-split add - > >=20 > > "A security association is required even if the DNS server=20 > is in the=20 > > same administrative domain as the Home Agent. The security=20 > association=20 > > SHOULD be separate from the security associations used for other=20 > > purposes, such as AAA." > >=20 > > One can claim that HA can be configured to say that the SA with the=20 > > DNS server is a separate one. But, the statement is there=20 > because we=20 > > believe it is good recommended behavior and hence, should really be=20 > > part of the implementation and not a configuration. >=20 > in this case a MUST is required because it would be a bad=20 > idea for the HA to perform a DNS update without=20 > authenticating itself to the DNS server. > otherwise any malicious node in the home network or a mobile=20 > node through the tunnel to its HA can send a DNS update on=20 > behalf of another mobile node. > therefore the 'MUST' is required for securing the DNS update=20 > between the HA and the DNS server. it is not a configuration=20 > issue on the HA in this case. >=20 I wasn't referring to the fact that an SA is needed (not at all questioning the "MUST have an SA" part). I'm referring to the fact that the draft talks about the fact that the SA *SHOULD* be a *separate* one for DNS. And, this was *one* example I pulled up from the draft - if I didn't consider the exercise a waste of time, I could pull up other text in the document (and other MIP6 documents) along the same lines.=20 > >=20 > > Please see some specific comments inline below.=20 > >=20 > > >=20 > > > > > > Right, I understand that per RFC3775, the MN is supposed to > > > > > be on its > > > > > > own when it is at home and hence doesn't need an > > > > > IKEv2/IPsec SA. But, > > > > > > in the interest of reducing handoff latency, don't=20 > we want to=20 > > > > > > recommend that the MN set up the SA even if it detected > > > > > being at home? > > > > >=20 > > > > > its a configuration issue on the mobile node. > > > > > it can setup an IPsec SA with the home agent if it wants to.=20 > > > > > since the IPsec SA is not tied to the existence of a=20 > > > binding cache=20 > > > > > entry, the HA wouldnt reject the MN's request to setup an=20 > > > IPsec SA. > > > > >=20 > > > >=20 > > > > How is this just a configuration issue? This is about the MN=20 > > > > triggering the set up of an IKEv2 and IPsec SA even when it=20 > > > knows it=20 > > > > is home from a > > > > MIP6 perspective - are you saying that MIP6 implementations=20 > > > must allow=20 > > > > configuration of this behavior? There is not clear guidance to=20 > > > > implementors on what triggers the set up of IKEv2/IPsec SA=20 > > > at the MN=20 > > > > with the HA - for one, it could be that the need for=20 > > > sending a BU is=20 > > > > what does that, which would preclude setting up the SA=20 > > > while at home. > > >=20 > > > the mobile node as a regular IPv6 host can setup any number=20 > > > of IPsec SAs it wants. it is a matter of configuring the=20 > > > mobile node to setup an IPsec SA for protecting protocol 135,=20 > > > mh type 6 to the HA as soon as it boots up or as soon as it=20 > > > configures a home agent. you can do this for any protocol in=20 > > > your stack. > > >=20 > >=20 > > As for configuring the MN to set up an IKEv2 SA for protocol=20 > > 135 upon HA > > assignment, it makes a lot more sense to me that a MIP6=20 > implementation > > should trigger the IKEv2 SA set up upon HA assignment,=20 > without a need > > for this being a configuration.=20 >=20 > why? it could just be a security policy which=20 > triggers this.=20 >=20 Why is this a security policy? If hosts actually supported such configuration granularity, it would be a nightmare for admins.=20 > >=20 > > > > > > Actually, > > > > > > there are a few things to mention here:=20 > > > > > >=20 > > > > > > 1. The MN may first obtain an IP address and then discover > > > > > it is home, > > > > > > after HA discovery/assignment. > > > > > > > > > > > > 2. If it wants to set up the IKEv2 SA, it must request the > > > > > configured > > > > > > IP address to be its home address. > > > > > > > > > > > > 3. If the HA assigned a different HoA for whatever reason, > > > > > the MN must > > > > > > use that and may release the address it configured earlier. > > > > > > > > > > > > 4. The IKEv2 SA in this case can be created with the HoA - > > > > > hence, the > > > > > > address on that SA may not change when the MN hands off. > > > > > >=20 > > > > > > It would be good to capture these in the document.=20 > > > > >=20 > > > > > this is standard behavior. in a typical IKEv2=20 > > implementation, the=20 > > > > > initiator can propose an address in the INTERNAL_IP6_ADDRESS=20 > > > > > attribute. > > > > > the responder can honor that or propose a new address. if=20 > > > there is a=20 > > > > > new address in the config reply, the initiator starts=20 > > > using the new=20 > > > > > address. > > > > >=20 > > > >=20 > > > > I understand standard IKEv2 behavior. This is about a=20 > recommended=20 > > > > behavior for the MN when it is home - an implementation may be=20 > > > > implemented such that it *never* proposes an address in the=20 > > > > INTERNAL_IP6_ADDRESS attribute - in this case, the MN=20 > > benefits from=20 > > > > requesting the configured address, due to the fact that it=20 > > > realized it=20 > > > > is home. > > >=20 > > > that would be an implementation limitation. any > > > IKEv2 implementation should be have this configurable on the=20 > > > initiator. the initiator can either a propose an address or=20 > > > request an address. > > > there is nothing to recommend. it is one of the things that=20 > > > should be left configurable. > > >=20 > >=20 > > This is not a blanket configuration. In this case, the MN=20 > > would request > > an IP address in the attribute when it is on the home link, but not > > while bootstrapping on a visited link, for instance.=20 >=20 > if you want to do this, just configure your MN=20 > to always request an IP address when it is on=20 > the home link but not while it is bootstrapping=20 > from a visited link. or the other way around. >=20 I don't understand your motivation for saying this, when we specify such behavior in many other places in many other documents. We need to try and avoid a configuration mess for implementors and admins where we can. And, of course, it doesn't seem like you are consistent with this philosophy either, so, that doesn't allow us to make much progress.=20 Vidya _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 14 11:40:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUQPS-0002fj-CA; Fri, 14 Apr 2006 11:40:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUQPR-0002Vx-La for mip6@ietf.org; Fri, 14 Apr 2006 11:40:33 -0400 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUQPO-0005bi-A7 for mip6@ietf.org; Fri, 14 Apr 2006 11:40:31 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.10.03) with ESMTP id k3EFeQfw013193; Fri, 14 Apr 2006 17:40:26 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [192.44.77.29]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.09.01) with ESMTP id k3EFeMWT013181; Fri, 14 Apr 2006 17:40:22 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id k3EFeLCJ050283; Fri, 14 Apr 2006 17:40:21 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200604141540.k3EFeLCJ050283@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Vijay Devarapalli" Subject: Re: [Mip6] Changes to draft-ietf-mip6-ikev2-ipsec In-reply-to: Your message of Wed, 05 Apr 2006 16:29:21 PDT. Date: Fri, 14 Apr 2006 17:40:21 +0200 X-Virus-Scanned: amavisd-new at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org I have three comments (in next messages) about: - whether the "tunnel all" mode needs a requirement keyword and which one - compatibility issue with existing (not really new nor fully bound to the "tunnel all" mode) - consequences for IPsec/IKE. Thanks Francis.Dupont@point6.net _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Apr 16 20:46:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVHrd-0006Pr-9g; Sun, 16 Apr 2006 20:45:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVHrc-0006NU-Kl for mip6@ietf.org; Sun, 16 Apr 2006 20:45:12 -0400 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVHrb-0007Hn-9y for mip6@ietf.org; Sun, 16 Apr 2006 20:45:12 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1FVHrT-000106-8D; Mon, 17 Apr 2006 02:45:05 +0200 Received: from [192.168.2.100] (p54A36D02.dip.t-dialin.net [84.163.109.2]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 19525853F; Mon, 17 Apr 2006 02:45:02 +0200 (CEST) Message-ID: <4442E50D.4010703@tm.uka.de> Date: Mon, 17 Apr 2006 02:45:01 +0200 From: Christian Vogt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.5) Gecko/20041206 Thunderbird/1.0 Mnenhy/0.7.3.0 X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Mip6 X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.5 (--) X-Spam-Status: No X-Spam-Report: -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.1 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Subject: [Mip6] Blocking Authentication Data After De-Registration X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi everybody. Section 9.5.3 of RFC 3775 specifies that, when a MN de-registers with a CN, the CN must block the combination of HoA, CoA, seqno, and nonce indices as it was used for the creation of the existing BC entry. The blocked combination must be kept for at least the smaller of the remaining lifetimes of the associated nonces. The purpose of this rule is to prevent replay of an intercepted Binding Update message after sequence-number state is lost due to the MN's de-registration. An issue with this rule is that a CN generally does not only keep a single valid nonce, but a small number of valid nonces. An attacker may hence intercept a Binding Update message that was authenticated with nonce A, while the CN would block a combination including nonce B. This attacker could replay the intercepted Binding Update message. Furthermore, a MN may end up authenticating multiple Binding Update messages with different sequence numbers, but with the same nonce B. An attacker could then intercept a Binding Update message with sequence number X, while the CN would block a combination including sequence number X+n. Again, the attacker could replay the intercepted Binding Update message. A solution to this problem would be for the CN to keep *every* combination of HoA, CoA, seqno, and nonce index for *each* nonce that is currently valid. The CN could then block each such combination for a while when the MN de-registers. Kind regards, - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 17 16:43:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVaZQ-0006nd-3m; Mon, 17 Apr 2006 16:43:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVaZO-0006nY-MP for mip6@ietf.org; Mon, 17 Apr 2006 16:43:38 -0400 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVaZN-00048J-9Z for mip6@ietf.org; Mon, 17 Apr 2006 16:43:38 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.10.03) with ESMTP id k3HKhSCs007035; Mon, 17 Apr 2006 22:43:28 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [192.44.77.29]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.09.01) with ESMTP id k3HKhMk7007027; Mon, 17 Apr 2006 22:43:22 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id k3HKhMF4071076; Mon, 17 Apr 2006 22:43:22 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200604172043.k3HKhMF4071076@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Vijay Devarapalli" Subject: Re: [Mip6] Changes to draft-ietf-mip6-ikev2-ipsec (Req) In-reply-to: Your message of Wed, 05 Apr 2006 16:29:21 PDT. Date: Mon, 17 Apr 2006 22:43:22 +0200 X-Virus-Scanned: amavisd-new at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org The "tunnel all" mode was "MUST NOT", now we can make it optional ("MAY"), recommended ("SHOULD") or mandatory ("MUST"): - the reason of the "MUST NOT" was compatibility with the standard mode (but look at the next message). - "MAY" is the simplest, it only adds a new option - "SHOULD" can be argued because it is more in the line of the "all" idea and avoids to give a choice (i.e., to become incompatible) - "MUST" IMHO is too early because it makes some current implementations both incompatible and not compliant. Note that the current wording could be interpreted as an implicit MAY? Regards Francis.Dupont@point6.net _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 17 16:53:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVaia-0007gR-UE; Mon, 17 Apr 2006 16:53:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVaiZ-0007fw-Ig for mip6@ietf.org; Mon, 17 Apr 2006 16:53:07 -0400 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVaiZ-0004eL-7a for mip6@ietf.org; Mon, 17 Apr 2006 16:53:07 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.10.03) with ESMTP id k3HKr4b9007443; Mon, 17 Apr 2006 22:53:04 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [192.44.77.29]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.09.01) with ESMTP id k3HKqweP007430; Mon, 17 Apr 2006 22:52:58 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id k3HKqvFn071112; Mon, 17 Apr 2006 22:52:57 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200604172052.k3HKqvFn071112@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Vijay Devarapalli" Subject: Re: [Mip6] Changes to draft-ietf-mip6-ikev2-ipsec (Comp) In-reply-to: Your message of Wed, 05 Apr 2006 16:29:21 PDT. Date: Mon, 17 Apr 2006 22:52:57 +0200 X-Virus-Scanned: amavisd-new at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org The second point is compatibility with current implementations: the "tunnel all" mode is clearly not compatible as it introduces a new choice. But in fact the current (previous soon :-) specs don't enforce full compatibility because the SA pairs for BU/BA and for MPS/MPA protections can be shared or not. So if we consider the "tunnel all" mode as a super sharing option, it is just a third case... Regards Francis.Dupont@point6.net _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 17 17:06:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVavn-0005r4-Ew; Mon, 17 Apr 2006 17:06:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVavm-0005qz-5L for mip6@ietf.org; Mon, 17 Apr 2006 17:06:46 -0400 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVavk-0005HM-OD for mip6@ietf.org; Mon, 17 Apr 2006 17:06:46 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.10.03) with ESMTP id k3HL6e8E008344; Mon, 17 Apr 2006 23:06:40 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [192.44.77.29]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.09.01) with ESMTP id k3HL6ctn008331; Mon, 17 Apr 2006 23:06:38 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id k3HL6bwi071148; Mon, 17 Apr 2006 23:06:37 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200604172106.k3HL6bwi071148@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Vijay Devarapalli" Subject: Re: [Mip6] Changes to draft-ietf-mip6-ikev2-ipsec (IPsec) In-reply-to: Your message of Wed, 05 Apr 2006 16:29:21 PDT. Date: Mon, 17 Apr 2006 23:06:37 +0200 X-Virus-Scanned: amavisd-new at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org The "tunnel all" mode has some impacts on IPsec: - there is no more transport mode SAs: the IPsec config is far simpler. - all packets between the MN and the HA are through the tunnel: there are no difference (at the exception of the MIPv6 signaling for mobility control) with a mobile IPsec VPN with the MN in the client role and the HA in the Security Gateway role. - the K flag (again) is very useful: the MIPv6 signaling updates the SPD and the SAD but can't directly update the IKE internal state (this is the role of the K flag stuff). - actions at home are not very clearly defined: one can delete the tunnel as usual or keep it in order to make the home position not so special (cf monami6 stuff for development of this kind of ideas), Regards Francis.Dupont@point6.net _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 17 18:20:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVc4d-0004JJ-Sb; Mon, 17 Apr 2006 18:19:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVc4c-0004JD-1G for mip6@ietf.org; Mon, 17 Apr 2006 18:19:58 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVc4a-0000bW-O7 for mip6@ietf.org; Mon, 17 Apr 2006 18:19:58 -0400 Received: from [10.1.201.19] ([10.1.201.19]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Apr 2006 15:19:55 -0700 Message-ID: <44441486.8050905@azairenet.com> Date: Mon, 17 Apr 2006 15:19:50 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Francis Dupont Subject: Re: [Mip6] Changes to draft-ietf-mip6-ikev2-ipsec (Req) References: <200604172043.k3HKhMF4071076@givry.rennes.enst-bretagne.fr> In-Reply-To: <200604172043.k3HKhMF4071076@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Apr 2006 22:19:55.0424 (UTC) FILETIME=[0E1AEA00:01C6626D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Francis Dupont wrote: > The "tunnel all" mode was "MUST NOT", now we can make it optional > ("MAY"), recommended ("SHOULD") or mandatory ("MUST"): > - the reason of the "MUST NOT" was compatibility with the standard mode > (but look at the next message). > - "MAY" is the simplest, it only adds a new option > - "SHOULD" can be argued because it is more in the line of the "all" > idea and avoids to give a choice (i.e., to become incompatible) > - "MUST" IMHO is too early because it makes some current implementations > both incompatible and not compliant. > Note that the current wording could be interpreted as an implicit MAY? MAY sound good to me. Vijay > > Regards > > Francis.Dupont@point6.net _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 17 18:27:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVcCB-0004mX-C4; Mon, 17 Apr 2006 18:27:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVcC9-0004mQ-DW for mip6@ietf.org; Mon, 17 Apr 2006 18:27:45 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVcC9-0000yW-5C for mip6@ietf.org; Mon, 17 Apr 2006 18:27:45 -0400 Received: from [10.1.201.19] ([10.1.201.19]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Apr 2006 15:27:43 -0700 Message-ID: <4444165F.1070305@azairenet.com> Date: Mon, 17 Apr 2006 15:27:43 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Francis Dupont Subject: Re: [Mip6] Changes to draft-ietf-mip6-ikev2-ipsec (Comp) References: <200604172052.k3HKqvFn071112@givry.rennes.enst-bretagne.fr> In-Reply-To: <200604172052.k3HKqvFn071112@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Apr 2006 22:27:43.0887 (UTC) FILETIME=[2554B1F0:01C6626E] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Francis Dupont wrote: > The second point is compatibility with current implementations: the > "tunnel all" mode is clearly not compatible as it introduces a new > choice. > But in fact the current (previous soon :-) specs don't enforce full > compatibility because the SA pairs for BU/BA and for MPS/MPA protections > can be shared or not. So if we consider the "tunnel all" mode as a > super sharing option, it is just a third case... I am not sure I understand the concern. there is still a "MUST" for the packet formats specified in RFC 3775. the tunnel all mode is optional. so there shouldnt be an interop issue. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 17 18:30:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVcFE-0006a0-AF; Mon, 17 Apr 2006 18:30:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVcFC-0006Zv-T8 for mip6@ietf.org; Mon, 17 Apr 2006 18:30:54 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVcFB-00014e-F2 for mip6@ietf.org; Mon, 17 Apr 2006 18:30:54 -0400 Received: from [10.1.201.19] ([10.1.201.19]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Apr 2006 15:30:51 -0700 Message-ID: <4444171B.2020009@azairenet.com> Date: Mon, 17 Apr 2006 15:30:51 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Francis Dupont Subject: Re: [Mip6] Changes to draft-ietf-mip6-ikev2-ipsec (IPsec) References: <200604172106.k3HL6bwi071148@givry.rennes.enst-bretagne.fr> In-Reply-To: <200604172106.k3HL6bwi071148@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Apr 2006 22:30:51.0916 (UTC) FILETIME=[9567A4C0:01C6626E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Francis Dupont wrote: > The "tunnel all" mode has some impacts on IPsec: > - there is no more transport mode SAs: the IPsec config is far simpler. > - all packets between the MN and the HA are through the tunnel: there are > no difference (at the exception of the MIPv6 signaling for mobility > control) with a mobile IPsec VPN with the MN in the client role and > the HA in the Security Gateway role. > - the K flag (again) is very useful: the MIPv6 signaling updates the SPD > and the SAD but can't directly update the IKE internal state (this is > the role of the K flag stuff). agree with the above. > - actions at home are not very clearly defined: one can delete the tunnel > as usual or keep it in order to make the home position not so special > (cf monami6 stuff for development of this kind of ideas), both are possible. the mobile node can explicitly tear down the tunnels, keep the tunnels or just let the IPsec SAs expire. Vijay > > Regards > > Francis.Dupont@point6.net _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 18 08:08:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVp0U-0003bF-26; Tue, 18 Apr 2006 08:08:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVp0T-0003b6-Fl for mip6@ietf.org; Tue, 18 Apr 2006 08:08:33 -0400 Received: from smtp12.clb.oleane.net ([213.56.31.47]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVp0T-000272-3N for mip6@ietf.org; Tue, 18 Apr 2006 08:08:33 -0400 Received: from Pavillonquatre ([194.3.133.88]) by smtp12.clb.oleane.net with ESMTP id k3IC8P4G018770 for ; Tue, 18 Apr 2006 14:08:30 +0200 Message-Id: <200604181208.k3IC8P4G018770@smtp12.clb.oleane.net> From: "Chantal Ladouce" To: Date: Tue, 18 Apr 2006 14:07:27 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZi4Kjj7pJOZFvuSqOnN/9vT3R1lg== X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Subject: [Mip6] Mobile TV World Congress 2007 - Paris - France X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2116551458==" Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============2116551458== Content-Type: multipart/alternative; boundary="----=_NextPart_000_05BC_01C662F1.6D1AC870" This is a multi-part message in MIME format. ------=_NextPart_000_05BC_01C662F1.6D1AC870 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The Mobile TV World Congress, will be held in Paris January 23 to 26, together with the worldwide leader event TVoDSL 2007. Carriers, content providers and equipment vendors will address technical issues, describe the standardization process and discuss business and content delivery models. A call for proposals is online at: http://www.upperside.fr/mobiletv2007/mobiletv2007intro.htm ------=_NextPart_000_05BC_01C662F1.6D1AC870 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The Mobile TV World = Congress, will be held in Paris January 23 to 26, together with the worldwide leader event = TVoDSL = 2007.

Carriers, content providers and equipment = vendors will address technical issues, describe the standardization process and = discuss business and content delivery models.

 

A call for proposals is online = at:

http://www.upperside.fr/mobiletv2007/mobiletv2007intro.htm

 

------=_NextPart_000_05BC_01C662F1.6D1AC870-- --===============2116551458== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============2116551458==-- From mip6-bounces@ietf.org Tue Apr 18 13:13:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVtlc-0006OK-C9; Tue, 18 Apr 2006 13:13:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVtlb-0006OC-3q for mip6@ietf.org; Tue, 18 Apr 2006 13:13:31 -0400 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVtlZ-0002LI-Ml for mip6@ietf.org; Tue, 18 Apr 2006 13:13:31 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.10.03) with ESMTP id k3IHDPf9017594; Tue, 18 Apr 2006 19:13:25 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [192.44.77.29]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.09.01) with ESMTP id k3IHDNZK017590; Tue, 18 Apr 2006 19:13:23 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id k3IHDNvZ074290; Tue, 18 Apr 2006 19:13:23 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200604181713.k3IHDNvZ074290@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Vijay Devarapalli Subject: Re: [Mip6] Changes to draft-ietf-mip6-ikev2-ipsec (Comp) In-reply-to: Your message of Mon, 17 Apr 2006 15:27:43 PDT. <4444165F.1070305@azairenet.com> Date: Tue, 18 Apr 2006 19:13:23 +0200 X-Virus-Scanned: amavisd-new at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org In your previous mail you wrote: Francis Dupont wrote: > The second point is compatibility with current implementations: the > "tunnel all" mode is clearly not compatible as it introduces a new > choice. > But in fact the current (previous soon :-) specs don't enforce full > compatibility because the SA pairs for BU/BA and for MPS/MPA protections > can be shared or not. So if we consider the "tunnel all" mode as a > super sharing option, it is just a third case... I am not sure I understand the concern. there is still a "MUST" for the packet formats specified in RFC 3775. the tunnel all mode is optional. so there shouldnt be an interop issue. => the MN and the HA must either both be configured to use the tunnel all mode or the old RFC 3775 style. But this is not a new constraint as they already had to be configured to share or not the transport mode SAs for BU/BA and MPS/MPA, i.e., we add only a new option to an already existing issue (so this is not a concern). Regards Francis.Dupont@point6.net _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 19 18:22:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWL3a-0001Wo-Og; Wed, 19 Apr 2006 18:21:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWL3Z-0001Uo-2k for mip6@ietf.org; Wed, 19 Apr 2006 18:21:53 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWL3Y-000322-4r for mip6@ietf.org; Wed, 19 Apr 2006 18:21:53 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k3JMJfrN003388 for ; Thu, 20 Apr 2006 01:19:45 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Apr 2006 01:21:45 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Apr 2006 17:21:43 -0500 Received: from 10.162.253.122 ([10.162.253.122]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 19 Apr 2006 22:21:43 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 19 Apr 2006 17:22:52 -0500 From: Basavaraj Patil To: Message-ID: Thread-Topic: Minutes of MIP6 WG meeting from IETF65 Thread-Index: AcZj/8wtCqv4hs/zEdqNzQARJNUNiA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 19 Apr 2006 22:21:43.0806 (UTC) FILETIME=[A38831E0:01C663FF] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5299d0955d21ceeb18e25a232290fec Subject: [Mip6] Minutes of MIP6 WG meeting from IETF65 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Minutes of: Mobility for IPv6 (mip6) WG At: IETF65 March 20, 2006 (Dallas) Chairs: Basavaraj Patil , Gopal Dommety Credit for these minutes: 1. Victor Fajardo (vfajardo at tari dot toshiba dot com 2. Timothy Kniveton for being the Jabber scribe (tj at kniveton dot com) Jabber logs at: http://www.ietf.org/meetings/ietf-logs/mip6/2006-03-20.html #################################################### I. Chairs statements: 1. Whats published - RFC 4238 - RFC 4285 2. Whats in the editors Queue - mip6-firewall - mip6-mipv6-mib - standards - mip6-percfgkbm - standards 3. Whats in IEST Evaluation - mip6-bootstrap-ps (info) - mip6-mipext-adavpi 4. IESG Eval - mip6-ikev2-ipsec 5. WG LC on mip6-cn-ipsec Comments: - HMAC-SHA1 in RFC4285 is 128-bit, why 128 and not 160 ? To be clarified by the authors. - HA reliability issue now has a design team a. problem document b. scope c. solution II. Presentations: 1. draft-ietf-mip6-v4traversal-01.txt (Hesham Soliman) - joint working group item with NEMO - CoA address independence, bind IPv4 to IPv6 and vice versa - NAT traversal - 5 issues outstanding - No discussion on the mip6 alias Issue updates: a. Issue 58: Proxy ARP in HA b. Issue 62: Editorials c. Issue 64: Sending BU and BA in UDP tunnels d. Issue 63: Prefering IPv6 CoA when both v4 and v6 are available Outstanding: a. Issue 60 ligthweight keepalives Overview: - netbinding on 110 seconds w/c is cumbersome - ping like keep alive is needed - current keep alives relies on BU in the absence of traffic - need ligthweight version for small mobile devices - create ping-like mechanisms over UDP Comments: a. Neutral - NAT Binding alive on other working group (BEHAVE WG - NAT behavior), can be inline with that work b. Pro - because theres lifetime in the BU, not same as keep alive - you must use the same UDP port so maybe not applicable to - expensive encryption - use only for keeping NAT bindings c. Against - do not think this is expensive - how about a lite BU ? - ecnryption may not be that expensive (Charles) if keep alives are very infrequent - maybe unecessary since other traffic can be used for keeping NAT binding, counter=for interoperability b. Issue 71: Use of the CoA option Overview: - use of CoA option requires the use of the HoA in the source address filed - This violates the format in RFC3775 Comments: a. Against - Second bullet is wrong - there is no violation b. Pro - It is a violation since text on 3775 simply says "how to send BU" - Dynamic detection of NAT in the HAs domain Overview: - current draft assumes that the HA is configured with presence of NAT in its domain - draft handles dynamic detection of the NA in the MN's domain - UNRESOLVED Comments: a. Pro - super set scenario for flexibility - could be an extension if there is a strong need - more configuration makes it harder - not as costly b. Againts - no need for dynamic detection as a consensus - more complexity 2. draft-ietf-mip6-ikev2-ipsec, 2401bis - Update (Vijay Devarapalli) Overview: - Minor changes to address Jari Arkko's comments - Remove reference to EAP-ONLY-AUTHENTICATION Notificatin payload - should be pursued separately - The K-bit - do we still need the K-bit if we have MOBIKE ? - at least move it to separate section - discussion in the ML: - IKE SA is delete, associated IPsec SA are also delete, so updating IKE SA is important - does not make sense to use MIPv6 and MOBIKE at the same time - k-bit is easier in IKEv2 than IKEv1 Comments: - cleanup k-bit issue (from Jari) - maybe out of scope ? - cannot say deprecate this flag in another doc, maybe say set or not but cannot say deprecate - no consensus to remove k-bit - make a statement regarding "if you use MOBIKE then dont use MIPv6". We need to be clear about it since there will be interoperability - what does mip6 want ? (jari) - we should do technical comparison before consensus a. Pro: - its fine to update 3775 because thats what we do - dont need to specify simulteneously use MOBIKE and MIPv6 because it's just an opinion and you can make it work maybe information text somewhere b. Againts: - keep k-bit but clarify operations, not clear cause you need to know how to implement it - IPsec Selector Granularity - Cases - Fine grained selectors are supported - tunnel mode SA for HoTi - Protocol level selectors are supported - Protocol selectors not available 3. draft-ietf-mip6-aaa-ha-goals-01 (Gerardo Giaretta) Overview: - Draft is fully reviewed - both split and integrated has been reviewed - has been updated in the latest version - Critical Portion: - G1.4 - AAA-HA interface SHOULD provide confidentiality since it may be used to transfer keying material - shared key generated during EAP authentication - Unsure Porition: - G2.2 - HA should be able to query the AAH server to verfy MIPv6 service authorizaiton Comments: - Should'nt require solutions in this group Reply from Author: - Intent is to just list all the goals - G2.5 - HA MUST BE ABLE TO REQUEST THE aaaH server an extension of the auth lifetime granted to the MN - G2.3 - Comments: - AAAH server MAY enforce explicit operational limitations and authorization - Are you asking a doc fulfills the goals has to contain this spec ? maybe multiple docs - ansr: yes. - What is the authorization protocol for use in this goal ? ansr: same as diameter - you can extend auth lifetime. Don't need to define new protocols since this is just a set of goals - Suggest remove 2.3 - difficult to do this in MIPv6, maybe use of this is logging that can be sent to HA but maybe not possible in MIPv6 - What is the relationship with the EAP-EMSK ? needs to be discussed in EAP and followed by MIPv6 - John: what are the really things that you really need since DIME is working on a app for this - Avi: issue with the work enforce - Main issues: - List requirements for AAA-HA interface - complete for split scenario - integrated scenario implies some MIPv6 attributes exchange from AAA to NAS - Should we broaden scope of the draft to encompass all AAA req for MIPv6 ? Comments: - Intention: Get all AAA requirements - When is this avaialbe ? (john) - ansr: broaden scope first (raj) maybe next ietf but need more feedback 4. draft-ietf-mip6-bootstrapping-split-02 (Gerardo Giaretta) Overview: - WGLC last Dec - New ID available after WGLC - 2 open technical issues a. Use-ASSIGNED_HoA attribute - specifies a new IKEv2 notify message type in case the MN tries to perform HoA auto-conf but it is not allowed - proopsal during WGLC: the HA may raise b. DNS Update - some concerns: mobile should update only if trusted scalability issue if each MN has to established SA with the DNS - no consensus to make the changes - DNS expert review requested c. MIP6_HOME_PREFIX attribute - draft specified attribute configuration in order to send Home prefix to the MN - no consensus - IKEv2/IPsec expert review requested Comments: - Do we want to ask expert if we want to have more prefixes ? ansr: try to get some consensus in the ML on what to ask experts. - Configuraiton stuff in IKEv2 is not designed to do this ? ansr: thats why we ask experts for this - Next steps - authors request WG chairs for expert review - if more changes then new WGLC 5. Report on MIP6 operation with IKEv1 Interoperability test from TAHI (Shinta Sugimoto) Overview: - Interoperability testing in IKEv1 and MIPv6 - Scenarios - K-bit = 0, results are in slides in the example message sequence - K-bit = 1, results are in slides in the example message sequence - Summary - rekeying in IPsec can be performed independely from MIPV6 registration - same with ISAKMP SA. However, ISAKMP SA sholud be closed when the MN changes its attachement 6. draft-sugimoto-mip6-homelan-access-00.txt (Shinta Sugimoto) Overview: - Seamless and secure access to home network - mip6 may fit well in this scenario, mip6 is assured to be connected to homelink - may rely on link-local communication to realize zero-conf - rfc3775 does not allow HA forwarding link-local traffic so propsed extension a. S flag - request link local home address, see slides for clarification on use of this flag b. link local multicast address option - allow MN to request for bypassing particular HA c. Alternate interafce ID option, valid only when S flag is set in the BU message d. security considerations: exposure of net internals to third party, off-path eavsdropping 7. draft-dupont-ikev2-haassign-01.txt (Francis Dupont) Overview: - missing features for IKEv2 based solution - strong properties for care-of address - home agent assignment(==choice controlled by the home side): this document - security - basically secure (cant get Ss with a fake home agent) - default defense for DoS agains the hHA (stateless cookie) - defense for Dos against the mobile node Comments: - unknown from the chairs on how to proceed ? needs more discussion in the ML 8. draft-devarapalli-mip6-authprotocol-bootstrap (Vijay Devarapalli) Overview: - why ? current bootstrapping focus on IKEv2 - Boostrapping HA - Home agent configuration - SA setup - RC4285 is an alternative to IPsec (and IKEv2 but does not provide all the feateurs) - Reachability, no new mechanism, DNS update Comments: - Questions on why we need another bootstrapping protocol ? need to have further discussion on justifying the work 10. next steps for the WG Overview: - mip6 boostrapping, solution for split and integrated - v4/v6 tranversal - progress the location privacy for publication as information RFC - increase scope of doc AAA HA goals. doc to be last called in the WG - split the base protocol spec (mip6), i.e. sep route discovery etc. Comments: - give it time to have some implementation experience (question) - a few mistakes are there so we may want to take on the work also since there are dependencies (chair) - should be one document since its hard to keep track of the pieces (comment) 11. draft-chowdhury-mip6-radius-00.txt (Kuntal Chowdhury) Overview: - Bootstrap scenario for MIPv6 with RADIUS - covers the bootstrapping goals doc - split scenario - HA as a RADIUS client - RADIUS server may also instruct the HA to perform DNS update for the MN - integrated scenario - see goals - RADIUS attributes Comments: - should this work be in DIME or RADEXT ? - verify the neighbor case - add a mobile network prefix attribute - next steps, work in the goals people, maybe for the RADEXT group work _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Apr 20 15:26:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWenc-0005um-Gh; Thu, 20 Apr 2006 15:26:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWenb-0005uc-Gf for mip6@ietf.org; Thu, 20 Apr 2006 15:26:43 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWenX-0001VV-3M for mip6@ietf.org; Thu, 20 Apr 2006 15:26:43 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k3KJOuLi007599; Thu, 20 Apr 2006 22:24:59 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Apr 2006 22:26:32 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Apr 2006 14:26:29 -0500 Received: from 10.241.32.10 ([10.241.32.10]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Thu, 20 Apr 2006 19:26:29 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Thu, 20 Apr 2006 14:27:41 -0500 From: Basavaraj Patil To: Message-ID: Thread-Topic: WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt Thread-Index: AcZksH2Mu9KA0tCjEdqTSAARJNUNiA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 20 Apr 2006 19:26:30.0032 (UTC) FILETIME=[533F5900:01C664B0] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Gopal Dommety Subject: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hello, WG I-D: draft-ietf-mip6-ikev2-ipsec-06.txt (Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture) has been revised based on feedback received in the last few months. This document has already completed a WG last call which was issued in September 05. This is a second WG last call for this I-D. Please review and provide comments and feedback to the authors directly or via the MIP6 mailing list. The last call will end on May 5th, 2006. A diff about the changes made from version 05 to version 06 are at: http://www.dvijay.com/ietf/internet-drafts/mip6/diff-05to06.html -Chairs _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Apr 20 16:17:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWfac-0003Z1-Qh; Thu, 20 Apr 2006 16:17:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWfab-0003Yq-HN for mip6@ietf.org; Thu, 20 Apr 2006 16:17:21 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWfaa-0003sc-44 for mip6@ietf.org; Thu, 20 Apr 2006 16:17:21 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3KKHHYg019031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 20 Apr 2006 13:17:19 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3KKHBJl000089; Thu, 20 Apr 2006 13:17:17 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Apr 2006 13:17:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt Date: Thu, 20 Apr 2006 13:17:02 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF00233CF36@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt Thread-Index: AcZksH2Mu9KA0tCjEdqTSAARJNUNiAABtNCg From: "Soliman, Hesham" To: "Basavaraj Patil" , X-OriginalArrivalTime: 20 Apr 2006 20:17:04.0058 (UTC) FILETIME=[63AAF9A0:01C664B7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Gopal Dommety X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org I'd really like to understand the reason for the chane in section 3 (packet formats). Can someone shed some light on this? Hesham=20 > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com]=20 > Sent: Thursday, April 20, 2006 3:28 PM > To: mip6@ietf.org > Cc: Gopal Dommety > Subject: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt=20 >=20 >=20 > Hello, >=20 > WG I-D: draft-ietf-mip6-ikev2-ipsec-06.txt (Mobile IPv6=20 > Operation with > IKEv2 and the revised IPsec Architecture) has been revised based on > feedback received in the last few months. This document has already > completed a WG last call which was issued in September 05. >=20 > This is a second WG last call for this I-D. Please review and provide > comments and feedback to the authors directly or via the MIP6 mailing > list. The last call will end on May 5th, 2006. >=20 > A diff about the changes made from version 05 to version 06 are at: > http://www.dvijay.com/ietf/internet-drafts/mip6/diff-05to06.html >=20 > -Chairs >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Apr 20 17:24:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWgdT-0005iO-CK; Thu, 20 Apr 2006 17:24:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWgdS-0005iJ-Qg for mip6@ietf.org; Thu, 20 Apr 2006 17:24:22 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWgdR-0007fU-Fb for mip6@ietf.org; Thu, 20 Apr 2006 17:24:22 -0400 Received: from [10.1.201.19] ([10.1.201.19]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Apr 2006 14:24:17 -0700 Message-ID: <4447FC01.7030804@azairenet.com> Date: Thu, 20 Apr 2006 14:24:17 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt References: <1487A357FD2ED544B8AD29E528FF9DF00233CF36@NAEX06.na.qualcomm.com> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF00233CF36@NAEX06.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Apr 2006 21:24:17.0770 (UTC) FILETIME=[C7F294A0:01C664C0] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: Gopal Dommety , mip6@ietf.org, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Soliman, Hesham wrote: > I'd really like to understand the reason for the chane in section 3 > (packet formats). Can someone shed some light on this? well, the tunnel mode BU has been around for a long time. draft-ietf-mip6-ikev2-ipsec also explicitly mentioned the tunnel mode in version 03 or 04, when the "Selector Granularity Considerations" section was introduced. but there was no packet format for a tunnel mode BU anywhere in any RFC or a working group document. due to this there was way too much confusion regarding the packet format for a tunnel mode BU. so this is supposed to be clarifying that. note that support for transport mode BU at the mobile node and the home agent is mandatory. I had sent a mail proposing this text before adding it to the draft on April 5th. Vijay > > Hesham > > > -----Original Message----- > > From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com] > > Sent: Thursday, April 20, 2006 3:28 PM > > To: mip6@ietf.org > > Cc: Gopal Dommety > > Subject: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt > > > > > > Hello, > > > > WG I-D: draft-ietf-mip6-ikev2-ipsec-06.txt (Mobile IPv6 > > Operation with > > IKEv2 and the revised IPsec Architecture) has been revised based on > > feedback received in the last few months. This document has already > > completed a WG last call which was issued in September 05. > > > > This is a second WG last call for this I-D. Please review and provide > > comments and feedback to the authors directly or via the MIP6 mailing > > list. The last call will end on May 5th, 2006. > > > > A diff about the changes made from version 05 to version 06 are at: > > http://www.dvijay.com/ietf/internet-drafts/mip6/diff-05to06.html > > > > -Chairs > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Apr 20 21:46:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWkjA-0008LO-75; Thu, 20 Apr 2006 21:46:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWkj6-0008Kp-Ro for mip6@ietf.org; Thu, 20 Apr 2006 21:46:28 -0400 Received: from f.csce.kyushu-u.ac.jp ([133.5.33.1]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FWkj1-0006Io-0w for mip6@ietf.org; Thu, 20 Apr 2006 21:46:28 -0400 Received: (qmail 14203 invoked from network); 21 Apr 2006 01:46:13 -0000 Received: from unknown (HELO ?172.17.3.211?) (192.168.77.254) by 192.168.77.101 with SMTP; 21 Apr 2006 01:46:13 -0000 Date: Fri, 21 Apr 2006 10:46:13 +0900 From: Teruaki Kitasuka To: manet@ietf.org, mip4@ietf.org, mip6@ietf.org, mipshop@ietf.org, monami6@ietf.org, nemo@ietf.org Message-Id: <20060421104311.4A52.KITASUKA@f.csce.kyushu-u.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.24.02 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Cc: Subject: [Mip6] Extended Deadline - CfP - 3rd Int. Conf. on Mobile Computing and Ubiquitous Networking (ICMU2006) at London, UK X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org (Apologies if you receive multiple copies of this message) !!!! Extended Deadline to May 9, ICMU2006 !!!! ======================================================================== C A L L F O R P A P E R S ======================================================================== The Third International Conference on Mobile Computing and Ubiquitous Networking (ICMU2006) October 11-13, 2006 BCS London Office, London, UK http://www.icmu.org/icmu2006/ Sponsored by: IPSJ SIG-MBL (Information Processing Society of Japan, Special Interest Group of Mobile Computing and Ubiquitous Networking) Technically co-sponsored by: BCS (British Computer Society), IEE (Institution of Electrical Engineers), and IEEE ITS Society, Technical Committee on Mobile Communications & Applications Supported by: ICF (International Communications Foundation) and SCAT (Support Center for Advanced Telecommunications Technology Research, Foundation) SCOPE: Mobile computing aims at ubiquitous user access to computer application. To make it possible, networking technology which enables Internet access anytime and everywhere, i.e. ubiquitous networking is necessary. It is obvious that with the accelerating trends towards mobile networks, ad-hoc networks, and wireless networks, mobile computing and ubiquitous networking will play an important role in future network. This conference is aimed at providing researchers and practitioners in this hot research area a forum for discussion and collaboration. Authors are invited to submit papers addressing, but not limited to, the following topics: - Network management for ubiquitous networking - Data management for mobile computing - Mobile device management - Performance evaluation for mobile computing and ubiquitous networking systems - Broadcast communications - Network architectures, protocols, or service models for ubiquitous networking - Security in mobile computing and ubiquitous networking - Mobile OS - Wireless and mobile communications - 4G wireless communications - Mobile Internetworking - Ad-hoc networks - Network mobility - Mesh networks - Sensor networks - Location-based services SUBMISSION INSTRUCTIONS: Papers are solicited as full papers of no more than 8 pages, each of which will be subject to a full review process. Submission should already follow the author guidelines as specified in the web site below. An electronic, PDF-based submission of papers is mandatory. Please check the web site of the conference http://www.icmu.org/icmu2006/ for further submission instructions. After the conference, a selected number of papers will be published as special issues in IPSJ journal and IPSJ Digital Courier. Please check the web site of IPSJ http://www.ipsj.or.jp/08editt/dc/index.html for the details of IPSJ Digital Coulier. IMPORTANT DATES: ########################################################## # Deadline for submissions : May 9, 2006 # # Notification of acceptance: July 8, 2006 # # Camera ready due: July 31, 2006 # ########################################################## ORGANIZING COMMITTEE: General Chair: Chai-Keong Toh (Queen Mary University of London, UK) Technical Program Committee Co-Chairs: Susumu Ishihara (Shizuoka University, Japan) Eiji Kamioka (National Institute of Informatics, Japan) Publication Co-Chairs: Gen Kitagata (Tohoku University, Japan) Yang Yang (University College London, UK) Publicity Co-Chairs: Teruaki Kitasuka (Kyushu University, Japan) Kun Yang (University of Essex, UK) Local Arrangement Chair: David Martland (Kingston University London, UK) Hiroshi Mineno (Shizuoka University, Japan) Treasurers: David Martland (Kingston University London, UK) Tomohiko Yagyu (NEC, Japan) Registration Co-Chairs: Jindong Hou (France Telecom, UK) Homare Murakami (NICT, Japan) ICMU STEERING COMMITTEE: Tadanori Mizuno (Shizuoka University, Japan) Osamu Takahashi (Future University-Hakodate, Japan) Takashi Watanabe (Shizuoka University, Japan) Miki Yamamoto (Kansai University, Japan) TECHNICAL PROGRAM COMMITTEE: Mohammed Atiquzzaman (University of Oklahoma, USA) Xiuzhen Cheng (George Washington University, USA) We Duke Cho (Ajou University, Korea) John Gardiner (Bradford University, UK) Teruo Higashino (Osaka University, Japan) Choong Seon Hong (Kyung Hee University, Korea) Russell Hsing (Telcordia Technologies, USA) Chung Ming Huang (National Cheng Kung University, Taiwan) Joseph Hui (Arizona State University, USA) Masugi Inoue (NICT, Japan) Masahiro Ishiyama (Toshiba Corporation, Japan) Holger Karl (University of Paderborn, Germany) Hughes Kester (Qinetiq Ltd, UK) Dongkyun Kim (Kyungpook National University, Korea) Peter Langendoerfer (IHP Microelectronics, Germany) Madjid Merabti (Liverpool John Moores University, UK) Isabelle Moreau (Mitsubishi Electric ITE, France) Hiroyuki Morikawa (University of Tokyo, Japan) Yasuto Nakanishi (Keio University, Japan) Ken Ohta (NTT DoCoMo, Japan) Ryouji Ono (Mitsubishi Electric, Japan) Mohamed Ould-Khaoua (University of Glasgow, UK) Antonio Pescape (University of Napoli, Italy) Petar Popovski (Aalborg University, Denmark) Jeremy Randles (British Telecom, UK) Ichiro Satoh (National Institute of Informatics, Japan) Winston Seah (Institute for Infocomm Research, Singapore) Hiroshi Shigeno (Keio University, Japan) Biplab Sikdar (Rensselaer Polytechnic Institute, USA) David Simplot-Ryl (University of Lille 1, France) Tatsuya Suda (University of California Irvine, USA) Shinta Sugimoto (Nippon Ericsson, Japan) Keisuke Suwa (Musashi Institute of Technology, Japan) Kevin W. Tsai (University of California, Irvine, USA) Xin Wang (Fudan University, China) Neil Williams (ERA Technology Ltd, UK) Nik Van den Wingaert (University of Antwerp, Belgium) Hirozumi Yamaguchi (Osaka University, Japan) Kun Yang (Essex University, UK) Yang Yang (University College London, UK) Masashi Yano (Hitachi Ltd, Japan) Hidetoshi Yokota (KDDI R&D Laboratories, Japan) Ekio Yoneki (Cambridge University, UK) Qing-An Zeng (University of Cincinnati, USA) ---- $BKL?\2l(B $B51L@(B TEL/FAX: 092-583-7625($B8&5f<<(B), FAX2: 092-583-1338($B>pJs;vL3<<(B) $B6e=#Bg3X(B $BBg3X1!(B $B%7%9%F%`>pJs2J3X8&5f1!(B $B>pJs9)3XItLg(B($BC^;gCO6h(B) $BJ!ED!&Cf@>8&5f<<(B $B=u X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt Thread-Index: AcZkwM8t6w/aA80dRdmIaPqjjAbKjwAPa/aw From: "Soliman, Hesham" To: "Vijay Devarapalli" X-OriginalArrivalTime: 21 Apr 2006 04:49:49.0961 (UTC) FILETIME=[05933790:01C664FF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Gopal Dommety , mip6@ietf.org, jari.arkko@ericsson.com, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > well, the tunnel mode BU has been around for > a long time. draft-ietf-mip6-ikev2-ipsec also > explicitly mentioned the tunnel mode in > version 03 or 04, when the "Selector > Granularity Considerations" section was > introduced. =3D> Tunnel mode was never around for the BU and it should not be. I see no reason for this change; in fact I think it's bad to allow this for several reasons. If we want to open=20 the tunnel mode discussion again then I would suggest that=20 we eliminate it for everything except for the HOTI/HOT exchange. It has clearly been a problem with implementations that don't interface with IPsec and it's completely unnecessary.=20 In any case, even if this is to be done, it should not be done=20 in this draft, in the last minute after WGLC.=20 Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 21 14:49:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX0go-00040k-Sk; Fri, 21 Apr 2006 14:49:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX0go-0003z7-8h for mip6@ietf.org; Fri, 21 Apr 2006 14:49:10 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FX0gn-0000O1-0O for mip6@ietf.org; Fri, 21 Apr 2006 14:49:10 -0400 Received: from [10.1.201.19] ([10.1.201.19]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Apr 2006 11:49:03 -0700 Message-ID: <4449291E.5090101@azairenet.com> Date: Fri, 21 Apr 2006 11:49:02 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt References: <1487A357FD2ED544B8AD29E528FF9DF00233D24C@NAEX06.na.qualcomm.com> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF00233D24C@NAEX06.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Apr 2006 18:49:03.0234 (UTC) FILETIME=[4276EE20:01C66574] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Gopal Dommety , mip6@ietf.org, jari.arkko@ericsson.com, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Soliman, Hesham wrote: > > > well, the tunnel mode BU has been around for > > a long time. draft-ietf-mip6-ikev2-ipsec also > > explicitly mentioned the tunnel mode in > > version 03 or 04, when the "Selector > > Granularity Considerations" section was > > introduced. > > => Tunnel mode was never around for the BU and it should not > be. go and take a look at the MIP6 issues list at Jari's page. it was discussed numerous times. it was even advocated as the default mode for MIPv6. > In any case, even if this is to be done, it should not be done > in this draft, in the last minute after WGLC. thats why we are having another WGLC. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 21 14:53:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX0kl-0001kK-2e; Fri, 21 Apr 2006 14:53:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX0kj-0001eD-Q9 for mip6@ietf.org; Fri, 21 Apr 2006 14:53:13 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FX0ki-0000Ti-G1 for mip6@ietf.org; Fri, 21 Apr 2006 14:53:13 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3LIr6w4014492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 21 Apr 2006 11:53:06 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3LIr4Fd010961; Fri, 21 Apr 2006 11:53:05 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Apr 2006 11:52:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt Date: Fri, 21 Apr 2006 11:52:54 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF0023DC8E5@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt Thread-Index: AcZldEj5XWKitnOmS3uWT4oozt2p+wAAFuDQ From: "Soliman, Hesham" To: "Vijay Devarapalli" X-OriginalArrivalTime: 21 Apr 2006 18:52:49.0279 (UTC) FILETIME=[C932A8F0:01C66574] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Gopal Dommety , mip6@ietf.org, jari.arkko@ericsson.com, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org =20 > > =3D> Tunnel mode was never around for the BU and it should not > > be.=20 >=20 > go and take a look at the MIP6 issues list at > Jari's page. it was discussed numerous times. > it was even advocated as the default mode for > MIPv6. =3D> And was never accepted in the spec. I know it was discussed numerous times. >=20 > > In any case, even if this is to be done, it should not be done=20 > > in this draft, in the last minute after WGLC.=20 >=20 > thats why we are having another WGLC. =3D> Good. I think it needs to be removed. Hesham >=20 > Vijay >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 21 15:09:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX10D-0003Wc-1x; Fri, 21 Apr 2006 15:09:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX10C-0003WX-HH for mip6@ietf.org; Fri, 21 Apr 2006 15:09:12 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FX10C-0001Du-Fq for mip6@ietf.org; Fri, 21 Apr 2006 15:09:12 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FX10A-0002gq-VI for mip6@ietf.org; Fri, 21 Apr 2006 15:09:12 -0400 Received: from [10.1.201.19] ([10.1.201.19]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Apr 2006 12:09:03 -0700 Message-ID: <44492DCE.7020608@azairenet.com> Date: Fri, 21 Apr 2006 12:09:02 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt References: <1487A357FD2ED544B8AD29E528FF9DF0023DC8E5@NAEX06.na.qualcomm.com> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF0023DC8E5@NAEX06.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Apr 2006 19:09:03.0506 (UTC) FILETIME=[0DE1E720:01C66577] X-Spam-Score: -1.3 (-) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Gopal Dommety , mip6@ietf.org, jari.arkko@ericsson.com, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Soliman, Hesham wrote: > > > > => Tunnel mode was never around for the BU and it should not > > > be. > > > > go and take a look at the MIP6 issues list at > > Jari's page. it was discussed numerous times. > > it was even advocated as the default mode for > > MIPv6. > > => And was never accepted in the spec. I know it was discussed > numerous times. it was accepted as part of the privacy solutions. it is used when you want to hide the home address from the access network. there is some progress in the mobopts working group on this. it was accepted in draft-ietf-mip6-ikev2-ipsec version 03 when the IPsec selector granularity section was introduced. this was before the first working group last call. also thats when Francis was added as the co-author for this draft. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 21 15:14:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX15E-0006Op-Bj; Fri, 21 Apr 2006 15:14:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX15D-0006Ok-VX for mip6@ietf.org; Fri, 21 Apr 2006 15:14:23 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FX15D-0001Sl-NM for mip6@ietf.org; Fri, 21 Apr 2006 15:14:23 -0400 Received: from [10.1.201.19] ([10.1.201.19]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Apr 2006 12:14:21 -0700 Message-ID: <44492F0B.9070907@azairenet.com> Date: Fri, 21 Apr 2006 12:14:19 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt References: <1487A357FD2ED544B8AD29E528FF9DF0023DC8E5@NAEX06.na.qualcomm.com> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF0023DC8E5@NAEX06.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Apr 2006 19:14:21.0189 (UTC) FILETIME=[CB3C7B50:01C66577] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Gopal Dommety , mip6@ietf.org, jari.arkko@ericsson.com, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Soliman, Hesham wrote: > > > > => Tunnel mode was never around for the BU and it should not > > > be. > > > > go and take a look at the MIP6 issues list at > > Jari's page. it was discussed numerous times. > > it was even advocated as the default mode for > > MIPv6. > > => And was never accepted in the spec. I forgot to mention this. since a few people wanted to use the tunnel mode, we made sure it wasn't prohibited. and we also put in an "at least" in RFC 3776. When the mobile node is away from its home, the BUs sent by it to the home agent MUST support at least the following headers in the following order: the "at least" wasn't there in the earlier text. Vijay I know it was discussed > numerous times. > > > > > > In any case, even if this is to be done, it should not be done > > > in this draft, in the last minute after WGLC. > > > > thats why we are having another WGLC. > > => Good. I think it needs to be removed. > > Hesham > > > > > Vijay > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 21 15:16:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX17W-0007fp-Va; Fri, 21 Apr 2006 15:16:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX17V-0007fj-9L for mip6@ietf.org; Fri, 21 Apr 2006 15:16:45 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FX17T-0001aS-UQ for mip6@ietf.org; Fri, 21 Apr 2006 15:16:45 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3LJGQmw008973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 21 Apr 2006 12:16:28 -0700 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3LJG5Qo020251; Fri, 21 Apr 2006 12:16:25 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Apr 2006 12:16:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt Date: Fri, 21 Apr 2006 12:16:11 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF0023DC927@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt Thread-Index: AcZldxOI7EGdRPAlRKmCSHTtYcuO/wAAC5eA From: "Soliman, Hesham" To: "Vijay Devarapalli" X-OriginalArrivalTime: 21 Apr 2006 19:16:04.0875 (UTC) FILETIME=[0909B5B0:01C66578] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Gopal Dommety , mip6@ietf.org, jari.arkko@ericsson.com, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > >=20 > > =3D> And was never accepted in the spec. I know it was discussed > > numerous times. >=20 > it was accepted as part of the privacy solutions. > it is used when you want to hide the home address > from the access network. there is some progress > in the mobopts working group on this. =3D> This is not relevant to my statement, I'm referring=20 to the MIPv6 specs 3775/6. Transport mode in general is needed for HOTI/HOT, it's useless when the sender is protecting packets for the ultimate receiver with IPsec. This is what transport mode is for! Mobopts is not part of IETF and has no bearing=20 on this discussion.=20 Finally, this draft should not be inventing new packet formats for MIPv6. The purpose is to make sure that IKEv2/new IPsec specs can work with mipv6, not to introduce new features that we could have done with the old specs anyway but chose not to.=20 Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 21 15:26:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX1GX-0001RY-Hs; Fri, 21 Apr 2006 15:26:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX1GW-0001RT-ET for mip6@ietf.org; Fri, 21 Apr 2006 15:26:04 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FX1GV-00022L-3N for mip6@ietf.org; Fri, 21 Apr 2006 15:26:04 -0400 Received: from [10.1.201.19] ([10.1.201.19]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Apr 2006 12:26:00 -0700 Message-ID: <444931C8.4020407@azairenet.com> Date: Fri, 21 Apr 2006 12:26:00 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt References: <1487A357FD2ED544B8AD29E528FF9DF0023DC927@NAEX06.na.qualcomm.com> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF0023DC927@NAEX06.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Apr 2006 19:26:00.0805 (UTC) FILETIME=[6C3D6950:01C66579] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Gopal Dommety , mip6@ietf.org, jari.arkko@ericsson.com, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Soliman, Hesham wrote: > > > > > > > => And was never accepted in the spec. I know it was discussed > > > numerous times. > > > > it was accepted as part of the privacy solutions. > > it is used when you want to hide the home address > > from the access network. there is some progress > > in the mobopts working group on this. > > => This is not relevant to my statement, I'm referring > to the MIPv6 specs 3775/6. Transport mode in general is > needed for HOTI/HOT, I guess you meant tunnel mode. > it's useless when the sender is protecting > packets for the ultimate receiver with IPsec. its useful when you want to setup only one tunnel IPsec SA with the home agent for sending and receiving BU/BAck, MPS/MPA and HoTi/HoT. > This is what > transport mode is for! disagree. many times the mobile node is unable to setup transport mode SA with the CN. > Mobopts is not part of IETF and has no bearing > on this discussion. the idea behind Mobopts is that the initial work gets done there and then the solutions are eventually standardized in the working groups in the IETF. some examples. draft-arkko-mipshop-cga-cba-03.txt, draft-kempf-mobopts-handover-key-01.txt. > Finally, this draft should not be inventing new packet formats for > MIPv6. > The purpose is to make sure that IKEv2/new IPsec specs can work > with mipv6, not to introduce new features that we could have done with > the old specs anyway but chose not to. in previous discussions it was decided that this draft can update RFC 3775 and RFC 3776 if required. RFC 3775 especially assumes the use of IKEv1 and RFC 2401. RFC 2401 is incompatible with IKEv2. IKEv2 requires RFC 4301. > > Hesham > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 21 16:26:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX2DG-00019H-Pq; Fri, 21 Apr 2006 16:26:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX2DF-00019C-AW for mip6@ietf.org; Fri, 21 Apr 2006 16:26:45 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FX2DE-0004Zn-Tz for mip6@ietf.org; Fri, 21 Apr 2006 16:26:45 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3LKPsgG025924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 21 Apr 2006 13:25:55 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3LKPjsJ007178; Fri, 21 Apr 2006 13:25:54 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Apr 2006 13:25:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt Date: Fri, 21 Apr 2006 13:25:49 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF0023DC9F3@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt Thread-Index: AcZleXKWakqdfdbWStS6Pp4ywsBOcQAAOPhQ From: "Soliman, Hesham" To: "Vijay Devarapalli" X-OriginalArrivalTime: 21 Apr 2006 20:25:52.0990 (UTC) FILETIME=[C95957E0:01C66581] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Gopal Dommety , mip6@ietf.org, jari.arkko@ericsson.com, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org =20 > > =3D> This is not relevant to my statement, I'm referring=20 > > to the MIPv6 specs 3775/6. Transport mode in general is > > needed for HOTI/HOT,=20 >=20 > I guess you meant tunnel mode. =3D> yes. >=20 > > it's useless when the sender is protecting > > packets for the ultimate receiver with IPsec.=20 >=20 > its useful when you want to setup only one > tunnel IPsec SA with the home agent for sending > and receiving BU/BAck, MPS/MPA and HoTi/HoT. =3D> I don't think it's a tradeoff that is worth the trouble.=20 You get an additional header, more complexity in the implementation,=20 more trouble classifying packets in the access, potential interoperability problems ...etc and the gain is one SA instead of 2.=20 Again, I'm happy to discuss this, but I strongly think that this draft is not the right place for this change. I believe it was a mistake to remove the HAO in some cases (payload traffic) in 3776. If anything is to be changed, we should put back the HAO. >=20 > > This is what > > transport mode is for! >=20 > disagree. many times the mobile node is unable > to setup transport mode SA with the CN. =3D> ?? first of all we're talking about the BU to the HA.=20 But why would tunnel mode be any harder with a CN? >=20 > > Mobopts is not part of IETF and has no bearing=20 > > on this discussion.=20 >=20 > the idea behind Mobopts is that the initial work > gets done there and then the solutions are > eventually standardized in the working groups in > the IETF. some examples. > draft-arkko-mipshop-cga-cba-03.txt, > draft-kempf-mobopts-handover-key-01.txt. =3D> Honestly, I understand the ideas here but I strongly disagree with this and I strongly disagree with adding it (if it's added=20 at all) to this draft. If this is to be done at all, it should be done in a different context. This draft has to be limited to its original intention.=20 > in previous discussions it was decided that this > draft can update RFC 3775 and RFC 3776 if required. =3D> I don't agree with that. Please point me to those emails that included these decisions.=20 Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 21 17:09:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX2sG-00051a-RJ; Fri, 21 Apr 2006 17:09:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX2r5-0004hI-EX for mip6@ietf.org; Fri, 21 Apr 2006 17:07:55 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FX2kQ-0006HJ-6f for mip6@ietf.org; Fri, 21 Apr 2006 17:01:03 -0400 Received: from [10.1.201.19] ([10.1.201.19]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Apr 2006 14:01:00 -0700 Message-ID: <4449480B.3040704@azairenet.com> Date: Fri, 21 Apr 2006 14:00:59 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt References: <1487A357FD2ED544B8AD29E528FF9DF0023DC9F3@NAEX06.na.qualcomm.com> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF0023DC9F3@NAEX06.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Apr 2006 21:01:00.0253 (UTC) FILETIME=[B16028D0:01C66586] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: Gopal Dommety , mip6@ietf.org, jari.arkko@ericsson.com, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Soliman, Hesham wrote: > > > > > > => This is not relevant to my statement, I'm referring > > > to the MIPv6 specs 3775/6. Transport mode in general is > > > needed for HOTI/HOT, > > > > I guess you meant tunnel mode. > > => yes. > > > > > > it's useless when the sender is protecting > > > packets for the ultimate receiver with IPsec. > > > > its useful when you want to setup only one > > tunnel IPsec SA with the home agent for sending > > and receiving BU/BAck, MPS/MPA and HoTi/HoT. > > => I don't think it's a tradeoff that is worth the trouble. > You get an additional header, more complexity in the implementation, > more trouble classifying packets in the access, potential > interoperability > problems ...etc and the gain is one SA instead of 2. one SA instead of four. you can end up with one SA for BU/BAck, one for HoTi/HoT, one for MPS/MPA and one for tunneling payload traffic. you could send all this traffic through one SA. > Again, I'm happy to discuss this, but I strongly think that > this draft is not the right place for this change. I believe > it was a mistake to remove the HAO in some cases (payload traffic) > in 3776. If anything is to be changed, we should put back the HAO. > > > > > > This is what > > > transport mode is for! > > > > disagree. many times the mobile node is unable > > to setup transport mode SA with the CN. > > => ?? first of all we're talking about the BU to the HA. ok. I thought you were talking about the HoTi. > But why would tunnel mode be any harder with a CN? we are not doing tunnel mode with the CN, with the HA. > > > Mobopts is not part of IETF and has no bearing > > > on this discussion. > > > > the idea behind Mobopts is that the initial work > > gets done there and then the solutions are > > eventually standardized in the working groups in > > the IETF. some examples. > > draft-arkko-mipshop-cga-cba-03.txt, > > draft-kempf-mobopts-handover-key-01.txt. > > => Honestly, I understand the ideas here but I strongly disagree > with this and I strongly disagree with adding it (if it's added > at all) to this draft. If this is to be done at all, it should be > done in a different context. This draft has to be limited to its > original intention. your objection is noted. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 21 17:13:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX2wJ-0000Ql-AL; Fri, 21 Apr 2006 17:13:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX2wH-0000KE-Qc for mip6@ietf.org; Fri, 21 Apr 2006 17:13:17 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FX2wF-0007GW-BC for mip6@ietf.org; Fri, 21 Apr 2006 17:13:17 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3LLCx4P031035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 21 Apr 2006 14:13:00 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3LLCwd2002836; Fri, 21 Apr 2006 14:12:59 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Apr 2006 14:12:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt Date: Fri, 21 Apr 2006 14:12:54 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF0023DCA6E@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt Thread-Index: AcZlhrdPYAMtkXt+S0mdHqv+vcagLwAAN9FA From: "Soliman, Hesham" To: "Vijay Devarapalli" X-OriginalArrivalTime: 21 Apr 2006 21:12:58.0425 (UTC) FILETIME=[5D708290:01C66588] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Gopal Dommety , mip6@ietf.org, jari.arkko@ericsson.com, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > > =3D> I don't think it's a tradeoff that is worth the trouble.=20 > > You get an additional header, more complexity in the=20 > implementation,=20 > > more trouble classifying packets in the access, potential > > interoperability > > problems ...etc and the gain is one SA instead of 2.=20 >=20 > one SA instead of four. you can end up with > one SA for BU/BAck, one for HoTi/HoT, one > for MPS/MPA and one for tunneling payload > traffic. you could send all this traffic > through one SA. =3D> So I take you understand the other points I've raised in addition to the number of SAs. I think we all know that we wouldn't end up with 4 SAs if we used the HAO, so this statement is not accurate. Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 21 17:16:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX2zX-0002Q9-7A; Fri, 21 Apr 2006 17:16:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX2zW-0002Q4-90 for mip6@ietf.org; Fri, 21 Apr 2006 17:16:38 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FX2zU-0007cz-Vr for mip6@ietf.org; Fri, 21 Apr 2006 17:16:38 -0400 Received: from [10.1.201.19] ([10.1.201.19]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Apr 2006 14:16:34 -0700 Message-ID: <44494BB0.6090603@azairenet.com> Date: Fri, 21 Apr 2006 14:16:32 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt References: <1487A357FD2ED544B8AD29E528FF9DF0023DCA6E@NAEX06.na.qualcomm.com> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF0023DCA6E@NAEX06.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Apr 2006 21:16:34.0598 (UTC) FILETIME=[DE49E460:01C66588] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Gopal Dommety , mip6@ietf.org, jari.arkko@ericsson.com, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Soliman, Hesham wrote: > > > > => I don't think it's a tradeoff that is worth the trouble. > > > You get an additional header, more complexity in the > > implementation, > > > more trouble classifying packets in the access, potential > > > interoperability > > > problems ...etc and the gain is one SA instead of 2. > > > > one SA instead of four. you can end up with > > one SA for BU/BAck, one for HoTi/HoT, one > > for MPS/MPA and one for tunneling payload > > traffic. you could send all this traffic > > through one SA. > > => So I take you understand the other points I've raised in > addition to the number of SAs. I think we all know that we > wouldn't end up with 4 SAs if we used the HAO, so this statement > is not accurate. if we tunnel everything we end up with one tunnel SA. the packet format would be IPv6 hdr (src=CoA, dst=HA) ESP header in tunnel mode IPv6 hdr (src=HoA, dst=CN/HA) Payload the "Payload" can be BU, MPS, HoTi or any traffic to the CN. Vijay > > Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 21 20:32:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX62U-0000nN-9r; Fri, 21 Apr 2006 20:31:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX62T-0000nI-8z for mip6@ietf.org; Fri, 21 Apr 2006 20:31:53 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FX62R-0002lj-Ss for mip6@ietf.org; Fri, 21 Apr 2006 20:31:53 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3M0VmsI016642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 21 Apr 2006 17:31:48 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3M0Vivm026382; Fri, 21 Apr 2006 17:31:45 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Apr 2006 17:31:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt Date: Fri, 21 Apr 2006 17:31:36 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF0023DCC04@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt Thread-Index: AcZliONgZRmV8GiHQA6abxSsUi21sgAGyCyw From: "Soliman, Hesham" To: "Vijay Devarapalli" X-OriginalArrivalTime: 22 Apr 2006 00:31:44.0135 (UTC) FILETIME=[21B77170:01C665A4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Gopal Dommety , mip6@ietf.org, jari.arkko@ericsson.com, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > > > > =3D> I don't think it's a tradeoff that is worth the trouble.=20 > > > > You get an additional header, more complexity in the=20 > > > implementation,=20 > > > > more trouble classifying packets in the access, potential > > > > interoperability > > > > problems ...etc and the gain is one SA instead of 2.=20 > > >=20 > > > one SA instead of four. you can end up with > > > one SA for BU/BAck, one for HoTi/HoT, one > > > for MPS/MPA and one for tunneling payload > > > traffic. you could send all this traffic > > > through one SA. > >=20 > > =3D> So I take you understand the other points I've raised in > > addition to the number of SAs. I think we all know that we > > wouldn't end up with 4 SAs if we used the HAO, so this statement > > is not accurate. >=20 > if we tunnel everything we end up with one > tunnel SA. the packet format would be =3D> Not the point I was raising, I don't know why you keep coming=20 back to this.=20 Hesham >=20 > IPv6 hdr (src=3DCoA, dst=3DHA) > ESP header in tunnel mode > IPv6 hdr (src=3DHoA, dst=3DCN/HA) > Payload >=20 > the "Payload" can be BU, MPS, HoTi or any > traffic to the CN. >=20 > Vijay >=20 > >=20 > > Hesham >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 21 21:54:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX7Kp-0001VT-3q; Fri, 21 Apr 2006 21:54:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX7Ko-0001VO-JT for mip6@ietf.org; Fri, 21 Apr 2006 21:54:54 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FX7Kn-00068D-A3 for mip6@ietf.org; Fri, 21 Apr 2006 21:54:54 -0400 Received: from [10.1.201.19] ([10.1.201.19]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Apr 2006 18:54:51 -0700 Message-ID: <44498CEA.4050803@azairenet.com> Date: Fri, 21 Apr 2006 18:54:50 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: mip6@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Apr 2006 01:54:51.0486 (UTC) FILETIME=[BE68CFE0:01C665AF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: James Kempf Subject: [Mip6] Bootstrapping from the home link X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org hello, after some discussions offlist, we came up with some text that could be added to draft-ietf-mip6-bootstrapping-split-02.txt to address bootstrapping from the home link. the proposal is to have this in a new section before the security considerations section. 9. Bootstrapping from the home link The mechanisms described in this document also support a mobile node bootstrapping from the home link. When the mobile node is on the home link it receives router advertisements from the home agent with the 'H' bit set and the 128 bit address of the home agent in the modified prefix information option [RFC3775]. When the mobile node bootstraps, the first operation it does is to perform a DNS lookup for the home agent. If at least one of the home agent address received in the DNS reply matches the address the mobile node received in the router advertisement from the home agent, then the mobile node assumes it is attached to the home link. For configuring a home address, the mobile node can either auto- configure a home address, use DHCPv6 or run IKEv2 with its home agent as described in section 5.3. The mobile node MAY setup IPsec security associations to send and receive Mobile IPv6 signaling messages while still attached to the home link. This would help avoid the latency involved in setting up the security associations during a handoff when the mobile node moves out of the home link. The existence of an IPsec SA for protecting a Binding Update does not depend on the existence of a valid binding cache entry. Therefore the mobile node is free to setup the required security associations at any time. comments are welcome. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Apr 22 05:36:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXEXB-0003ei-9N; Sat, 22 Apr 2006 05:36:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXEXA-0003ed-1X for mip6@ietf.org; Sat, 22 Apr 2006 05:36:08 -0400 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXEX8-0004XI-LN for mip6@ietf.org; Sat, 22 Apr 2006 05:36:08 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.10.03) with ESMTP id k3M9ZcK4017515; Sat, 22 Apr 2006 11:35:38 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [192.44.77.29]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.09.01) with ESMTP id k3M9Zba0017507; Sat, 22 Apr 2006 11:35:37 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id k3M9ZZij090879; Sat, 22 Apr 2006 11:35:36 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200604220935.k3M9ZZij090879@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Soliman, Hesham" Subject: Re: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt In-reply-to: Your message of Thu, 20 Apr 2006 21:49:45 PDT. <1487A357FD2ED544B8AD29E528FF9DF00233D24C@NAEX06.na.qualcomm.com> Date: Sat, 22 Apr 2006 11:35:35 +0200 X-Virus-Scanned: amavisd-new at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Gopal Dommety , mip6@ietf.org, jari.arkko@ericsson.com, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org In your previous mail you wrote: => Tunnel mode was never around for the BU and it should not be. => Hesham, you should defend this opinion with arguments. This discussion is about this. I see no reason for this change; in fact I think it's bad to allow this for several reasons. If we want to open the tunnel mode discussion again then I would suggest that we eliminate it for everything except for the HOTI/HOT exchange. => IMHO we need the whole spectrum. HOTI/HOT only is the other end, I like both ends which correspond to real world situations. The medium case (regular RFC 3775/3776 one) is still needed for compatibility. It has clearly been a problem with implementations that don't interface with IPsec and it's completely unnecessary. => you mean unnecessary of mobility purpose? In any case, even if this is to be done, it should not be done in this draft, in the last minute after WGLC. => I've really tried to get this discussion, the way it is done is not from me. But the important point is we have it, isn't it? Regards Francis.Dupont@point6.net _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Apr 22 06:21:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXFF4-0003kM-7n; Sat, 22 Apr 2006 06:21:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXFF2-0003kH-JY for mip6@ietf.org; Sat, 22 Apr 2006 06:21:28 -0400 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXFF1-0007Gp-6J for mip6@ietf.org; Sat, 22 Apr 2006 06:21:28 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.10.03) with ESMTP id k3MAKvn2019533; Sat, 22 Apr 2006 12:20:57 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [192.44.77.29]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.09.01) with ESMTP id k3MAKuW5019529; Sat, 22 Apr 2006 12:20:56 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id k3MAKtAh091025; Sat, 22 Apr 2006 12:20:55 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200604221020.k3MAKtAh091025@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Vijay Devarapalli Subject: Re: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt In-reply-to: Your message of Fri, 21 Apr 2006 12:09:02 PDT. <44492DCE.7020608@azairenet.com> Date: Sat, 22 Apr 2006 12:20:55 +0200 X-Virus-Scanned: amavisd-new at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Gopal Dommety , mip6@ietf.org, jari.arkko@ericsson.com, "Soliman, Hesham" , Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org In your previous mail you wrote: it was accepted in draft-ietf-mip6-ikev2-ipsec version 03 when the IPsec selector granularity section was introduced. this was before the first working group last call. => IMHO it was not so clearly accepted, this is why we have this discussion (BTW it should be better to get more than 3 persons in it). Regards Francis.Dupont@point6.net _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Apr 22 06:28:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXFLD-0001wy-9w; Sat, 22 Apr 2006 06:27:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXFLB-0001wq-Mx for mip6@ietf.org; Sat, 22 Apr 2006 06:27:49 -0400 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXFLA-0007bb-9W for mip6@ietf.org; Sat, 22 Apr 2006 06:27:49 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.10.03) with ESMTP id k3MARgag019839; Sat, 22 Apr 2006 12:27:42 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [192.44.77.29]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.09.01) with ESMTP id k3MARdYg019835; Sat, 22 Apr 2006 12:27:39 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id k3MARdXk091048; Sat, 22 Apr 2006 12:27:39 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200604221027.k3MARdXk091048@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Soliman, Hesham" Subject: Re: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt In-reply-to: Your message of Fri, 21 Apr 2006 12:16:11 PDT. <1487A357FD2ED544B8AD29E528FF9DF0023DC927@NAEX06.na.qualcomm.com> Date: Sat, 22 Apr 2006 12:27:39 +0200 X-Virus-Scanned: amavisd-new at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Gopal Dommety , mip6@ietf.org, jari.arkko@ericsson.com, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org In your previous mail you wrote: Finally, this draft should not be inventing new packet formats for MIPv6. The purpose is to make sure that IKEv2/new IPsec specs can work with mipv6, not to introduce new features that we could have done with the old specs anyway but chose not to. => I agree but the problem is the 3775bis will not be available soon, so following the advice of the area director the chairs decided to include this in the IKEv2 document. In exchange I asked and got this WGLC about this specific point, so persons (as you) who don't agree can explain why. Regards Francis.Dupont@point6.net _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Apr 22 12:10:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXKgt-0002uV-T4; Sat, 22 Apr 2006 12:10:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXKgs-0002uQ-Ge for mip6@ietf.org; Sat, 22 Apr 2006 12:10:34 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXKgs-00008Y-5Q for mip6@ietf.org; Sat, 22 Apr 2006 12:10:34 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3MGAOh6009869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 22 Apr 2006 09:10:25 -0700 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3MGANbl026553; Sat, 22 Apr 2006 09:10:24 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 22 Apr 2006 09:10:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt Date: Sat, 22 Apr 2006 09:10:23 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF0023DCC8E@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt Thread-Index: AcZl923P9gTnsfjRTT6i72yBhp2tRwALxQpg From: "Soliman, Hesham" To: X-OriginalArrivalTime: 22 Apr 2006 16:10:22.0785 (UTC) FILETIME=[423F7310:01C66627] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Gopal Dommety , mip6@ietf.org, jari.arkko@ericsson.com, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > Finally, this draft should not be inventing new packet formats for > MIPv6. > The purpose is to make sure that IKEv2/new IPsec specs can work > with mipv6, not to introduce new features that we could=20 > have done with > the old specs anyway but chose not to.=20 > =20 > =3D> I agree but the problem is the 3775bis will not be available = soon, > so following the advice of the area director the chairs decided to > include this in the IKEv2 document. In exchange I asked and got > this WGLC about this specific point, so persons (as you) who don't > agree can explain why. =3D> I agree this is a discussion we should have and involve more than 3 people. My reasons were mentioned in another email, I'm copying it here: > its useful when you want to setup only one > tunnel IPsec SA with the home agent for sending > and receiving BU/BAck, MPS/MPA and HoTi/HoT. =3D> I don't think it's a tradeoff that is worth the trouble.=20 You get an additional header, more complexity in the implementation,=20 more trouble classifying packets in the access, potential interoperability problems ...etc and the gain is one SA instead of 2.=20 Again, I'm happy to discuss this, but I strongly think that this draft is not the right place for this change. I believe it was a mistake to remove the HAO in some cases (payload traffic) in 3776. If anything is to be changed, we should put back the HAO. and the tread continued: > one SA instead of four. you can end up with > one SA for BU/BAck, one for HoTi/HoT, one > for MPS/MPA and one for tunneling payload > traffic. you could send all this traffic > through one SA. =3D> So I take you understand the other points I've raised in addition to the number of SAs. I think we all know that we wouldn't end up with 4 SAs if we used the HAO, so this statement is not accurate. I see no reason for using tunnel mode between two end=20 nodes. HOTI/HOT were the only exceptions. I think removing=20 the HAO was a mistake from the beginning and I said it numerous times. The result of the mistake are very clear. If we want to=20 make things simpler we should just use the HAO.=20 But everytime I bring this up (including in Dallas) I get "silence" and=20 no one explains why we can't rely on transport mode with the HAO.... Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Apr 22 12:12:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXKj4-0003gD-6Q; Sat, 22 Apr 2006 12:12:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXKj2-0003g5-9U for mip6@ietf.org; Sat, 22 Apr 2006 12:12:48 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXKj0-0000Ed-VN for mip6@ietf.org; Sat, 22 Apr 2006 12:12:48 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3MGCgmr009950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 22 Apr 2006 09:12:43 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3MGCfbV015097; Sat, 22 Apr 2006 09:12:42 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 22 Apr 2006 09:12:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt Date: Sat, 22 Apr 2006 09:12:41 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF0023DCC8F@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt Thread-Index: AcZl923P9gTnsfjRTT6i72yBhp2tRwAL+FFA From: "Soliman, Hesham" To: X-OriginalArrivalTime: 22 Apr 2006 16:12:41.0684 (UTC) FILETIME=[9509C140:01C66627] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Gopal Dommety , mip6@ietf.org, jari.arkko@ericsson.com, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org =20 > =3D> I agree but the problem is the 3775bis will not be available = soon, > so following the advice of the area director the chairs decided to > include this in the IKEv2 document.=20 =3D> I know you're trying to do the right thing, but this is not how WG documents should be handled. Big changes like this must be=20 discussed on the list before they can be added to the doc. =20 Hesham In exchange I asked and got > this WGLC about this specific point, so persons (as you) who don't > agree can explain why. >=20 > Regards > =20 > Francis.Dupont@point6.net >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Apr 22 18:09:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXQIH-0005cI-Fd; Sat, 22 Apr 2006 18:09:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXQIG-0005Xi-Fj for mip6@ietf.org; Sat, 22 Apr 2006 18:09:32 -0400 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXQIG-0008Oa-2r for mip6@ietf.org; Sat, 22 Apr 2006 18:09:32 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.10.03) with ESMTP id k3MM8v7m027081; Sun, 23 Apr 2006 00:08:57 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [192.44.77.29]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.09.01) with ESMTP id k3MM8u3m027077; Sun, 23 Apr 2006 00:08:56 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id k3MM8qib092323; Sun, 23 Apr 2006 00:08:55 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200604222208.k3MM8qib092323@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Soliman, Hesham" Subject: Re: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt In-reply-to: Your message of Sat, 22 Apr 2006 09:10:23 PDT. <1487A357FD2ED544B8AD29E528FF9DF0023DCC8E@NAEX06.na.qualcomm.com> Date: Sun, 23 Apr 2006 00:08:52 +0200 X-Virus-Scanned: amavisd-new at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: Gopal Dommety , mip6@ietf.org, jari.arkko@ericsson.com, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org In your previous mail you wrote: > its useful when you want to setup only one > tunnel IPsec SA with the home agent for sending > and receiving BU/BAck, MPS/MPA and HoTi/HoT. => I don't think it's a tradeoff that is worth the trouble. => IMHO the real argument is privacy even the tunnel all mode is simpler from an IPsec point of view. You get an additional header, => only for packets previously protected by a transport mode, i.e., a very low amount of traffic. more complexity in the implementation, => as I explained the complexity was already there. more trouble classifying packets in the access, => IMHO it is less trouble than more trouble. potential interoperability problems => a new option in the current interoperability problem, i.e., have compatible policies on the MN and the HA, including for hidden things like SA sharing. and the gain is one SA instead of 2. => the gain is privacy (and full IPsec VPN compatibility, if you believe it is a gain). Again, I'm happy to discuss this, but I strongly think that this draft is not the right place for this change. => IMHO you should open another thread for this point. I believe it was a mistake to remove the HAO in some cases (payload traffic) in 3776. If anything is to be changed, we should put back the HAO. => I don't fully understand your proposal (pointer/description?) I see no reason for using tunnel mode between two end nodes. => here it is to make no difference between MN-CN and MN-HA. HOTI/HOT were the only exceptions. => there are not exceptions, there are the only case where mobility requires this kind of protection (note that all words are important). I think removing the HAO was a mistake from the beginning and I said it numerous times. The result of the mistake are very clear. If we want to make things simpler we should just use the HAO. But everytime I bring this up (including in Dallas) I get "silence" and no one explains why we can't rely on transport mode with the HAO.... => perhaps because you idea was not understood? Regards Francis.Dupont@point6.net PS: the discussion should be extended to the nemo WG too. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Apr 23 14:26:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXjHR-00016u-V7; Sun, 23 Apr 2006 14:25:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXjHQ-00016p-71 for mip6@ietf.org; Sun, 23 Apr 2006 14:25:56 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXjHP-0001t7-Pw for mip6@ietf.org; Sun, 23 Apr 2006 14:25:56 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3NIPjOx009110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 23 Apr 2006 11:25:46 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3NIPiSn019733; Sun, 23 Apr 2006 11:25:44 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 23 Apr 2006 11:25:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt Date: Sun, 23 Apr 2006 11:25:51 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF0023DCD02@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt Thread-Index: AcZmWXjZkI9WKmvrTAynB6ocIAJeQAAqK7Vg From: "Soliman, Hesham" To: X-OriginalArrivalTime: 23 Apr 2006 18:25:43.0477 (UTC) FILETIME=[54F87650:01C66703] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: Gopal Dommety , mip6@ietf.org, jari.arkko@ericsson.com, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > =20 > =3D> I don't think it's a tradeoff that is worth the trouble.=20 >=20 > =3D> IMHO the real argument is privacy even the tunnel all mode is > simpler from an IPsec point of view. =3D> If the idea is to hide the HoA then we should devise a solution for this in a seperate doc, this is a completely separate topic. As=20 you might remember, Claude had an idea for generating a random HoA a few years ago. A privacy draft would be fine, but we certainly haven't discussed/agreed on the privacy space. So we shouldn't be putting a solution when others were proposed earlier.=20 >=20 > You get an additional header, >=20 > =3D> only for packets previously protected by a transport mode, i.e., > a very low amount of traffic. =3D> Yes but we're talking about the BU, this is what the draft changed. = It might not be as frequent as data but adding another header during=20 the handover time is most unhelpful.=20 >=20 > more complexity in the implementation,=20 >=20 > =3D> as I explained the complexity was already there. =3D> The complexity was *added* in 3776 unnecessarily. If we want=20 to reopen this area then we should go back to using transport mode with the HAO and remove all this complexity of requiring=20 MIP6-IPsec interactions which took people years to support!=20 I never saw a good reason for this troublesome design. > and the gain is one SA instead of 2.=20 > =20 > =3D> the gain is privacy (and full IPsec VPN compatibility, if you > believe it is a gain). =3D> I don't believe this is the best way of doing privacy and I = certainly don't think it belongs to this draft.=20 > I see no reason for using tunnel mode between two end nodes. >=20 > =3D> here it is to make no difference between MN-CN and MN-HA. =3D> I don't understand this statement or the one below.=20 > HOTI/HOT were the only exceptions. >=20 > =3D> there are not exceptions, there are the only case where mobility > requires this kind of protection (note that all words are important). >=20 > I think removing=20 > the HAO was a mistake from the beginning and I said it numerous > times. The result of the mistake are very clear. If we want to=20 > make things simpler we should just use the HAO.=20 > But everytime I bring this up (including in Dallas) I get=20 > "silence" and=20 > no one explains why we can't rely on transport mode with=20 > the HAO.... > =20 > =3D> perhaps because you idea was not understood? =3D> I don't know if it was or wasn't because I never received an answer... Hesham > =20 > Regards > =20 > Francis.Dupont@point6.net >=20 > PS: the discussion should be extended to the nemo WG too. >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Apr 23 17:27:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXm6Q-0006CJ-Oe; Sun, 23 Apr 2006 17:26:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXm6P-0006CE-MG for mip6@ietf.org; Sun, 23 Apr 2006 17:26:45 -0400 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXm6P-0002Cw-90 for mip6@ietf.org; Sun, 23 Apr 2006 17:26:45 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.10.03) with ESMTP id k3NLQYQe003065; Sun, 23 Apr 2006 23:26:34 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [192.44.77.29]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.09.01) with ESMTP id k3NLQVwD003061; Sun, 23 Apr 2006 23:26:31 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id k3NLQUF4095126; Sun, 23 Apr 2006 23:26:30 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200604232126.k3NLQUF4095126@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Soliman, Hesham" Subject: Re: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt In-reply-to: Your message of Sun, 23 Apr 2006 11:25:51 PDT. <1487A357FD2ED544B8AD29E528FF9DF0023DCD02@NAEX06.na.qualcomm.com> Date: Sun, 23 Apr 2006 23:26:30 +0200 X-Virus-Scanned: amavisd-new at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Gopal Dommety , mip6@ietf.org, jari.arkko@ericsson.com, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org In your previous mail you wrote: > => IMHO the real argument is privacy even the tunnel all mode is > simpler from an IPsec point of view. => If the idea is to hide the HoA then we should devise a solution for this in a seperate doc, this is a completely separate topic. As you might remember, Claude had an idea for generating a random HoA a few years ago. => as one of the authors of the I-D I really remember (:-). But the issue is a bit different here because between the MN and the HA the HoA is visible only in BU/BA. This has some advantages (i.e., it was not designed by accident) but doesn't fit well with privacy. A privacy draft would be fine, but we certainly haven't discussed/agreed on the privacy space. So we shouldn't be putting a solution when others were proposed earlier. => the tunnel all idea is not new so your argument is more procedural than technical. > => as I explained the complexity was already there. => The complexity was *added* in 3776 unnecessarily. => I disagree, the complexity is from the struture of IPsec policies and was not added in 3776. To put some MUST to remove all freedom would give complete compatibility for an empty set of implementations... If we want to reopen this area then we should go back to using transport mode with the HAO => I don't understand how the transport mode can be used between the MN and CNs in all cases. Can you explain your idea? and remove all this complexity of requiring MIP6-IPsec interactions which took people years to support! => the way to support them has been known since some years so the issue is not there. I never saw a good reason for this troublesome design. => which design? > I see no reason for using tunnel mode between two end nodes. > > => here it is to make no difference between MN-CN and MN-HA. => I don't understand this statement or the one below. => the traffic terminating at the HA or going through the HA are dealt the same way. Regards Francis.Dupont@point6.net _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Apr 23 17:42:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXmL9-0003Mr-On; Sun, 23 Apr 2006 17:41:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXmL8-0003Mm-Vo for mip6@ietf.org; Sun, 23 Apr 2006 17:41:58 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXmL8-000321-KZ for mip6@ietf.org; Sun, 23 Apr 2006 17:41:58 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3NLfoAC014457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 23 Apr 2006 14:41:51 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3NLfnPl023225; Sun, 23 Apr 2006 14:41:50 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 23 Apr 2006 14:41:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt Date: Sun, 23 Apr 2006 14:41:41 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF0023DCD1A@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt Thread-Index: AcZnHK24WD9z3ZJLQ92ZXqNKG+SnCgAANzoA From: "Soliman, Hesham" To: X-OriginalArrivalTime: 23 Apr 2006 21:41:49.0629 (UTC) FILETIME=[BA24C6D0:01C6671E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: Gopal Dommety , mip6@ietf.org, jari.arkko@ericsson.com, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > =3D> If the idea is to hide the HoA then we should devise a = solution > for this in a seperate doc, this is a completely separate=20 > topic. As=20 > you might remember, Claude had an idea for generating a random HoA > a few years ago. >=20 > =3D> as one of the authors of the I-D I really remember (:-). But the > issue is a bit different here because between the MN and the=20 > HA the HoA > is visible only in BU/BA. This has some advantages (i.e., it was not > designed by accident) but doesn't fit well with privacy. =3D> The whole point of the draft I'm referring to was to create a = pseudo HoA to be included after the first BU. So the issue is not any different from the one attempted in this draft. Having this discussion shows that we don't even agree on a privacy solution yet, so why shove it into this draft?? >=20 > A privacy draft would be fine, but we certainly haven't > discussed/agreed on the privacy space. So we shouldn't be=20 > putting a > solution when others were proposed earlier.=20 > =20 > =3D> the tunnel all idea is not new so your argument is more = procedural > than technical. =3D> No it's not, I've already mentioned several technical reasons for this. And yes there is a procedural reason, but that's not the only one.=20 >=20 > > =3D> as I explained the complexity was already there. > =20 > =3D> The complexity was *added* in 3776 unnecessarily. >=20 > =3D> I disagree, the complexity is from the struture of IPsec = policies > and was not added in 3776. To put some MUST to remove all freedom > would give complete compatibility for an empty set of=20 > implementations... =3D> I'm talking about removing the HAO option for tunneled traffic to the HA and using tunnel mode. Of course this was added in 3776.=20 > If we want=20 > to reopen this area then we should go back to using transport > mode with the HAO >=20 > =3D> I don't understand how the transport mode can be used between > the MN and CNs in all cases. Can you explain your idea? =3D> Where did I claim that we should use transport mode to the CN?=20 I've been talking about the BU in every email...This *is* what the new section 3 in the draft modifies.=20 Transport mode is used for the BU now and MPD now. It can also be used=20 for all tunneled traffic to the HA (to protect payload traffic) if we use the HAO.=20 >=20 > and remove all this complexity of requiring=20 > MIP6-IPsec interactions which took people years to support!=20 >=20 > =3D> the way to support them has been known since some years so > the issue is not there. =3D> Know !=3D supported in implementations. Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Apr 23 18:07:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXmjp-0003zT-SR; Sun, 23 Apr 2006 18:07:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXmjo-0003zO-TB for mip6@ietf.org; Sun, 23 Apr 2006 18:07:28 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXmjn-0004Hv-KB for mip6@ietf.org; Sun, 23 Apr 2006 18:07:28 -0400 Received: from [10.1.210.8] ([10.1.210.8]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 23 Apr 2006 15:07:25 -0700 Message-ID: <444BFA98.4080303@azairenet.com> Date: Sun, 23 Apr 2006 15:07:20 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt References: <1487A357FD2ED544B8AD29E528FF9DF0023DCC8F@NAEX06.na.qualcomm.com> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF0023DCC8F@NAEX06.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Apr 2006 22:07:25.0176 (UTC) FILETIME=[4D66A780:01C66722] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Francis.Dupont@point6.net, Gopal Dommety , Basavaraj Patil , jari.arkko@ericsson.com, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Soliman, Hesham wrote: > > > > => I agree but the problem is the 3775bis will not be available soon, > > so following the advice of the area director the chairs decided to > > include this in the IKEv2 document. > > => I know you're trying to do the right thing, but this is not > how WG documents should be handled. Big changes like this must be > discussed on the list before they can be added to the doc. the changes were proposed on the list before they were added to the draft.... I guess you missed that email. Vijay > > Hesham > > > In exchange I asked and got > > this WGLC about this specific point, so persons (as you) who don't > > agree can explain why. > > > > Regards > > > > Francis.Dupont@point6.net > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Apr 23 18:09:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXmlt-0004TO-Vl; Sun, 23 Apr 2006 18:09:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXmlt-0004TJ-1r for mip6@ietf.org; Sun, 23 Apr 2006 18:09:37 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXmls-0004JU-PX for mip6@ietf.org; Sun, 23 Apr 2006 18:09:37 -0400 Received: from [10.1.210.8] ([10.1.210.8]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 23 Apr 2006 15:09:34 -0700 Message-ID: <444BFB1D.3020809@azairenet.com> Date: Sun, 23 Apr 2006 15:09:33 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt References: <1487A357FD2ED544B8AD29E528FF9DF0023DCC8E@NAEX06.na.qualcomm.com> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF0023DCC8E@NAEX06.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Apr 2006 22:09:34.0893 (UTC) FILETIME=[9AB7E5D0:01C66722] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Francis.Dupont@point6.net, Gopal Dommety , Basavaraj Patil , jari.arkko@ericsson.com, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Soliman, Hesham wrote: > > > Finally, this draft should not be inventing new packet formats for > > MIPv6. > > The purpose is to make sure that IKEv2/new IPsec specs can work > > with mipv6, not to introduce new features that we could > > have done with > > the old specs anyway but chose not to. > > > > => I agree but the problem is the 3775bis will not be available soon, > > so following the advice of the area director the chairs decided to > > include this in the IKEv2 document. In exchange I asked and got > > this WGLC about this specific point, so persons (as you) who don't > > agree can explain why. > > => I agree this is a discussion we should have and involve more > than 3 people. My reasons were mentioned in another email, I'm copying > it here: > > > its useful when you want to setup only one > > tunnel IPsec SA with the home agent for sending > > and receiving BU/BAck, MPS/MPA and HoTi/HoT. > > => I don't think it's a tradeoff that is worth the trouble. > You get an additional header, more complexity in the implementation, it only simplifies things by having to deal with only one tunnel SA. > more trouble classifying packets in the access, potential > interoperability > problems ... there should no interop issues. perhaps you should elaborate. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Apr 23 18:11:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXmo2-0005pb-Il; Sun, 23 Apr 2006 18:11:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXmo1-0005o8-U4 for mip6@ietf.org; Sun, 23 Apr 2006 18:11:49 -0400 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXmo1-0004NK-HJ for mip6@ietf.org; Sun, 23 Apr 2006 18:11:49 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.10.03) with ESMTP id k3NMBhpI005570; Mon, 24 Apr 2006 00:11:43 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [192.44.77.29]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.09.01) with ESMTP id k3NMBfoS005562; Mon, 24 Apr 2006 00:11:41 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id k3NMBfk4095280; Mon, 24 Apr 2006 00:11:41 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200604232211.k3NMBfk4095280@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Soliman, Hesham" Subject: Re: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt In-reply-to: Your message of Sun, 23 Apr 2006 14:41:41 PDT. <1487A357FD2ED544B8AD29E528FF9DF0023DCD1A@NAEX06.na.qualcomm.com> Date: Mon, 24 Apr 2006 00:11:41 +0200 X-Virus-Scanned: amavisd-new at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Gopal Dommety , mip6@ietf.org, jari.arkko@ericsson.com, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org In your previous mail you wrote: => I'm talking about removing the HAO option for tunneled traffic to the HA and using tunnel mode. Of course this was added in 3776. => the transport mode is end to end, so it can't be used from the MN to the CN using the HA both as a router and the end of the SAs. => Where did I claim that we should use transport mode to the CN? => you didn't explain your idea. I've been talking about the BU in every email...This *is* what the new section 3 in the draft modifies. Transport mode is used for the BU now and MPD now. It can also be used for all tunneled traffic to the HA (to protect payload traffic) if we use the HAO. => you want to use a transport mode with a HAO for the tunneled traffic, i.e.: IPv6 header (src=CoA, dst=HA) HAO (with HoA) ESP header IPv6 header (src=HoA, dst=*) Payload Is your proposal? > => the way to support them has been known since some years so > the issue is not there. => Know != supported in implementations. => yes but in this case the issue is not technical. Regards Francis.Dupont@point6.net _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Apr 23 18:18:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXmuI-0007lc-SB; Sun, 23 Apr 2006 18:18:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXmuH-0007lX-Vn for mip6@ietf.org; Sun, 23 Apr 2006 18:18:17 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXmuH-0004UW-Mf for mip6@ietf.org; Sun, 23 Apr 2006 18:18:17 -0400 Received: from [10.1.210.8] ([10.1.210.8]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 23 Apr 2006 15:18:16 -0700 Message-ID: <444BFD27.9060606@azairenet.com> Date: Sun, 23 Apr 2006 15:18:15 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt References: <1487A357FD2ED544B8AD29E528FF9DF0023DCD1A@NAEX06.na.qualcomm.com> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF0023DCD1A@NAEX06.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Apr 2006 22:18:16.0418 (UTC) FILETIME=[D1924C20:01C66723] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Francis.Dupont@point6.net, Gopal Dommety , Basavaraj Patil , jari.arkko@ericsson.com, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Soliman, Hesham wrote: > > > => If the idea is to hide the HoA then we should devise a solution > > for this in a seperate doc, this is a completely separate > > topic. As > > you might remember, Claude had an idea for generating a random HoA > > a few years ago. > > > > => as one of the authors of the I-D I really remember (:-). But the > > issue is a bit different here because between the MN and the > > HA the HoA > > is visible only in BU/BA. This has some advantages (i.e., it was not > > designed by accident) but doesn't fit well with privacy. > > => The whole point of the draft I'm referring to was to create a pseudo > HoA to be included after the first BU. So the issue is not any different > from the one attempted in this draft. Having this discussion shows that > we don't even agree on a privacy solution yet, so why shove it into > this draft?? Hesham, you are mixing up things. you should look up the discussion on the mobopts WG. it is working on a solution for generating temporary HoAs and use them instead of the actual HoA. but this requires some support on the CN too. the CN needs to know how to deal with the temporary HoA. the "tunnel all" mode is used to hide the HoA from the access network. this requires no support on the CN. the "tunnel all" mode is already there. it is *not* a new solution. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Apr 23 18:25:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXn0n-0001k4-LA; Sun, 23 Apr 2006 18:25:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXn0m-0001jy-8f for mip6@ietf.org; Sun, 23 Apr 2006 18:25:00 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXn0k-0004iT-Sq for mip6@ietf.org; Sun, 23 Apr 2006 18:25:00 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3NMOmjH024504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 23 Apr 2006 15:24:48 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3NMOlCq018392; Sun, 23 Apr 2006 15:24:48 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 23 Apr 2006 15:24:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt Date: Sun, 23 Apr 2006 15:24:42 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF0023DCD1E@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt Thread-Index: AcZnI9ZnJ5i9Zoj7QYuYom/bYdVtBwAAILwg From: "Soliman, Hesham" To: "Vijay Devarapalli" X-OriginalArrivalTime: 23 Apr 2006 22:24:47.0788 (UTC) FILETIME=[BAD89EC0:01C66724] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Francis.Dupont@point6.net, Gopal Dommety , Basavaraj Patil , jari.arkko@ericsson.com, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > you are mixing up things. you should look up the > discussion on the mobopts WG. it is working on > a solution for generating temporary HoAs and use > them instead of the actual HoA. but this requires > some support on the CN too. the CN needs to know > how to deal with the temporary HoA. >=20 > the "tunnel all" mode is used to hide the HoA > from the access network. this requires no support > on the CN. the "tunnel all" mode is already there. > it is *not* a new solution. =3D> I think you're confusing two separate issues: - BU sent to the HA - BU sent to the CN The draft in the subject of this email deals with the=20 former, there is *no* CN involvement here. If you want to create a pseudo HoA between the MN and HA you can=20 do that without involving the CN. You only involve the=20 CN when you're sending the BU *to* the CN. So you can't claim that the proposed section 3 goes around the problem of involving the CN, if that's what you're claiming.=20 Hesham >=20 > Vijay >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Apr 23 18:31:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXn7G-00048W-Fg; Sun, 23 Apr 2006 18:31:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXn7F-00047w-FO for mip6@ietf.org; Sun, 23 Apr 2006 18:31:41 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXn7F-00052I-4Z for mip6@ietf.org; Sun, 23 Apr 2006 18:31:41 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3NMVbm0017142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 23 Apr 2006 15:31:38 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3NMVbpx023710; Sun, 23 Apr 2006 15:31:37 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 23 Apr 2006 15:31:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt Date: Sun, 23 Apr 2006 15:31:34 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF0023DCD1F@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt Thread-Index: AcZnIvHn6zIgtTBuTxujBsjS6HL45AAAfT9g From: "Soliman, Hesham" To: X-OriginalArrivalTime: 23 Apr 2006 22:31:36.0875 (UTC) FILETIME=[AEAE57B0:01C66725] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: Gopal Dommety , mip6@ietf.org, jari.arkko@ericsson.com, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > =3D> I'm talking about removing the HAO option for tunneled=20 > traffic to > the HA and using tunnel mode. Of course this was added in 3776.=20 > =20 > =3D> the transport mode is end to end, so it can't be used from the > MN to the CN using the HA both as a router and the end of the SAs. =3D> Yes I know, again, I didn't say it should be used with the CN.=20 >=20 > =3D> Where did I claim that we should use transport mode to the = CN?=20 >=20 > =3D> you didn't explain your idea. >=20 > I've been talking about the BU in every email...This *is*=20 > what the new > section 3 in the draft modifies.=20 > Transport mode is used for the BU now and MPD now. It can=20 > also be used=20 > for all tunneled traffic to the HA (to protect payload=20 > traffic) if we > use the HAO. >=20 > =3D> you want to use a transport mode with a HAO for the=20 > tunneled traffic, > i.e.: > IPv6 header (src=3DCoA, dst=3DHA) > HAO (with HoA) > ESP header > IPv6 header (src=3DHoA, dst=3D*) > Payload > Is your proposal? =3D> My poroposal two fold:=20 A. Remove the current section 3 and replace it with the one in the previous=20 version. I.e. do not propose a new format for the BU.=20 B. For protecting payload traffic (VPN style) we can do the packet format you describe above.=20 > =3D> Know !=3D supported in implementations. > =20 > =3D> yes but in this case the issue is not technical. =3D> Oh come on. If you're going to mandate that we do something=20 extra (MIP6-IPsec API, K flag ...etc) when there is an easier way of=20 doing it that doesn't require these changes (the format above) you need to motivate it. Of course that's technical. Hesham > =20 > Regards >=20 > Francis.Dupont@point6.net >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Apr 23 18:36:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXnCE-0006Uf-Sq; Sun, 23 Apr 2006 18:36:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXnCE-0006Ua-EK for mip6@ietf.org; Sun, 23 Apr 2006 18:36:50 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXnCE-0005EU-58 for mip6@ietf.org; Sun, 23 Apr 2006 18:36:50 -0400 Received: from [10.1.210.8] ([10.1.210.8]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 23 Apr 2006 15:36:49 -0700 Message-ID: <444C0180.90703@azairenet.com> Date: Sun, 23 Apr 2006 15:36:48 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt References: <1487A357FD2ED544B8AD29E528FF9DF0023DCD1E@NAEX06.na.qualcomm.com> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF0023DCD1E@NAEX06.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Apr 2006 22:36:49.0153 (UTC) FILETIME=[68D02F10:01C66726] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Francis.Dupont@point6.net, Gopal Dommety , Basavaraj Patil , jari.arkko@ericsson.com, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Soliman, Hesham wrote: > > > you are mixing up things. you should look up the > > discussion on the mobopts WG. it is working on > > a solution for generating temporary HoAs and use > > them instead of the actual HoA. but this requires > > some support on the CN too. the CN needs to know > > how to deal with the temporary HoA. > > > > the "tunnel all" mode is used to hide the HoA > > from the access network. this requires no support > > on the CN. the "tunnel all" mode is already there. > > it is *not* a new solution. > > => I think you're confusing two separate issues: ofcourse not. > - BU sent to the HA > - BU sent to the CN > > The draft in the subject of this email deals with the > former, there is *no* CN involvement here. for using temporary HoA instead of actual HoA in payload traffic, there is a need to modify the CN. If you want > to create a pseudo HoA between the MN and HA you can > do that without involving the CN. why would I? if I am sending a BU to the HA and do not want the access network to see the HoA, I just tunnel it and put ESP with non-null encryption between the two IP headers. simple. no pseudo HoA stuff. > You only involve the > CN when you're sending the BU *to* the CN. yes. the privacy solutions are trying to address route optimization too. > So you can't > claim that the proposed section 3 goes around the problem > of involving the CN, if that's what you're claiming. the claim is simple. I can hide the HoA from the access network *without* requiring the HA or the CN to support the use of pseudo HoA by tunneling everything. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Apr 23 18:42:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXnHL-0008HZ-20; Sun, 23 Apr 2006 18:42:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXnHJ-0008HU-Gj for mip6@ietf.org; Sun, 23 Apr 2006 18:42:05 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXnHI-0005bA-5s for mip6@ietf.org; Sun, 23 Apr 2006 18:42:05 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3NMfwUq017628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 23 Apr 2006 15:41:59 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3NMfwgO020889; Sun, 23 Apr 2006 15:41:58 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 23 Apr 2006 15:41:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt Date: Sun, 23 Apr 2006 15:41:52 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF0023DCD21@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt Thread-Index: AcZnJm2QFur4ZxP5SR6hswcnWgiPmAAABisw From: "Soliman, Hesham" To: "Vijay Devarapalli" X-OriginalArrivalTime: 23 Apr 2006 22:41:57.0950 (UTC) FILETIME=[20DEDDE0:01C66727] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Francis.Dupont@point6.net, Gopal Dommety , Basavaraj Patil , jari.arkko@ericsson.com, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > > - BU sent to the HA > > - BU sent to the CN > >=20 > > The draft in the subject of this email deals with the=20 > > former, there is *no* CN involvement here.=20 >=20 > for using temporary HoA instead of actual HoA in > payload traffic, there is a need to modify the CN. =3D> This is an issue you created, that's not the issue I'm raising. In this draft the only thing you're doing is hiding=20 the HoA in the BU from the access network. So if you want=20 to compare apples and apples one would have to say that you can do the same thing by using a pseudo HoA in the BU.=20 You're not hiding anything from the CN in this draft so I don't know why you're comparing it with another proposal that tries to hide the HoA from the CN. > If you want > > to create a pseudo HoA between the MN and HA you can=20 > > do that without involving the CN.=20 >=20 > why would I? if I am sending a BU to the HA and > do not want the access network to see the HoA, I > just tunnel it and put ESP with non-null > encryption between the two IP headers. simple. > no pseudo HoA stuff. =3D> That's you preferred solution, clearly, but it's not the only way to do it. If you want to discuss pros and cons for privacy then we can do that, but we can't be forced to use this solution for privacy when there are others, and it's out of scope of this draft. Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Apr 23 18:44:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXnJr-0000bI-0N; Sun, 23 Apr 2006 18:44:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXnJq-0000Yd-Ak for mip6@ietf.org; Sun, 23 Apr 2006 18:44:42 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXnJq-0005fv-1p for mip6@ietf.org; Sun, 23 Apr 2006 18:44:42 -0400 Received: from [10.1.210.8] ([10.1.210.8]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 23 Apr 2006 15:44:40 -0700 Message-ID: <444C0358.9010103@azairenet.com> Date: Sun, 23 Apr 2006 15:44:40 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt References: <1487A357FD2ED544B8AD29E528FF9DF0023DCD21@NAEX06.na.qualcomm.com> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF0023DCD21@NAEX06.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Apr 2006 22:44:40.0741 (UTC) FILETIME=[81E6CD50:01C66727] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Francis.Dupont@point6.net, Gopal Dommety , Basavaraj Patil , jari.arkko@ericsson.com, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Soliman, Hesham wrote: > > > > - BU sent to the HA > > > - BU sent to the CN > > > > > > The draft in the subject of this email deals with the > > > former, there is *no* CN involvement here. > > > > for using temporary HoA instead of actual HoA in > > payload traffic, there is a need to modify the CN. > > => This is an issue you created, that's not the issue I'm > raising. In this draft the only thing you're doing is hiding > the HoA in the BU from the access network. So if you want > to compare apples and apples one would have to say that > you can do the same thing by using a pseudo HoA in the BU. that requires additional specification. > You're not hiding anything from the CN in this draft so I don't > know why you're comparing it with another proposal that tries > to hide the HoA from the CN. duh? both solutions are complementary in case you weren't following the discussion. > > > If you want > > > to create a pseudo HoA between the MN and HA you can > > > do that without involving the CN. > > > > why would I? if I am sending a BU to the HA and > > do not want the access network to see the HoA, I > > just tunnel it and put ESP with non-null > > encryption between the two IP headers. simple. > > no pseudo HoA stuff. > > => That's you preferred solution, clearly, but it's not > the only way to do it. If you want to discuss pros and cons > for privacy then we can do that, but we can't be forced to > use this solution for privacy when there are others, and it's > out of scope of this draft. sure. nobody is forcing anything. its an optional feature. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Apr 23 18:50:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXnPW-0002pO-Qn; Sun, 23 Apr 2006 18:50:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXnPV-0002pJ-O2 for mip6@ietf.org; Sun, 23 Apr 2006 18:50:33 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXnPV-0005xA-Cb for mip6@ietf.org; Sun, 23 Apr 2006 18:50:33 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3NMoPBC018086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 23 Apr 2006 15:50:26 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3NMoPd4026415; Sun, 23 Apr 2006 15:50:25 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 23 Apr 2006 15:50:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt Date: Sun, 23 Apr 2006 15:50:22 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF0023DCD23@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt Thread-Index: AcZnJ4Usts2UtZrpQhOnKUXRjiT6ZAAAEqGA From: "Soliman, Hesham" To: "Vijay Devarapalli" X-OriginalArrivalTime: 23 Apr 2006 22:50:24.0759 (UTC) FILETIME=[4EF3C870:01C66728] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Francis.Dupont@point6.net, Gopal Dommety , Basavaraj Patil , jari.arkko@ericsson.com, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > > =3D> This is an issue you created, that's not the issue I'm > > raising. In this draft the only thing you're doing is hiding=20 > > the HoA in the BU from the access network. So if you want=20 > > to compare apples and apples one would have to say that > > you can do the same thing by using a pseudo HoA in the BU.=20 >=20 > that requires additional specification. =3D> So what? >=20 > > You're not hiding anything from the CN in this draft so I don't > > know why you're comparing it with another proposal that tries > > to hide the HoA from the CN. >=20 > duh?=20 =3D> Careful with your language. > > =3D> That's you preferred solution, clearly, but it's not > > the only way to do it. If you want to discuss pros and cons > > for privacy then we can do that, but we can't be forced to > > use this solution for privacy when there are others, and it's > > out of scope of this draft. >=20 > sure. nobody is forcing anything. its an optional > feature. =3D> We don't need this option. Options add more implementation effort that needs to be motivated. The motivation here is=20 weak IMO and the consequences not well understood. And as I said many times this is not the right place for this solution.=20 Hesham >=20 > Vijay >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Apr 23 18:53:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXnSA-0003wH-J2; Sun, 23 Apr 2006 18:53:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXnS9-0003wC-C4 for mip6@ietf.org; Sun, 23 Apr 2006 18:53:17 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXnS9-00067p-41 for mip6@ietf.org; Sun, 23 Apr 2006 18:53:17 -0400 Received: from [10.1.210.8] ([10.1.210.8]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 23 Apr 2006 15:53:15 -0700 Message-ID: <444C055A.7070203@azairenet.com> Date: Sun, 23 Apr 2006 15:53:14 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt References: <1487A357FD2ED544B8AD29E528FF9DF0023DCD23@NAEX06.na.qualcomm.com> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF0023DCD23@NAEX06.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Apr 2006 22:53:15.0328 (UTC) FILETIME=[B49E8C00:01C66728] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Francis.Dupont@point6.net, Gopal Dommety , Basavaraj Patil , jari.arkko@ericsson.com, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Soliman, Hesham wrote: > > > => That's you preferred solution, clearly, but it's not > > > the only way to do it. If you want to discuss pros and cons > > > for privacy then we can do that, but we can't be forced to > > > use this solution for privacy when there are others, and it's > > > out of scope of this draft. > > > > sure. nobody is forcing anything. its an optional > > feature. > > => We don't need this option. Options add more implementation > effort that needs to be motivated. nope. existing IPsec implementations already support creating transport mode and tunnel mode SAs. > The motivation here is > weak IMO and the consequences not well understood. And as I said > many times this is not the right place for this solution. as I said many times because, no new solution is being introduced. we are infact clarifying things. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Apr 23 18:57:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXnVh-0005QG-K0; Sun, 23 Apr 2006 18:56:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXnVg-0005QB-Ez for mip6@ietf.org; Sun, 23 Apr 2006 18:56:56 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXnVf-0006Gs-3M for mip6@ietf.org; Sun, 23 Apr 2006 18:56:56 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3NMuokO018292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 23 Apr 2006 15:56:50 -0700 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3NMunsQ023995; Sun, 23 Apr 2006 15:56:49 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 23 Apr 2006 15:56:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt Date: Sun, 23 Apr 2006 15:56:46 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF0023DCD24@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt Thread-Index: AcZnKLhegUBdJ9eCRciOMQ08pUGFcQAABnUg From: "Soliman, Hesham" To: "Vijay Devarapalli" X-OriginalArrivalTime: 23 Apr 2006 22:56:48.0881 (UTC) FILETIME=[33E82610:01C66729] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Francis.Dupont@point6.net, Gopal Dommety , Basavaraj Patil , jari.arkko@ericsson.com, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org =20 > > =3D> We don't need this option. Options add more implementation > > effort that needs to be motivated.=20 >=20 > nope. existing IPsec implementations already > support creating transport mode and tunnel > mode SAs. =3D> Of course they do. But existing MIP6 implementations need to be modified to support the new format for the BU. >=20 > > The motivation here is=20 > > weak IMO and the consequences not well understood. And as I said > > many times this is not the right place for this solution.=20 >=20 > as I said many times because, no new solution > is being introduced. we are infact clarifying > things. =3D> Disagree. If you want a new privacy solution then write a draft on it. The current draft doesn't clarify, it updates/adds a new BU format. Hesham >=20 > Vijay >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Apr 23 18:58:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXnXJ-0005qF-5X; Sun, 23 Apr 2006 18:58:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXnXH-0005qA-8h for mip6@ietf.org; Sun, 23 Apr 2006 18:58:35 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXnXG-0006Iq-0T for mip6@ietf.org; Sun, 23 Apr 2006 18:58:35 -0400 Received: from [10.1.210.8] ([10.1.210.8]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 23 Apr 2006 15:58:32 -0700 Message-ID: <444C0697.2030908@azairenet.com> Date: Sun, 23 Apr 2006 15:58:31 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt References: <1487A357FD2ED544B8AD29E528FF9DF0023DCD24@NAEX06.na.qualcomm.com> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF0023DCD24@NAEX06.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Apr 2006 22:58:32.0809 (UTC) FILETIME=[71DA4D90:01C66729] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Francis.Dupont@point6.net, Gopal Dommety , Basavaraj Patil , jari.arkko@ericsson.com, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Soliman, Hesham wrote: > > > The motivation here is > > > weak IMO and the consequences not well understood. And as I said > > > many times this is not the right place for this solution. > > > > as I said many times because, no new solution > > is being introduced. we are infact clarifying > > things. > > => Disagree. disagree with what? > If you want a new privacy solution then write a draft > on it. I am quite happy with the work being done in the mobopts WG. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 06:17:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXy87-00061g-Uz; Mon, 24 Apr 2006 06:17:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXy86-00061b-KM for mip6@ietf.org; Mon, 24 Apr 2006 06:17:18 -0400 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXy85-0002Su-7J for mip6@ietf.org; Mon, 24 Apr 2006 06:17:18 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id k3OAT4jM020709; Mon, 24 Apr 2006 03:29:04 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id k3OAUXj7019146; Mon, 24 Apr 2006 05:30:33 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id A61E4865980; Mon, 24 Apr 2006 12:17:10 +0200 (CEST) Message-ID: <444CA5A6.7060905@motorola.com> Date: Mon, 24 Apr 2006 12:17:10 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip6] Bootstrapping from the home link References: <44498CEA.4050803@azairenet.com> In-Reply-To: <44498CEA.4050803@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: mip6@ietf.org, James Kempf X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Vijay Devarapalli wrote: > hello, > > after some discussions offlist, we came up with some text that could > be added to draft-ietf-mip6-bootstrapping-split-02.txt to address > bootstrapping from the home link. the proposal is to have this in a > new section before the security considerations section. > > 9. Bootstrapping from the home link > > The mechanisms described in this document also support a mobile node > bootstrapping from the home link. When the mobile node is on the > home link it receives router advertisements from the home agent with > the 'H' bit set and the 128 bit address of the home agent in the > modified prefix information option [RFC3775]. When the mobile node > bootstraps, the first operation it does is to perform a DNS lookup > for the home agent. Can MN do DNS lookup before having an Address? I guess no. So I doubt the first operation it does is to perform a DNS loookup for the HA. I think the first operation it does is to auto-configure an address. Also, in order to perform DNS lookup, would the MN need to have an SA developed with the DNS Server first? > If at least one of the home agent address received in the DNS reply Isn't that a "DNS Response" or "answer" but not "reply"? > matches the address the mobile node received in the router > advertisement from the home agent, then the mobile node assumes it is > attached to the home link. > > For configuring a home address, the mobile node can either auto- > configure a home address, use DHCPv6 or run IKEv2 with its home agent > as described in section 5.3. Would MN auto-configure a Address first or decide first whether it is at home or not (and do DNS)? Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 06:25:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXyFp-0003np-7K; Mon, 24 Apr 2006 06:25:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXyFn-0003nf-IX for mip6@ietf.org; Mon, 24 Apr 2006 06:25:15 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXyFm-0002rh-7R for mip6@ietf.org; Mon, 24 Apr 2006 06:25:15 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id k3OAlKe9020479; Mon, 24 Apr 2006 03:47:20 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id k3OAlL0R019779; Mon, 24 Apr 2006 05:47:22 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 146D2865980; Mon, 24 Apr 2006 12:25:07 +0200 (CEST) Message-ID: <444CA782.10300@motorola.com> Date: Mon, 24 Apr 2006 12:25:06 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip6] Bootstrapping on the home link References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Vijay Devarapalli wrote: >> MN powers up on the home link. It has no means of knowing it is on the >> home link. Hence, it configures an IP address that it thinks is a CoA >> (say, statelessly). It then goes about doing IKEv2 and trying to get a >> home address, at which point, it realizes that the home prefix is the >> same as the prefix on which it just got an IP address. > > before that the MN should get a router advertisement > from the HA with the H bit set and the 128 bit address > of the HA in the prefix information option. if this > address matches the HA's IP address the MN gets by DNS > lookup, then the MN realizes it is at home. I do not agree to involve DNS querying in the decision of being at home or not. "Home" link is the realm of proxy ND and MIP, not DNS. For this reason, the straightforward way to have a decision capability about being at home is to pre-configure the home prefix on the mobile, and compare it to the one in the received RA. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 06:30:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXyKc-0005d5-T6; Mon, 24 Apr 2006 06:30:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXyKb-0005d0-6U for mip6@ietf.org; Mon, 24 Apr 2006 06:30:13 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXyKa-000340-V7 for mip6@ietf.org; Mon, 24 Apr 2006 06:30:13 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3OAksOp014305; Mon, 24 Apr 2006 03:46:54 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k3OAlTu0016164; Mon, 24 Apr 2006 05:47:30 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 75A86865980; Mon, 24 Apr 2006 12:30:08 +0200 (CEST) Message-ID: <444CA8B0.9030706@motorola.com> Date: Mon, 24 Apr 2006 12:30:08 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip6] Bootstrapping on the home link References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Vijay Devarapalli wrote: > > >> -----Original Message----- From: Narayanan, Vidya >> [mailto:vidyan@qualcomm.com] Sent: Thursday, April 13, 2006 12:14 >> PM To: Vijay Devarapalli; Giaretta Gerardo Cc: mip6@ietf.org >> Subject: RE: [Mip6] Bootstrapping on the home link >> >> Vijay, The bootstrapping documents specify some MUSTs for MIP6 >> bootstrapping and also specify recommended behavior of DNS or IKEv2 >> as applicable for MIP6. If we go by the same argument that we can >> "configure the MN to set up an SA as soon as it gets an HA >> assigned", then, there are other parts of the document that should >> receive similar treatment. For instance, going by your argument, >> what value does the following statements in section 9.5 of >> draft-ietf-mip6-bootstrapping-split add - >> >> "A security association is required even if the DNS server is in >> the same administrative domain as the Home Agent. The security >> association SHOULD be separate from the security associations used >> for other purposes, such as AAA." >> >> One can claim that HA can be configured to say that the SA with the >> DNS server is a separate one. But, the statement is there because >> we believe it is good recommended behavior and hence, should really >> be part of the implementation and not a configuration. > > in this case a MUST is required because it would be a bad idea for > the HA to perform a DNS update without authenticating itself to the > DNS server. otherwise any malicious node in the home network or a > mobile node through the tunnel to its HA can send a DNS update on > behalf of another mobile node. therefore the 'MUST' is required for > securing the DNS update between the HA and the DNS server. it is not > a configuration issue on the HA in this case. Not only DNS update, but simple querying too should be secured. It would be bad for MN to be able to do a DNS querying without authenticating it first, because in this way some rogue DNS server can bootstrap the mobile into some rogue HA. In which case, the DNS server and the mobile should authenticate to each other first. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 09:22:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY11U-0004nH-GX; Mon, 24 Apr 2006 09:22:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY11T-0004kq-EI for mip6@ietf.org; Mon, 24 Apr 2006 09:22:39 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY11T-0003rU-2b for mip6@ietf.org; Mon, 24 Apr 2006 09:22:39 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3ODdMhV010379 for ; Mon, 24 Apr 2006 06:39:22 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k3ODdw1d025225 for ; Mon, 24 Apr 2006 08:39:59 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id E02ED8637E6 for ; Mon, 24 Apr 2006 15:22:36 +0200 (CEST) Message-ID: <444CD11C.2050807@motorola.com> Date: Mon, 24 Apr 2006 15:22:36 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: mip6@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Subject: [Mip6] Comments while reading draft-ietf-mip6-bootstrapping-split-02.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Dear authors of draft-ietf-mip6-bootstrapping-split-02.txt, I have read the draft and I have several comments. > Mobile IPv6 [2] requires the Mobile Node to know its Home Agent > Address, its own Home Address and the cryptographic materials (e.g. > shared keys or certificates) needed to set up IPsec security > associations with the Home Agent in order to protect Mobile IPv6 > signaling. This is generally referred to as the Mobile IPv6 > bootstrapping problem [4]. [...] Mobile IPv6 base protocol does not > specify any method to automatically acquire this information, That is wrong from many respects. The first and foremost is with respect to the HA address. rfc3775 does specify how to automatically acquire the HA address - DHAAD. With respect to the Home Address, although rfc3775 does not specify how MN could derive its Home Address, it still describes MPD (Mobile Prefix Discovery) and the MPA (Advertisement) could be used by MN to derive its Home Address by simple stateless auto-configuration. With respect to the crypto material, the certificates more specifically. Neither Mobile IPv6 nor any other method I'm aware off will allow MN to "automatically" acquire a cert. To acquire a cert one must prove its/his/her identity with an out-of-band method, non-automatisable. So stating that the bootstrapping problem lies in the fact that Mobile IPv6 can't distribute certs makes one think that a solution to that problem may be this draft which will help to distribute certs. It doesn't. > which means that network administrators are normally required to > manually set configuration data on Mobile Nodes and HAs. However, in > real deployments, manual configuration does not scale as the Mobile > Nodes increase in number. This leaves the reader the impression that while by RFC3775 the admins will need to manually configure data on MN, this spec would require no such pre-configuration, thus apparently more scalable. The first part is plain wrong. This spec does require the pre-configuration of something: the HA FQDN. Should be acknowledged here, not deep in the document. The second part (the one that gives the impression that pre-configuring data on MN is not scaling with the number of MNs) suddenly becomes a non-supportive argument for this draft. Because if pre-configuring data on MN is not scalable then pre-configuring the FQDN is not scalable either. Moreover, this spec requires additional data to be pre-configured on the MN, not just the domain name. It's the certificates. They must be pre-configured on MN in order to somehow avoid the fallacies of the still insecure HA Discovery phase (as opposed to the insecure DHAAD). (There is no automatic way to securely distribute certificates to MNs, so this must be a pre-configuration too.) > o HA address discovery. The Mobile Node needs to discover the > address of its Home Agent. The main objective of a bootstrapping > solution is to minimize the data pre-configured on the Mobile Node. Ok, so the objective is to minimize the data pre-configured on the MN. > For this reason, the DHAAD defined in [2] may not be applicable in > real deployments since it is required that the Mobile Node is > pre-configured with the home network prefix Ok, so pre-configuring the home network prefix on the MN is not minimal. > and it does not allow an operator to load balance by having Mobile > Nodes dynamically assigned to Home Agents located in different > subnets. But was load balancing an objective? The objective was to minimize pre-configured data, not to offer load balancing capability. > This document defines a solution for Home Agent address discovery > that is based on Domain Name Service (DNS), introducing a new DNS SRV > record [5]. The unique information that needs to be pre-configured > on the Mobile Node is the domain name of the MSP. So there is a need to pre-configure data on the MN, except that this time we pre-configure the domain name instead of the home prefix. Is pre-configuring the domain name more minimal than pre-configuring the home prefix? I don't think we can talk in absolute terms here. In terms of memory required, a prefix can take maximum 39 ASCII characters while a domain name may take any length ("domain" in domain.com can have up to 255 characters). So apparently pre-configuring a prefix could be shorter than pre-configuring a domain name. > An optional part of bootstrapping involves providing a way for the > Mobile Node to have its FQDN updated in the DNS with a dynamically > assigned home address. More correct language would be to update the IN Resource Record corresponding to its permanent FQDN. Because "updating the FQDN with something" may be read as changing the FQDN. It doesn't change normally. > The Mobile Node needs to obtain the IP address of the DNS server > before it can send a DNS request. This can be pre-configured on the > Mobile Node or obtained through DHCPv6 from the visited link [11]. "DNS server pre-configured on the MN"? More data pre-configured? Remark this would come in addition to the domain name pre-configured on the MN. But I do agree the DNS server address could come from the local DHCP server. > In this case, the Mobile Node is configured with the Fully Qualified > Domain Name of the Home Agent. As an example, the Mobile Node could > be configured with the name "ha1.example.com", where "example.com" is > the domain name of the MSP granting the mobility service. I find this method relatively more flexible than the method SRV RR, because it allows a specific HA to be associated to a specific subnet in example.com (the SRV method doesn't). However, it's still data to be pre-configured on the MN, just like the home prefix. > The service name for Mobile IPv6 Home Agent service as required by > RFC 2782 is "mip6" and the protocol name is "ipv6". Note that a > transport name cannot be used here because Mobile IPv6 does not run > over a transport protocol. Would this require modifications to rfc2782 to explain that the Port number in a SRV RR be optional? The second question is: do we need IANA action for being able to use the service name in SRV "mip6" ? Because the IANA Considerations section doesn't seem to mention it. > The SRV RR has a DNS type code of 33. As an example, the Mobile > constructs a request with QNAME set to "_mip6._ipv6.example.com" and > QTYPE to SRV. Thus, for a given domain example.com only one HA will be sent back by DNS to MN. Presumably, in a domain there are several subnets, and various MNs have various subnets as their homes, all in the same domain. How would DNS resolve the right HA for the right MN when the only key used is "_mip6._ipv6"? Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 12:18:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY3lQ-00034g-E3; Mon, 24 Apr 2006 12:18:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY3lP-00034Y-5l for mip6@ietf.org; Mon, 24 Apr 2006 12:18:15 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY3lL-0004Ix-P4 for mip6@ietf.org; Mon, 24 Apr 2006 12:18:15 -0400 Message-ID: <017a01c667bb$63396950$026115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Alexandru Petrescu" , "Vijay Devarapalli" References: <44498CEA.4050803@azairenet.com> <444CA5A6.7060905@motorola.com> Subject: Re: [Mip6] Bootstrapping from the home link Date: Mon, 24 Apr 2006 09:23:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > Also, in order to perform DNS lookup, would the MN need to have an SA > developed with the DNS Server first? > I don't think the way DNS is typically used today is to require an IPsec SA with the DNS server in order to do lookup. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 12:19:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY3mU-0003RI-0j; Mon, 24 Apr 2006 12:19:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY3mS-0003RD-Ro for mip6@ietf.org; Mon, 24 Apr 2006 12:19:20 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY3mR-0004LW-FN for mip6@ietf.org; Mon, 24 Apr 2006 12:19:20 -0400 Message-ID: <018501c667bb$8c436490$026115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Alexandru Petrescu" , "Vijay Devarapalli" References: <444CA782.10300@motorola.com> Subject: Re: [Mip6] Bootstrapping on the home link Date: Mon, 24 Apr 2006 09:24:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Alex, Can you say why? jak ----- Original Message ----- From: "Alexandru Petrescu" To: "Vijay Devarapalli" Cc: Sent: Monday, April 24, 2006 3:25 AM Subject: Re: [Mip6] Bootstrapping on the home link > Vijay Devarapalli wrote: >>> MN powers up on the home link. It has no means of knowing it is on the >>> home link. Hence, it configures an IP address that it thinks is a CoA >>> (say, statelessly). It then goes about doing IKEv2 and trying to get a >>> home address, at which point, it realizes that the home prefix is the >>> same as the prefix on which it just got an IP address. >> >> before that the MN should get a router advertisement >> from the HA with the H bit set and the 128 bit address >> of the HA in the prefix information option. if this >> address matches the HA's IP address the MN gets by DNS >> lookup, then the MN realizes it is at home. > > I do not agree to involve DNS querying in the decision of being at home > or not. "Home" link is the realm of proxy ND and MIP, not DNS. > > For this reason, the straightforward way to have a decision capability > about being at home is to pre-configure the home prefix on the mobile, > and compare it to the one in the received RA. > > Alex > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 12:24:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY3rf-0005ig-Ly; Mon, 24 Apr 2006 12:24:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY3re-0005ib-B7 for mip6@ietf.org; Mon, 24 Apr 2006 12:24:42 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY3rc-0004cy-S7 for mip6@ietf.org; Mon, 24 Apr 2006 12:24:42 -0400 Message-ID: <018a01c667bc$49409680$026115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Alexandru Petrescu" , "Vijay Devarapalli" References: <444CA8B0.9030706@motorola.com> Subject: Re: [Mip6] Bootstrapping on the home link Date: Mon, 24 Apr 2006 09:29:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Alex, DNS has its own security mechanisms for security. See RFC 4033. Section 9.1 in the bootstrapping draft discusses the security considerations for DNS in bootstrapping. jak ----- Original Message ----- From: "Alexandru Petrescu" To: "Vijay Devarapalli" Cc: Sent: Monday, April 24, 2006 3:30 AM Subject: Re: [Mip6] Bootstrapping on the home link > Vijay Devarapalli wrote: >> >> >>> -----Original Message----- From: Narayanan, Vidya >>> [mailto:vidyan@qualcomm.com] Sent: Thursday, April 13, 2006 12:14 >>> PM To: Vijay Devarapalli; Giaretta Gerardo Cc: mip6@ietf.org Subject: >>> RE: [Mip6] Bootstrapping on the home link >>> >>> Vijay, The bootstrapping documents specify some MUSTs for MIP6 >>> bootstrapping and also specify recommended behavior of DNS or IKEv2 >>> as applicable for MIP6. If we go by the same argument that we can >>> "configure the MN to set up an SA as soon as it gets an HA >>> assigned", then, there are other parts of the document that should >>> receive similar treatment. For instance, going by your argument, >>> what value does the following statements in section 9.5 of >>> draft-ietf-mip6-bootstrapping-split add - >>> >>> "A security association is required even if the DNS server is in >>> the same administrative domain as the Home Agent. The security >>> association SHOULD be separate from the security associations used >>> for other purposes, such as AAA." >>> >>> One can claim that HA can be configured to say that the SA with the >>> DNS server is a separate one. But, the statement is there because we >>> believe it is good recommended behavior and hence, should really >>> be part of the implementation and not a configuration. >> >> in this case a MUST is required because it would be a bad idea for >> the HA to perform a DNS update without authenticating itself to the >> DNS server. otherwise any malicious node in the home network or a >> mobile node through the tunnel to its HA can send a DNS update on >> behalf of another mobile node. therefore the 'MUST' is required for >> securing the DNS update between the HA and the DNS server. it is not >> a configuration issue on the HA in this case. > > Not only DNS update, but simple querying too should be secured. It > would be bad for MN to be able to do a DNS querying without > authenticating it first, because in this way some rogue DNS server can > bootstrap the mobile into some rogue HA. > > In which case, the DNS server and the mobile should authenticate to each > other first. > > Alex > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 12:37:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY43x-0001ie-1C; Mon, 24 Apr 2006 12:37:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY43w-0001iZ-1s for mip6@ietf.org; Mon, 24 Apr 2006 12:37:24 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY43u-00053W-QV for mip6@ietf.org; Mon, 24 Apr 2006 12:37:24 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3OGrTxi023088; Mon, 24 Apr 2006 09:53:30 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k3OGrdM1021120; Mon, 24 Apr 2006 11:53:39 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 4FCE3865980; Mon, 24 Apr 2006 18:36:44 +0200 (CEST) Message-ID: <444CFE9B.6030602@motorola.com> Date: Mon, 24 Apr 2006 18:36:43 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: James Kempf Subject: Re: [Mip6] Bootstrapping on the home link References: <444CA8B0.9030706@motorola.com> <018a01c667bc$49409680$026115ac@dcml.docomolabsusa.com> In-Reply-To: <018a01c667bc$49409680$026115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: mip6@ietf.org, Vijay Devarapalli X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org James Kempf wrote: > Alex, > > DNS has its own security mechanisms for security. Mechanisms and accepted limitations. So do you agree that HA discovery based on DNS (be it SRV or simple query) is not secure until MN queries the HA address in a secure manner? Do you also agree that to a certain extent this DNS querying can happen in a secure way (after IKE in visited domain), as well as in a non-secure way (w/o IKE in the visited domain)? > See RFC 4033. Section 9.1 in the bootstrapping draft discusses the > security considerations for DNS in bootstrapping. I read it. I'm left with the impression that DNS querying in the visited domain can't be guaranteed secure because all DNS Servers aren't known to be secure. Knowing this, do you agree that the entire argument claiming DHAAD is not good because it is insecure applies to DNS HA discovery as well? Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 12:38:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY44f-00023s-KW; Mon, 24 Apr 2006 12:38:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY44d-00023n-UY for mip6@ietf.org; Mon, 24 Apr 2006 12:38:07 -0400 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY44c-000543-KH for mip6@ietf.org; Mon, 24 Apr 2006 12:38:07 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id k3OGnJo2020398; Mon, 24 Apr 2006 09:49:20 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id k3OGooCw005632; Mon, 24 Apr 2006 11:50:51 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 8EE9C865980; Mon, 24 Apr 2006 18:37:27 +0200 (CEST) Message-ID: <444CFEC7.1080804@motorola.com> Date: Mon, 24 Apr 2006 18:37:27 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: James Kempf Subject: Re: [Mip6] Bootstrapping from the home link References: <44498CEA.4050803@azairenet.com> <444CA5A6.7060905@motorola.com> <017a01c667bb$63396950$026115ac@dcml.docomolabsusa.com> In-Reply-To: <017a01c667bb$63396950$026115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org James Kempf wrote: >> Also, in order to perform DNS lookup, would the MN need to have an SA >> developed with the DNS Server first? >> > > I don't think the way DNS is typically used today is to require an IPsec > SA with the DNS server in order to do lookup. Which renders HA discovery via DNS relatively insecure, no? Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 12:45:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY4Bx-0004lS-FE; Mon, 24 Apr 2006 12:45:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY4Bw-0004lN-64 for mip6@ietf.org; Mon, 24 Apr 2006 12:45:40 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY4Bv-0005Km-QO for mip6@ietf.org; Mon, 24 Apr 2006 12:45:40 -0400 Message-ID: <01c601c667bf$3a88dbe0$026115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Alexandru Petrescu" References: <444CA8B0.9030706@motorola.com> <018a01c667bc$49409680$026115ac@dcml.docomolabsusa.com> <444CFE9B.6030602@motorola.com> Subject: Re: [Mip6] Bootstrapping on the home link Date: Mon, 24 Apr 2006 09:50:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: mip6@ietf.org, Vijay Devarapalli X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > Mechanisms and accepted limitations. > > So do you agree that HA discovery based on DNS (be it SRV or simple > query) is not secure until MN queries the HA address in a secure manner? > No. RFC 4033 describes the architecture of DNS security. It is up to operators to deploy that if they want secure DNS lookup. Section 9 of the bootstrapping draft has recommendations about this. > Do you also agree that to a certain extent this DNS querying can happen > in a secure way (after IKE in visited domain), as well as in a > non-secure way (w/o IKE in the visited domain)? > IKE isn't necessary. The operator needs to deploy DNSSEC. >> See RFC 4033. Section 9.1 in the bootstrapping draft discusses the >> security considerations for DNS in bootstrapping. > > I read it. I'm left with the impression that DNS querying in the > visited domain can't be guaranteed secure because all DNS Servers aren't > known to be secure. > > Knowing this, do you agree that the entire argument claiming DHAAD is not > good because it is insecure applies to DNS HA discovery as well? > No. If people don't deploy and use the protocols for securing DNS, then of course lookup won't be secure. IETF has no power or leverage to get people to deploy anything. And the MIP6 group can't go around recommending security solutions that are not standard (such as using IKE to secure DNS) just because people today don't deploy the recommended security measures for a protocol. IMO, the bootstrapping draft adequately covers the issue of DNS security, and we have discussed this numerous times on the list in the past. I don't understand why you are raising this issue again. If you have some problem with the text in Section 9 that discusses the issue, then I would suggest you post some *specific changes in the text* and not these general arguments that we have already been over in the past. In order to make progress we need to move beyond rehashing the same issues again and nail down the text we want to submit to the IESG. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 12:48:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY4Ev-0005oR-7U; Mon, 24 Apr 2006 12:48:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY4Eu-0005oM-2O for mip6@ietf.org; Mon, 24 Apr 2006 12:48:44 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY4Es-0005T2-RI for mip6@ietf.org; Mon, 24 Apr 2006 12:48:44 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3OH5HRp025176; Mon, 24 Apr 2006 10:05:17 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id k3OH39hG000501; Mon, 24 Apr 2006 12:03:10 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id A5CE5865980; Mon, 24 Apr 2006 18:48:31 +0200 (CEST) Message-ID: <444D015F.6080900@motorola.com> Date: Mon, 24 Apr 2006 18:48:31 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: James Kempf Subject: Re: [Mip6] Bootstrapping on the home link References: <444CA782.10300@motorola.com> <018501c667bb$8c436490$026115ac@dcml.docomolabsusa.com> In-Reply-To: <018501c667bb$8c436490$026115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: mip6@ietf.org, Vijay Devarapalli X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org James Kempf wrote: > Alex, > > Can you say why? For one thing, SRV DNS interrogating wouldn't work here because the interrogating key _mip6._ipv6 is not enough to solve all the HAs that can exist in that domain's subnets. It can only solve one. For the DNS resolving method (not SRV), the MN issues normally a query for a ha fqdn. But there can be several HAs on the link, each with a different address, so MN sees several HAs in the RAs. Should it query the DNS for all HAs? If it queries only one and it compares with the wrong RA the home "test" wrongly yields "not at home". If we decide to pre-configure and query all the names of all HAs (and compare to all RAs) then MN could do so only when it is at home, but it doesn't know at this point it's at home or not. Makes sense? Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 13:00:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY4QL-00079m-W2; Mon, 24 Apr 2006 13:00:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY4QL-00079P-7A for mip6@ietf.org; Mon, 24 Apr 2006 13:00:33 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY4QJ-0005og-SS for mip6@ietf.org; Mon, 24 Apr 2006 13:00:33 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3OH0N5X010650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 24 Apr 2006 10:00:24 -0700 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3OGxtQT005479; Mon, 24 Apr 2006 10:00:21 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Apr 2006 10:00:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Bootstrapping on the home link Date: Mon, 24 Apr 2006 10:00:09 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF0023DD132@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Bootstrapping on the home link Thread-Index: AcZnv9W9+vHPLnPURf+z+U6x+EVB4AAAHPXA From: "Soliman, Hesham" To: "Alexandru Petrescu" , "James Kempf" X-OriginalArrivalTime: 24 Apr 2006 17:00:10.0230 (UTC) FILETIME=[8BBAE160:01C667C0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: mip6@ietf.org, Vijay Devarapalli X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > > See RFC 4033. Section 9.1 in the bootstrapping draft discusses the=20 > > security considerations for DNS in bootstrapping. >=20 > I read it. I'm left with the impression that DNS querying in the > visited domain can't be guaranteed secure because all DNS=20 > Servers aren't > known to be secure. >=20 > Knowing this, do you agree that the entire argument claiming=20 > DHAAD is=20 > not good because it is insecure applies to DNS HA discovery as well? =3D> Of course. Both insecurities amount to a DoS attack, which will not hijack any sessions, but will stop the MN from being=20 reachable. But the real advantage of using the DNS is not security,=20 it's the ability to not store IP addresses/prefixes in the=20 MN, which allows it to be more resilient to network changes like=20 renumbering.=20 Hesham >=20 > Alex >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 13:21:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY4ju-0007v7-Oe; Mon, 24 Apr 2006 13:20:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY4jD-0007mS-Gf for mip6@ietf.org; Mon, 24 Apr 2006 13:20:03 -0400 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY4jC-0006lG-7q for mip6@ietf.org; Mon, 24 Apr 2006 13:20:03 -0400 Received: from az33exr03.mot.com ([10.64.251.233]) by motgate7.mot.com (8.12.11/Motgate7) with ESMTP id k3OHpSsq024977; Mon, 24 Apr 2006 10:51:32 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id k3OHaSM2016747; Mon, 24 Apr 2006 12:36:29 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 2171D865980; Mon, 24 Apr 2006 19:19:48 +0200 (CEST) Message-ID: <444D08B3.8060903@motorola.com> Date: Mon, 24 Apr 2006 19:19:47 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: [Mip6] Bootstrapping on the home link References: <1487A357FD2ED544B8AD29E528FF9DF0023DD132@NAEX06.na.qualcomm.com> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF0023DD132@NAEX06.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: mip6@ietf.org, James Kempf , Vijay Devarapalli X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Soliman, Hesham wrote: > >>> See RFC 4033. Section 9.1 in the bootstrapping draft discusses >>> the security considerations for DNS in bootstrapping. >> >> I read it. I'm left with the impression that DNS querying in the >> visited domain can't be guaranteed secure because all DNS Servers >> aren't known to be secure. >> >> Knowing this, do you agree that the entire argument claiming DHAAD >> is not good because it is insecure applies to DNS HA discovery as >> well? > > => Of course. Both insecurities amount to a DoS attack, which will > not hijack any sessions, but will stop the MN from being reachable. Your affirmation is true _if_ the MN stores certs. If it does, then the amount of preconfigured info is much larger than with DHAAD. A simple method based on DHAAD would only store shared keys (not certs). > But the real advantage of using the DNS is not security, it's the > ability to not store IP addresses/prefixes in the MN, which allows it > to be more resilient to network changes like renumbering. 1. MPD is designed just for that - face home link re-numbering. 2. nowhere in the draft it's said the advantage of the DNS-based HA discovery is it's resilient to renumbering. 3. DHAAD use doesn't preclude the use of HA names in the DNS. What DHAAD is less resilient to is when the entire home prefix gets changed. In which case so many things will change that I guess the certs on the MN are no longer valid either - how do you update certs on the MN? Alex > > Hesham > >> >> Alex >> >> >> _______________________________________________ Mip6 mailing list >> Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 >> _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 13:21:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY4k7-0008BW-Sy; Mon, 24 Apr 2006 13:20:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY4jK-0007oZ-GC for mip6@ietf.org; Mon, 24 Apr 2006 13:20:10 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY4Yt-0006I2-2i for mip6@ietf.org; Mon, 24 Apr 2006 13:09:23 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3OHQ465028675; Mon, 24 Apr 2006 10:26:04 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id k3OHNHR4020478; Mon, 24 Apr 2006 12:23:17 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id C8E54865980; Mon, 24 Apr 2006 19:09:18 +0200 (CEST) Message-ID: <444D063E.7090502@motorola.com> Date: Mon, 24 Apr 2006 19:09:18 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: James Kempf Subject: Re: [Mip6] Bootstrapping on the home link References: <444CA8B0.9030706@motorola.com> <018a01c667bc$49409680$026115ac@dcml.docomolabsusa.com> <444CFE9B.6030602@motorola.com> <01c601c667bf$3a88dbe0$026115ac@dcml.docomolabsusa.com> In-Reply-To: <01c601c667bf$3a88dbe0$026115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: mip6@ietf.org, Vijay Devarapalli X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org James Kempf wrote: >> Mechanisms and accepted limitations. >> >> So do you agree that HA discovery based on DNS (be it SRV or simple >> query) is not secure until MN queries the HA address in a secure manner? >> > > No. RFC 4033 describes the architecture of DNS security. It is up to > operators to deploy that if they want secure DNS lookup. Section 9 of > the bootstrapping draft has recommendations about this. Ok. Remark that DNS lookup may happen securely to DNS operators without DNSSEC (because operators have a SIM card in the phone) but at the same time insecurely for somebody discovering its HA via that apparently secure DNS (because same operators often use MAC address as the equivalent of the SIM card). I.e. the DNS looks secure for the operator itself but a user may be attackable if uses a HA not provided by that operator (the split scenario). >> Do you also agree that to a certain extent this DNS querying can happen >> in a secure way (after IKE in visited domain), as well as in a >> non-secure way (w/o IKE in the visited domain)? >> > > IKE isn't necessary. The operator needs to deploy DNSSEC. Ok. And if the operator deploys DNSSEC does the MN also need to use DNSSEC? In order for the DNS-based bootstrapping procedure to work securely will the MN need to run DNSSEC? >>> See RFC 4033. Section 9.1 in the bootstrapping draft discusses the >>> security considerations for DNS in bootstrapping. >> >> I read it. I'm left with the impression that DNS querying in the >> visited domain can't be guaranteed secure because all DNS Servers aren't >> known to be secure. >> >> Knowing this, do you agree that the entire argument claiming DHAAD is >> not good because it is insecure applies to DNS HA discovery as well? >> > > No. If people don't deploy and use the protocols for securing DNS, then > of course lookup won't be secure. IETF has no power or leverage to get > people to deploy anything. And the MIP6 group can't go around > recommending security solutions that are not standard (such as using IKE > to secure DNS) just because people today don't deploy the recommended > security measures for a protocol. > > IMO, the bootstrapping draft adequately covers the issue of DNS > security, and we have discussed this numerous times on the list in the > past. I don't understand why you are raising this issue again. If you > have some problem with the text in Section 9 that discusses the issue, > then I would suggest you post some *specific changes in the text* and How about changing the draft title to "DNS-based Mobile Node Bootstrapping"? This would leave the place for a "DHAAD-based Mobile Node Bootstrapping" draft. There are no security or preconfig amount of information discriminators between the two. I.e. one can't say that any one method is more secure or requires less pre-configuration. > not these general arguments that we have already been over in the past. > In order to make progress we need to move beyond rehashing the same > issues again and nail down the text we want to submit to the IESG. James, remember dhaad-harmful? Remember WG mike discussions where DHAAD was discarded as insecure? When somebody discards some protocol (DHAAD) on security grounds one would expect at least a more secure version of said protocol, not a fortunate assumption on how people should deploy yet other protocols (DNS). When ND was acked as non-secure nobody went out proposing to discover the AR via DNS, instead they worked out SeND. But I'll get back to the text section 9 on draft-bootstrap-split and comment on it. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 13:23:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY4m5-0000Td-3U; Mon, 24 Apr 2006 13:23:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY4m3-0000TX-Of for mip6@ietf.org; Mon, 24 Apr 2006 13:22:59 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY4m2-000730-Gl for mip6@ietf.org; Mon, 24 Apr 2006 13:22:59 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3OHdVuf000965; Mon, 24 Apr 2006 10:39:31 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id k3OHahld026164; Mon, 24 Apr 2006 12:36:44 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id BD9EC865980; Mon, 24 Apr 2006 19:22:45 +0200 (CEST) Message-ID: <444D0965.8060504@motorola.com> Date: Mon, 24 Apr 2006 19:22:45 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: [Mip6] Bootstrapping on the home link References: <1487A357FD2ED544B8AD29E528FF9DF0023DD132@NAEX06.na.qualcomm.com> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF0023DD132@NAEX06.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: mip6@ietf.org, James Kempf , Vijay Devarapalli X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Soliman, Hesham wrote: > > > > See RFC 4033. Section 9.1 in the bootstrapping draft discusses the > > > security considerations for DNS in bootstrapping. > > > > I read it. I'm left with the impression that DNS querying in the > > visited domain can't be guaranteed secure because all DNS > > Servers aren't > > known to be secure. > > > > Knowing this, do you agree that the entire argument claiming > > DHAAD is > > not good because it is insecure applies to DNS HA discovery as well? > > => Of course. Both insecurities amount to a DoS attack, which will > not hijack any sessions, but will stop the MN from being > reachable. But the real advantage of using the DNS is not security, > it's the ability to not store IP addresses/prefixes in the > MN, For SVR, it's little possible to just store _mip6._ip6.domain.com in the MN because the reply back doesn't tell the MN the HA where the MN was attached when it was at home (there can be several subnets in domain.com, and each MUST have at least a HA). Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 13:40:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY52G-0005v2-I0; Mon, 24 Apr 2006 13:39:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY52F-0005ux-Kx for mip6@ietf.org; Mon, 24 Apr 2006 13:39:43 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY52E-0007dj-9M for mip6@ietf.org; Mon, 24 Apr 2006 13:39:43 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3OHdI6i016007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 24 Apr 2006 10:39:19 -0700 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3OHc6mG011756; Mon, 24 Apr 2006 10:39:18 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Apr 2006 10:39:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Bootstrapping on the home link Date: Mon, 24 Apr 2006 10:39:16 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF0023DD1BF@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Bootstrapping on the home link Thread-Index: AcZnw1mY2lll/I2eQmiA4aRlmtm2ogAAJ0BA From: "Soliman, Hesham" To: "Alexandru Petrescu" X-OriginalArrivalTime: 24 Apr 2006 17:39:16.0902 (UTC) FILETIME=[02749C60:01C667C6] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: mip6@ietf.org, James Kempf , Vijay Devarapalli X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > > =3D> Of course. Both insecurities amount to a DoS attack, which = will=20 > > not hijack any sessions, but will stop the MN from being reachable. >=20 > Your affirmation is true _if_ the MN stores certs. If it=20 > does, then the=20 > amount of preconfigured info is much larger than with DHAAD.=20 =3D> I wasn't referring to the amount of information stored, I was = talking about the type of information. > A simple=20 > method based on DHAAD would only store shared keys (not certs). =3D> No, there is no relationship between the two. >=20 > > But the real advantage of using the DNS is not security, it's the > > ability to not store IP addresses/prefixes in the MN,=20 > which allows it > > to be more resilient to network changes like renumbering. >=20 > 1. MPD is designed just for that - face home link re-numbering. >=20 > 2. nowhere in the draft it's said the advantage of the DNS-based HA > discovery is it's resilient to renumbering. >=20 > 3. DHAAD use doesn't preclude the use of HA names in the DNS. What > DHAAD is less resilient to is when the entire home prefix gets > changed.=20 =3D> That *is* renumbering... In which case so many things will change that=20 > I guess the > certs on the MN are no longer valid either -=20 =3D> Why not? Certs are not tied to addresses unless you make them so, but you shouldn't. how do you=20 > update certs > on the MN? =3D> You don't need to.=20 Hesham >=20 > Alex >=20 > >=20 > > Hesham > >=20 > >>=20 > >> Alex > >>=20 > >>=20 > >> _______________________________________________ Mip6 mailing list=20 > >> Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 > >>=20 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 13:43:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY55U-0007U4-SP; Mon, 24 Apr 2006 13:43:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY55T-0007Tz-E0 for mip6@ietf.org; Mon, 24 Apr 2006 13:43:03 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY55S-0007lm-2H for mip6@ietf.org; Mon, 24 Apr 2006 13:43:03 -0400 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Apr 2006 19:42:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 24 Apr 2006 19:42:49 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft-dupont-ikev2-haassign-01.txt - Status Thread-Index: AcZnxoE9Ns4SvcymR8OLRUX/RNeKvw== From: "COMBES Jean-Michel RD-MAPS-ISS" To: X-OriginalArrivalTime: 24 Apr 2006 17:42:54.0415 (UTC) FILETIME=[841A75F0:01C667C6] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Mip6] Draft-dupont-ikev2-haassign-01.txt - Status X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi, I would like to know what is the status regarding the draft 'draft-dupont-ikev2-haassign-01.txt'? Thanks in advance. Best regards. JMC. France Telecom - R&D Division - MAPS/NSS =20 Jean-Michel COMBES, Internet/Intranet Security E-Mail: jeanmichel.combes@francetelecom.com Phone: +33 (0)1 45 29 45 94 Fax: +33 (0)1 45 29 65 19 Mobile: +33 (0)6 07 29 30 16=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 13:50:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY5Ce-0001kG-6H; Mon, 24 Apr 2006 13:50:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY5Cc-0001kA-HV for mip6@ietf.org; Mon, 24 Apr 2006 13:50:26 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY5Ca-00085U-7c for mip6@ietf.org; Mon, 24 Apr 2006 13:50:26 -0400 Received: from [10.1.201.8] ([10.1.201.8]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Apr 2006 10:50:09 -0700 Message-ID: <444D0FDE.508@azairenet.com> Date: Mon, 24 Apr 2006 10:50:22 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [Mip6] Bootstrapping from the home link References: <44498CEA.4050803@azairenet.com> <444CA5A6.7060905@motorola.com> In-Reply-To: <444CA5A6.7060905@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Apr 2006 17:50:09.0973 (UTC) FILETIME=[87B75650:01C667C7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: mip6@ietf.org, James Kempf X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Alexandru Petrescu wrote: > Vijay Devarapalli wrote: >> hello, >> >> after some discussions offlist, we came up with some text that could >> be added to draft-ietf-mip6-bootstrapping-split-02.txt to address >> bootstrapping from the home link. the proposal is to have this in a >> new section before the security considerations section. >> >> 9. Bootstrapping from the home link >> >> The mechanisms described in this document also support a mobile node >> bootstrapping from the home link. When the mobile node is on the home >> link it receives router advertisements from the home agent with the >> 'H' bit set and the 128 bit address of the home agent in the modified >> prefix information option [RFC3775]. When the mobile node bootstraps, >> the first operation it does is to perform a DNS lookup for the home >> agent. > > Can MN do DNS lookup before having an Address? I guess no. So I doubt > the first operation it does is to perform a DNS loookup for the HA. I > think the first operation it does is to auto-configure an address. yes. I guess the current text is confusing. the fact that the MN configures an address before doing a DNS lookup was left implicit. >> If at least one of the home agent address received in the DNS reply > > Isn't that a "DNS Response" or "answer" but not "reply"? will change it to "DNS Response". Vijay > >> matches the address the mobile node received in the router >> advertisement from the home agent, then the mobile node assumes it is >> attached to the home link. >> >> For configuring a home address, the mobile node can either auto- >> configure a home address, use DHCPv6 or run IKEv2 with its home agent >> as described in section 5.3. > > Would MN auto-configure a Address first or decide first whether it > is at home or not (and do DNS)? > > Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 13:54:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY5G3-0002ik-Dm; Mon, 24 Apr 2006 13:53:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY5G1-0002iX-KS for mip6@ietf.org; Mon, 24 Apr 2006 13:53:57 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY5G1-0008Gv-CT for mip6@ietf.org; Mon, 24 Apr 2006 13:53:57 -0400 Received: from [10.1.201.8] ([10.1.201.8]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Apr 2006 10:53:43 -0700 Message-ID: <444D10B4.1070609@azairenet.com> Date: Mon, 24 Apr 2006 10:53:56 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [Mip6] Bootstrapping on the home link References: <444CA782.10300@motorola.com> In-Reply-To: <444CA782.10300@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Apr 2006 17:53:43.0736 (UTC) FILETIME=[0720FB80:01C667C8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Alexandru Petrescu wrote: > For this reason, the straightforward way to have a decision capability > about being at home is to pre-configure the home prefix on the mobile, > and compare it to the one in the received RA. sure thats possible. but the assumption here is that the MN has minimal configuration. this does not include configuring home prefix information on the MN. infact, many folks did not want to tie the mobile node to a specific home prefix. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 14:12:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY5Xt-0000YV-Km; Mon, 24 Apr 2006 14:12:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY5Xs-0000YP-7f for mip6@ietf.org; Mon, 24 Apr 2006 14:12:24 -0400 Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY5Xr-0000Zj-Rs for mip6@ietf.org; Mon, 24 Apr 2006 14:12:24 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id k3OIXfhH008581 for ; Mon, 24 Apr 2006 11:33:41 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id k3OIO4KG012975 for ; Mon, 24 Apr 2006 13:24:04 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 8793C865980 for ; Mon, 24 Apr 2006 20:12:19 +0200 (CEST) Message-ID: <444D1503.3020105@motorola.com> Date: Mon, 24 Apr 2006 20:12:19 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: mip6@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Subject: [Mip6] Substitute "high risk" for "mitigated risk" in Security Considerations of draft-ietf-mip6-bootstrapping-split-02.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org James, Per your request here are some comments and text suggestions on some parts of the Security Considerations section of draft-ietf-mip6-bootstrapping-split-02.txt. > The risk in Case 1 is mitigated because the Mobile Node is ^^^^^^^^^ Substitute "high" for "mitigated" because it is very easy to set up an AP running DNS Server, HA and even fake CA, thus fooling MN to send all its traffic to it. > Thus, an attacker would have to set up both a bogus DNS server and a > bogus Home Agent, This leaves the reader with the impression that it is difficult to set up a rogue laptop being AP, DNS, HA and CA. It's not: hostap, bind9, mipl and open-ssl. > and provision the Home Agent with a certificate that a victim Mobile > Node could verify. Once the MN sends all its traffic to the rogue AP being CA, the MN will query that CA about cert validity and the rogue CA will reply positively, because it's rogue. > If the Mobile Node can detect that the certificate is not > trustworthy, That's a big IF. Do you have in mind a legitimate MN with two interfaces, one spoofable and one completely secure? Because if the MN is attached only to the rogue AP leading to a fake Internet, how could it securely verify the certificate? > the attack will be foiled when the Mobile Node attempts to set up the > IKE SA. Yes, provided that big IF materializes into a yes. But I am pretty sure a 802.11 laptop won't do normal traffic on one interface and security verification traffic on another more secure interface. So I suggest substituting High for the Mitigated cited previously. > The risk in Case 2 is limited for a single Mobile Node to Home Agent > transaction if the attacker does not possess proper credentials to > authenticate with the Home Agent. The IKE SA establishment will fail > when the attacking Mobile Node attempts to authenticate itself with > the Home Agent. Regardless of whether the Home Agent utilizes EAP or > host-side certificates to authenticate the Mobile Node, the > authentication will fail unless the Mobile Node has valid > credentials. I agree with this. However the previous risk is relatively high, not mitigated. Would you agree? > Explicit security measures between the DNS server and host, such > DNSSEC [16] or TSIG/TKEY [17] [18] can mitigate the risk of 1) and > 2), but these security measures are not widely deployed on end nodes. Substitute "1) and 2)" with "2) only" because I think it's easy to set-up a fake DNS server appearing as DNSSEC to MN, with the laptop hostap I described previously. Or maybe some text is needed in this section that states that the MN to the first real IP hop (not virtual) connection is secured? There is no such text currently here. I mean something about link-layer security? Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 14:19:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY5es-0003YM-CP; Mon, 24 Apr 2006 14:19:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY5eq-0003YH-TK for mip6@ietf.org; Mon, 24 Apr 2006 14:19:36 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY5em-0000zj-Hl for mip6@ietf.org; Mon, 24 Apr 2006 14:19:36 -0400 Received: from [10.1.201.8] ([10.1.201.8]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Apr 2006 11:19:18 -0700 Message-ID: <444D16B2.8040004@azairenet.com> Date: Mon, 24 Apr 2006 11:19:30 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [Mip6] Comments while reading draft-ietf-mip6-bootstrapping-split-02.txt References: <444CD11C.2050807@motorola.com> In-Reply-To: <444CD11C.2050807@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Apr 2006 18:19:18.0216 (UTC) FILETIME=[99C00C80:01C667CB] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org hi Alex, I will try to answer a couple of questions and leave the rest to Gerardo. :) Alexandru Petrescu wrote: >> The service name for Mobile IPv6 Home Agent service as required by RFC >> 2782 is "mip6" and the protocol name is "ipv6". Note that a transport >> name cannot be used here because Mobile IPv6 does not run over a >> transport protocol. > > Would this require modifications to rfc2782 to explain that the Port > number in a SRV RR be optional? no need for modifications. it is just a string. RFC 2782 says Proto The symbolic name of the desired protocol, with an underscore (_) prepended to prevent collisions with DNS labels that occur in nature. _TCP and _UDP are at present the most useful values for this field, though any name defined by Assigned Numbers or locally may be used (as for Service). The Proto is case insensitive. > The second question is: do we need IANA action for being able to use the > service name in SRV "mip6" ? Because the IANA Considerations section > doesn't seem to mention it. nope. IANA does not maintain this. for some reason they are maintained at http://www.dns-sd.org/ServiceTypes.html. I would also like IANA to maintain the service types. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 14:24:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY5jO-0004yu-Ur; Mon, 24 Apr 2006 14:24:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY5jN-0004yp-1W for mip6@ietf.org; Mon, 24 Apr 2006 14:24:17 -0400 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY5jK-0001Lv-MA for mip6@ietf.org; Mon, 24 Apr 2006 14:24:17 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id k3OIZuUM021263; Mon, 24 Apr 2006 11:36:00 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id k3OIZmIT020442; Mon, 24 Apr 2006 13:35:48 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 9C8B9865980; Mon, 24 Apr 2006 20:24:03 +0200 (CEST) Message-ID: <444D17C3.1090303@motorola.com> Date: Mon, 24 Apr 2006 20:24:03 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip6] Bootstrapping on the home link References: <444CA782.10300@motorola.com> <444D10B4.1070609@azairenet.com> In-Reply-To: <444D10B4.1070609@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Vijay Devarapalli wrote: > Alexandru Petrescu wrote: > >> For this reason, the straightforward way to have a decision >> capability about being at home is to pre-configure the home prefix >> on the mobile, and compare it to the one in the received RA. > > sure thats possible. but the assumption here is that the MN has > minimal configuration. this does not include configuring home prefix > information on the MN. Vijay what's "minimal"? Memory space? Binary representation of a 64 bit prefix (the longest possible) is sure shorter than here-goes-my-domain.com. ASCII too. Do you mean "more human-friendly" and not "minimal"? Even in that case, entering a hexa address on a PDA screen may be easier than a domain name, depending on software and user skill. Besides, I think this kind of pre-configured information is to be written in the MN by some configuration software (SNMP, SMS, you name it), so I don't buy the argument configuring a DNS address is more minimal than a home prefix. > infact, many folks did not want to tie the mobile node to a specific > home prefix. That's another thing. Ask whether they want a permanent Home IP Address or not, also do they want session continuity. Because, one can not imagine to magically use bootstrapping and each time obtain a different Home Address and still have session continuity at the previous Home Address. Also, one can not imagine that same traffic from CN to same Home Address will be duplicated in two parts of the network (different home prefixes). > infact, many folks did not want to tie the mobile node to a specific > home prefix. Do you think they agree to tie the MN to one specific home domain name? I don't think so. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 14:34:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY5si-0000Cz-2S; Mon, 24 Apr 2006 14:33:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY5sf-0000B9-GL for mip6@ietf.org; Mon, 24 Apr 2006 14:33:53 -0400 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY5se-0001sl-4j for mip6@ietf.org; Mon, 24 Apr 2006 14:33:53 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id k3OIjVhS027001; Mon, 24 Apr 2006 11:45:31 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id k3OIl1hU012952; Mon, 24 Apr 2006 13:47:02 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 2BD61865980; Mon, 24 Apr 2006 20:33:38 +0200 (CEST) Message-ID: <444D1A01.9010007@motorola.com> Date: Mon, 24 Apr 2006 20:33:37 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: [Mip6] Bootstrapping on the home link References: <1487A357FD2ED544B8AD29E528FF9DF0023DD1BF@NAEX06.na.qualcomm.com> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF0023DD1BF@NAEX06.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: mip6@ietf.org, James Kempf , Vijay Devarapalli X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Soliman, Hesham wrote: > >>> => Of course. Both insecurities amount to a DoS attack, which >>> will not hijack any sessions, but will stop the MN from being >>> reachable. >> >> Your affirmation is true _if_ the MN stores certs. If it does, >> then the amount of preconfigured info is much larger than with >> DHAAD. > > => I wasn't referring to the amount of information stored, I was > talking about the type of information. So for you the type of preconfigured information is cert, then it's better than if the type of information is SA key plus home prefix? >> A simple method based on DHAAD would only store shared keys (not >> certs). > > => No, there is no relationship between the two. > >> >>> But the real advantage of using the DNS is not security, it's the >>> ability to not store IP addresses/prefixes in the MN, >> which allows it >>> to be more resilient to network changes like renumbering. >> >> 1. MPD is designed just for that - face home link re-numbering. >> >> 2. nowhere in the draft it's said the advantage of the DNS-based HA >> discovery is it's resilient to renumbering. >> >> 3. DHAAD use doesn't preclude the use of HA names in the DNS. What >> DHAAD is less resilient to is when the entire home prefix gets >> changed. > > => That *is* renumbering... Ok. > In which case so many things will change that >> I guess the certs on the MN are no longer valid either - > > => Why not? Certs are not tied to addresses unless you make them so, > but you shouldn't. What are they tied to? MAC address? NAI? email address? FQDN? Any of these can change and so the cert on the MN can change. No less than the home prefix can change. >> how do you update certs on the MN? > > => You don't need to. If one doesn't change it, and the cert is tied to the FQDN, and the respective company gets sold to some other company, and the domain name changes, then the mobile won't be able to authenticate to its HA unless one updates the cert on MN, no? Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 14:46:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY65B-00047o-Mu; Mon, 24 Apr 2006 14:46:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY65A-00047j-P1 for mip6@ietf.org; Mon, 24 Apr 2006 14:46:48 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY65A-0003L6-EZ for mip6@ietf.org; Mon, 24 Apr 2006 14:46:48 -0400 Received: from [10.1.201.8] ([10.1.201.8]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Apr 2006 11:46:34 -0700 Message-ID: <444D1D16.1020306@azairenet.com> Date: Mon, 24 Apr 2006 11:46:46 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [Mip6] Bootstrapping on the home link References: <444CA782.10300@motorola.com> <444D10B4.1070609@azairenet.com> <444D17C3.1090303@motorola.com> In-Reply-To: <444D17C3.1090303@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Apr 2006 18:46:34.0226 (UTC) FILETIME=[68E35D20:01C667CF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Alexandru Petrescu wrote: > Vijay Devarapalli wrote: >> Alexandru Petrescu wrote: >> >>> For this reason, the straightforward way to have a decision >>> capability about being at home is to pre-configure the home prefix >>> on the mobile, and compare it to the one in the received RA. >> >> sure thats possible. but the assumption here is that the MN has >> minimal configuration. this does not include configuring home prefix >> information on the MN. > > Vijay what's "minimal"? see section 8 of http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrap-ps-04.txt this draft is with the IESG right now. >> infact, many folks did not want to tie the mobile node to a specific >> home prefix. > > That's another thing. Ask whether they want a permanent Home IP Address > or not, also do they want session continuity. no permanent home address but session continuity. > > Because, one can not imagine to magically use bootstrapping and each > time obtain a different Home Address and still have session continuity > at the previous Home Address. as long as the new home address is updated in the DNS entry, the new home address is _the_ home address of the mobile node. Alex, all this has nothing to do with the current text that is being proposed. looks like you have issues with the basic assumptions in draft-ietf-mip6-bootstrap-ps-04.txt and draft-ietf-mip6-bootstrapping-split-02.txt. > Also, one can not imagine that same traffic from CN to same Home Address > will be duplicated in two parts of the network (different home prefixes). I didn't get this. the traffic from the CN to a home address shouldnt get duplicated. Vijay > > > infact, many folks did not want to tie the mobile node to a specific > > home prefix. > > Do you think they agree to tie the MN to one specific home domain name? > I don't think so. > > Alex > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 14:52:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY6AD-0004YZ-DH; Mon, 24 Apr 2006 14:52:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY6AC-0004YU-5c for mip6@ietf.org; Mon, 24 Apr 2006 14:52:00 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY6A9-0003SF-PK for mip6@ietf.org; Mon, 24 Apr 2006 14:52:00 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3OIpVxo025016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 24 Apr 2006 11:51:32 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3OIp5xw019487; Mon, 24 Apr 2006 11:51:30 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Apr 2006 11:51:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Bootstrapping on the home link Date: Mon, 24 Apr 2006 11:51:25 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF0023DD2CF@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Bootstrapping on the home link Thread-Index: AcZnzag37w6Ne+/rRjWd28NKjNXZdwAAe/bg From: "Soliman, Hesham" To: "Alexandru Petrescu" X-OriginalArrivalTime: 24 Apr 2006 18:51:28.0049 (UTC) FILETIME=[18053210:01C667D0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: mip6@ietf.org, James Kempf , Vijay Devarapalli X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > > =3D> I wasn't referring to the amount of information stored, I was=20 > > talking about the type of information. >=20 > So for you the type of preconfigured information is cert, then it's > better than if the type of information is SA key plus home prefix? =3D> yes. But i'm not saying DHAAD should be deprecated, you can choose in your own deployment.=20 > >> how do you update certs on the MN? > >=20 > > =3D> You don't need to. >=20 > If one doesn't change it, and the cert is tied to the FQDN, and the=20 > respective company gets sold to some other company, and the=20 > domain name=20 > changes, then the mobile won't be able to authenticate to=20 > its HA unless=20 > one updates the cert on MN, no? =3D> Yes but this is not specific to MIP6, it's a general issue for cert management. =20 Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 15:05:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY6N4-0002S3-Bh; Mon, 24 Apr 2006 15:05:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY6N3-0002Ry-3B for mip6@ietf.org; Mon, 24 Apr 2006 15:05:17 -0400 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY6Mz-0003sn-Nb for mip6@ietf.org; Mon, 24 Apr 2006 15:05:17 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id k3OJH3mY016220; Mon, 24 Apr 2006 12:17:03 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id k3OJIXWs002362; Mon, 24 Apr 2006 14:18:34 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 14DBC865980; Mon, 24 Apr 2006 21:05:10 +0200 (CEST) Message-ID: <444D2165.50008@motorola.com> Date: Mon, 24 Apr 2006 21:05:09 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip6] Comments while reading draft-ietf-mip6-bootstrapping-split-02.txt References: <444CD11C.2050807@motorola.com> <444D16B2.8040004@azairenet.com> In-Reply-To: <444D16B2.8040004@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Vijay Devarapalli wrote: > hi Alex, > > I will try to answer a couple of questions and > leave the rest to Gerardo. :) > > Alexandru Petrescu wrote: >>> The service name for Mobile IPv6 Home Agent service as required by >>> RFC 2782 is "mip6" and the protocol name is "ipv6". Note that a >>> transport name cannot be used here because Mobile IPv6 does not run >>> over a transport protocol. >> >> Would this require modifications to rfc2782 to explain that the Port >> number in a SRV RR be optional? > > no need for modifications. it is just a string. > RFC 2782 says > > Proto > The symbolic name of the desired protocol, with an underscore > (_) prepended to prevent collisions with DNS labels that occur > in nature. _TCP and _UDP are at present the most useful values > for this field, though any name defined by Assigned Numbers or > locally may be used (as for Service). The Proto is case > insensitive. Ok, got it. The doubt was in that mentioning of "Assigned Numbers" and "local", because I was afraid that foreign domain may define "ipv6" as local while home domain might use "mip6" as local. But the record is normally defined in only one place (presumably the home) and the foreign domains will just carry it. >> The second question is: do we need IANA action for being able to use the >> service name in SRV "mip6" ? Because the IANA Considerations section >> doesn't seem to mention it. > > nope. IANA does not maintain this. for some > reason they are maintained at > http://www.dns-sd.org/ServiceTypes.html. I would > also like IANA to maintain the service types. Maybe someone should write to srvtypes at that address, mixing in the IESG phase, inform the Name mip6 and Service ipv6 are used (?). At least the ipv6 keyword has a large potential that people may be interested in. Not to forget it, this SRV method lacks the capability to deliver to MN the home prefix the MN has seen previously (either because it was at home, or because this is a 2nd bootstrap) - hence Home Address changes and sessions are interrupted. But that's a separate thread. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 15:12:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY6UF-0005Y3-CX; Mon, 24 Apr 2006 15:12:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY6UD-0005Xx-Sz for mip6@ietf.org; Mon, 24 Apr 2006 15:12:41 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY6UC-0004H0-Ju for mip6@ietf.org; Mon, 24 Apr 2006 15:12:41 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3OJTBFg021408; Mon, 24 Apr 2006 12:29:11 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k3OJTKAT015158; Mon, 24 Apr 2006 14:29:20 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 4C58E865980; Mon, 24 Apr 2006 21:12:25 +0200 (CEST) Message-ID: <444D2319.10703@motorola.com> Date: Mon, 24 Apr 2006 21:12:25 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: [Mip6] Bootstrapping on the home link References: <1487A357FD2ED544B8AD29E528FF9DF0023DD2CF@NAEX06.na.qualcomm.com> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF0023DD2CF@NAEX06.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: mip6@ietf.org, James Kempf , Vijay Devarapalli X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Soliman, Hesham wrote: > >>> => I wasn't referring to the amount of information stored, I was >>> talking about the type of information. >> >> So for you the type of preconfigured information is cert, then it's >> better than if the type of information is SA key plus home prefix? >> > > => yes. But i'm not saying DHAAD should be deprecated, you can choose > in your own deployment. That's why I'm suggesting to title this draft "DNS-based MIP6 MN bootstrapping in split scenario" instead of the current all-covering "MIP6 bootstrapping in split scenario". It leaves the place for other drafts describing other deployments with "DHAAD-based MIP6 MN bootstrapping in split scenario". Would you agree? >>>> how do you update certs on the MN? >>> >>> => You don't need to. >> >> If one doesn't change it, and the cert is tied to the FQDN, and the >> respective company gets sold to some other company, and the domain >> name changes, then the mobile won't be able to authenticate to its >> HA unless one updates the cert on MN, no? > > => Yes but this is not specific to MIP6, it's a general issue for > cert management. Right, it's a general issue for cert management; it's still an issue and the ephemerality of certs is the same as that of the pre-configured prefixes. Would you agree? Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 15:35:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY6pk-00053i-3I; Mon, 24 Apr 2006 15:34:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY6pi-0004vu-GY for mip6@ietf.org; Mon, 24 Apr 2006 15:34:54 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY6pi-0005dX-7N for mip6@ietf.org; Mon, 24 Apr 2006 15:34:54 -0400 Received: from az33exr02.mot.com ([10.64.251.232]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3OJpbFP025333; Mon, 24 Apr 2006 12:51:37 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id k3OJmENc020584; Mon, 24 Apr 2006 14:48:14 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 37C9D865980; Mon, 24 Apr 2006 21:34:50 +0200 (CEST) Message-ID: <444D285A.8030202@motorola.com> Date: Mon, 24 Apr 2006 21:34:50 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip6] Bootstrapping on the home link References: <444CA782.10300@motorola.com> <444D10B4.1070609@azairenet.com> <444D17C3.1090303@motorola.com> <444D1D16.1020306@azairenet.com> In-Reply-To: <444D1D16.1020306@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Vijay Devarapalli wrote: > Alexandru Petrescu wrote: >> Vijay Devarapalli wrote: >>> Alexandru Petrescu wrote: >>> >>>> For this reason, the straightforward way to have a decision >>>> capability about being at home is to pre-configure the home >>>> prefix on the mobile, and compare it to the one in the received >>>> RA. >>> >>> sure thats possible. but the assumption here is that the MN has >>> minimal configuration. this does not include configuring home >>> prefix information on the MN. >> >> Vijay what's "minimal"? > > see section 8 of > http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrap-ps-04.txt > this draft is with the IESG right now. Not to look dumb: I _am_ aware of the draft and of the section. It says the bootstrapping for split scenario should use the domain name and IKE credentials. That's a biased and unfounded statement. A problem statement draft should consider all possible pre-config (seed) information. A possible pre-config information is the home prefix. That's been implemented in at least two implementations. I have said this on the mailing list and on the microphone. Skimming today through it anew, I find many statements about discarding DHAAD security issues as being problems, and to which proposed solution is no better, security-wise. Re the draft is in IESG queue - I can't and don't intend do anything about it. The document has other value in it anyways. The only point where it hasn't is that it leaves the reader with the taste that DHAAD is insecure, and can't be made secure, so one would expect a real secure discovery technique only to be disapointed by the relegation to "it's a generic problem" and "people deploy wrongly". Re "minimal" - nowhere does the PS draft (nor the split solution) say what's minimal pre-config. Calling "minimal" pre-config the list of domain name and IKE keys/certs is not adequate because home prefix + same certs is shorter in terms of memory space. >>> infact, many folks did not want to tie the mobile node to a >>> specific home prefix. >> >> That's another thing. Ask whether they want a permanent Home IP >> Address or not, also do they want session continuity. > > no permanent home address but session continuity. That can't be... but separate topic. >> Because, one can not imagine to magically use bootstrapping and >> each time obtain a different Home Address and still have session >> continuity at the previous Home Address. > > as long as the new home address is updated in the DNS entry, the new > home address is _the_ home address of the mobile node. > > Alex, all this has nothing to do with the current text that is being > proposed. looks like you have issues with the basic assumptions in > draft-ietf-mip6-bootstrap-ps-04.txt and > draft-ietf-mip6-bootstrapping-split-02.txt. I know. And it's too late. Fine. What I say now I was saying during the LC for PS too. There's still reply, the meaning of which is up to anyone's interpretation. >> Also, one can not imagine that same traffic from CN to same Home >> Address will be duplicated in two parts of the network (different >> home prefixes). > > I didn't get this. the traffic from the CN to a home address shouldnt > get duplicated. Yes, I can explain separately. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 15:43:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY6yH-0005sE-NZ; Mon, 24 Apr 2006 15:43:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY6yG-0005s9-O7 for mip6@ietf.org; Mon, 24 Apr 2006 15:43:44 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY6yG-00068b-F6 for mip6@ietf.org; Mon, 24 Apr 2006 15:43:44 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3OK0Q7Z026876; Mon, 24 Apr 2006 13:00:26 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k3OK0ZJE000839; Mon, 24 Apr 2006 15:00:35 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 47E64865980; Mon, 24 Apr 2006 21:43:40 +0200 (CEST) Message-ID: <444D2A6B.8090003@motorola.com> Date: Mon, 24 Apr 2006 21:43:39 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip6] Bootstrapping from the home link References: <44498CEA.4050803@azairenet.com> <444CA5A6.7060905@motorola.com> <444D0FDE.508@azairenet.com> In-Reply-To: <444D0FDE.508@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: mip6@ietf.org, James Kempf X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Vijay Devarapalli wrote: > Alexandru Petrescu wrote: >> Vijay Devarapalli wrote: >>> hello, >>> >>> after some discussions offlist, we came up with some text that could >>> be added to draft-ietf-mip6-bootstrapping-split-02.txt to address >>> bootstrapping from the home link. the proposal is to have this in a >>> new section before the security considerations section. >>> >>> 9. Bootstrapping from the home link >>> >>> The mechanisms described in this document also support a mobile node >>> bootstrapping from the home link. When the mobile node is on the >>> home link it receives router advertisements from the home agent with >>> the 'H' bit set and the 128 bit address of the home agent in the >>> modified prefix information option [RFC3775]. When the mobile node >>> bootstraps, the first operation it does is to perform a DNS lookup >>> for the home agent. >> >> Can MN do DNS lookup before having an Address? I guess no. So I doubt >> the first operation it does is to perform a DNS loookup for the HA. I >> think the first operation it does is to auto-configure an address. > > yes. I guess the current text is confusing. the fact > that the MN configures an address before doing a DNS > lookup was left implicit. Ok, implicit. And back to the multiple HA on the home link stuff... If the MN doesn't know it auto-configures a HoA or a CoA before doing DNS, wouldn't it be more appropriate to actually do a reverse dns lookup (not straight resolution) and check the resulting name against the HA name it pre-configured? Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 16:24:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY7b2-0006z3-OV; Mon, 24 Apr 2006 16:23:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY7b1-0006yt-Hp for mip6@ietf.org; Mon, 24 Apr 2006 16:23:47 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY7az-0008TI-8w for mip6@ietf.org; Mon, 24 Apr 2006 16:23:47 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3OKdgid003713; Mon, 24 Apr 2006 13:39:42 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k3OKeGFW012979; Mon, 24 Apr 2006 15:40:16 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id A05C4865980; Mon, 24 Apr 2006 22:22:55 +0200 (CEST) Message-ID: <444D339F.9010208@motorola.com> Date: Mon, 24 Apr 2006 22:22:55 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: Should the MN do reverse DNS lookup to check if at home? (was: [Mip6] Bootstrapping from the home link) References: <44498CEA.4050803@azairenet.com> <444CA5A6.7060905@motorola.com> <444D0FDE.508@azairenet.com> In-Reply-To: <444D0FDE.508@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: mip6@ietf.org, James Kempf X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Vijay, should the MN do reverse DNS lookup to check the name (resolved from the IP address it receives with H bit in RA) against the pre-configured HA address? It could help it decide whether it's at home or not. Alex Vijay Devarapalli wrote: > Alexandru Petrescu wrote: >> Vijay Devarapalli wrote: >>> hello, >>> >>> after some discussions offlist, we came up with some text that could >>> be added to draft-ietf-mip6-bootstrapping-split-02.txt to address >>> bootstrapping from the home link. the proposal is to have this in a >>> new section before the security considerations section. >>> >>> 9. Bootstrapping from the home link >>> >>> The mechanisms described in this document also support a mobile node >>> bootstrapping from the home link. When the mobile node is on the >>> home link it receives router advertisements from the home agent with >>> the 'H' bit set and the 128 bit address of the home agent in the >>> modified prefix information option [RFC3775]. When the mobile node >>> bootstraps, the first operation it does is to perform a DNS lookup >>> for the home agent. >> >> Can MN do DNS lookup before having an Address? I guess no. So I doubt >> the first operation it does is to perform a DNS loookup for the HA. I >> think the first operation it does is to auto-configure an address. > > yes. I guess the current text is confusing. the fact > that the MN configures an address before doing a DNS > lookup was left implicit. > >>> If at least one of the home agent address received in the DNS reply >> >> Isn't that a "DNS Response" or "answer" but not "reply"? > > will change it to "DNS Response". > > Vijay > >> >>> matches the address the mobile node received in the router >>> advertisement from the home agent, then the mobile node assumes it is >>> attached to the home link. >>> >>> For configuring a home address, the mobile node can either auto- >>> configure a home address, use DHCPv6 or run IKEv2 with its home agent >>> as described in section 5.3. >> >> Would MN auto-configure a Address first or decide first whether it >> is at home or not (and do DNS)? >> >> Alex > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 16:28:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY7fi-00082K-Bp; Mon, 24 Apr 2006 16:28:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY7fg-00081M-US for mip6@ietf.org; Mon, 24 Apr 2006 16:28:36 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY7fg-0000I2-Kl for mip6@ietf.org; Mon, 24 Apr 2006 16:28:36 -0400 Received: from [10.1.201.8] ([10.1.201.8]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Apr 2006 13:28:34 -0700 Message-ID: <444D34F3.8020701@azairenet.com> Date: Mon, 24 Apr 2006 13:28:35 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Alexandru Petrescu References: <44498CEA.4050803@azairenet.com> <444CA5A6.7060905@motorola.com> <444D0FDE.508@azairenet.com> <444D339F.9010208@motorola.com> In-Reply-To: <444D339F.9010208@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Apr 2006 20:28:34.0833 (UTC) FILETIME=[A90DE010:01C667DD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: mip6@ietf.org Subject: [Mip6] Re: Should the MN do reverse DNS lookup to check if at home? X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Alexandru Petrescu wrote: > Vijay, should the MN do reverse DNS lookup to check the name (resolved > from the IP address it receives with H bit in RA) against the > pre-configured HA address? It could help it decide whether it's at home > or not. that would work too. but then in the general case where the MN is mostly attached to visited link, we want the MN to always do a lookup for the HA's IP address instead of a reverse lookup. there could be local home agents on the access link and the MN could receive router advertisements with the 'H' bit set and the 128 bit home agent address. the MN might be better off doing a DNS lookup for the configured HA FQDN instead of reverse lookup for the IP address it received in the router advertisement. Vijay > > Alex > > Vijay Devarapalli wrote: >> Alexandru Petrescu wrote: >>> Vijay Devarapalli wrote: >>>> hello, >>>> >>>> after some discussions offlist, we came up with some text that could >>>> be added to draft-ietf-mip6-bootstrapping-split-02.txt to address >>>> bootstrapping from the home link. the proposal is to have this in a >>>> new section before the security considerations section. >>>> >>>> 9. Bootstrapping from the home link >>>> >>>> The mechanisms described in this document also support a mobile node >>>> bootstrapping from the home link. When the mobile node is on the >>>> home link it receives router advertisements from the home agent with >>>> the 'H' bit set and the 128 bit address of the home agent in the >>>> modified prefix information option [RFC3775]. When the mobile node >>>> bootstraps, the first operation it does is to perform a DNS lookup >>>> for the home agent. >>> >>> Can MN do DNS lookup before having an Address? I guess no. So I doubt >>> the first operation it does is to perform a DNS loookup for the HA. I >>> think the first operation it does is to auto-configure an address. >> >> yes. I guess the current text is confusing. the fact >> that the MN configures an address before doing a DNS >> lookup was left implicit. >> >>>> If at least one of the home agent address received in the DNS reply >>> >>> Isn't that a "DNS Response" or "answer" but not "reply"? >> >> will change it to "DNS Response". >> >> Vijay >> >>> >>>> matches the address the mobile node received in the router >>>> advertisement from the home agent, then the mobile node assumes it is >>>> attached to the home link. >>>> >>>> For configuring a home address, the mobile node can either auto- >>>> configure a home address, use DHCPv6 or run IKEv2 with its home agent >>>> as described in section 5.3. >>> >>> Would MN auto-configure a Address first or decide first whether it >>> is at home or not (and do DNS)? >>> >>> Alex >> > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 16:53:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY83Q-0003gL-6k; Mon, 24 Apr 2006 16:53:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY83O-0003gA-7r for mip6@ietf.org; Mon, 24 Apr 2006 16:53:06 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY83M-0001PX-U2 for mip6@ietf.org; Mon, 24 Apr 2006 16:53:06 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3OKqMN8008197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 24 Apr 2006 13:52:22 -0700 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3OKqJA9021923; Mon, 24 Apr 2006 13:52:21 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Apr 2006 13:52:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Bootstrapping on the home link Date: Mon, 24 Apr 2006 13:52:18 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF0023DD457@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Bootstrapping on the home link Thread-Index: AcZn0xeOZwDeEziKQ0CF2FB+0GsnLwADbiGA From: "Soliman, Hesham" To: "Alexandru Petrescu" X-OriginalArrivalTime: 24 Apr 2006 20:52:19.0090 (UTC) FILETIME=[F9FA3F20:01C667E0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: mip6@ietf.org, James Kempf , Vijay Devarapalli X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > That's why I'm suggesting to title this draft "DNS-based MIP6 MN > bootstrapping in split scenario" instead of the current all-covering > "MIP6 bootstrapping in split scenario". It leaves the place=20 > for other > drafts describing other deployments with "DHAAD-based MIP6 MN > bootstrapping in split scenario". Would you agree? =3D> I don't mind either way, it's pretty clear to me that it's = DNS-based. > > =3D> Yes but this is not specific to MIP6, it's a general issue for > > cert management. >=20 > Right, it's a general issue for cert management; it's still=20 > an issue and > the ephemerality of certs is the same as that of the pre-configured > prefixes. Would you agree? =3D> Nope. I think addresses are more likely to change.=20 Hesham >=20 > Alex >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 16:57:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY87z-0004a3-Ct; Mon, 24 Apr 2006 16:57:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY87x-0004Zy-Sg for mip6@ietf.org; Mon, 24 Apr 2006 16:57:49 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY87w-0001c6-Ix for mip6@ietf.org; Mon, 24 Apr 2006 16:57:49 -0400 Received: from [10.1.201.8] ([10.1.201.8]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Apr 2006 13:57:41 -0700 Message-ID: <444D3BC1.2020006@azairenet.com> Date: Mon, 24 Apr 2006 13:57:37 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: COMBES Jean-Michel RD-MAPS-ISS Subject: Re: [Mip6] Draft-dupont-ikev2-haassign-01.txt - Status References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Apr 2006 20:57:41.0936 (UTC) FILETIME=[BA68A300:01C667E1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org COMBES Jean-Michel RD-MAPS-ISS wrote: > Hi, > > I would like to know what is the status regarding the draft > 'draft-dupont-ikev2-haassign-01.txt'? an individual submission for now. Vijay > > Thanks in advance. > > Best regards. > > JMC. > > France Telecom - R&D Division - MAPS/NSS > Jean-Michel COMBES, Internet/Intranet Security > E-Mail: jeanmichel.combes@francetelecom.com > Phone: +33 (0)1 45 29 45 94 > Fax: +33 (0)1 45 29 65 19 > Mobile: +33 (0)6 07 29 30 16 > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 17:04:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY8EP-0006xa-U1; Mon, 24 Apr 2006 17:04:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY8EP-0006xV-IP for mip6@ietf.org; Mon, 24 Apr 2006 17:04:29 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY8EO-00022g-8R for mip6@ietf.org; Mon, 24 Apr 2006 17:04:29 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3OLLBVu010475; Mon, 24 Apr 2006 14:21:11 -0700 (MST) Received: from [144.189.73.141] (mvp-144-189-73-141.corp.mot.com [144.189.73.141]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id k3OLJ3c8022981; Mon, 24 Apr 2006 16:19:04 -0500 (CDT) Message-ID: <444D3D57.9050604@motorola.com> Date: Mon, 24 Apr 2006 23:04:23 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Vijay Devarapalli References: <44498CEA.4050803@azairenet.com> <444CA5A6.7060905@motorola.com> <444D0FDE.508@azairenet.com> <444D339F.9010208@motorola.com> <444D34F3.8020701@azairenet.com> In-Reply-To: <444D34F3.8020701@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: mip6@ietf.org Subject: [Mip6] Re: Should the MN do reverse DNS lookup to check if at home? X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Vijay Devarapalli wrote: > Alexandru Petrescu wrote: >> Vijay, should the MN do reverse DNS lookup to check the name >> (resolved from the IP address it receives with H bit in RA) against >> the pre-configured HA address? It could help it decide whether >> it's at home or not. > > that would work too. > > but then in the general case where the MN is mostly attached to > visited link, we want the MN to always do a lookup for the HA's IP > address instead of a reverse lookup. there could be local home agents > on the access link and the MN could receive router advertisements > with the 'H' bit set and the 128 bit home agent address. the MN might > be better off doing a DNS lookup for the configured HA FQDN instead > of reverse lookup for the IP address it received in the router > advertisement. Sorry, I do not get it. You do want the MN to do a IN AAAA resolution, ok but this does not preclude do the reverse resolution as well - it does not break anything. Why wouldn't MN do both the straight resolution on the pre-configured name _and_ the reverse resolution on the RA IP address? If it does both, then it avoids the situation where it should check the AAAA address it got from the initial straight resolution against _all_ the addresses in all the received RAs on a certain link. BTW, the current proposed text does not check against _all_ addresses: > If at least one of the home agent address received in the DNS reply > matches the address the mobile node received in the router ^ any of the > advertisement from the home agent, then the mobile node assumes it is > attached to the home link. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 17:10:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY8KJ-0007rs-GT; Mon, 24 Apr 2006 17:10:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY8KI-0007rn-F7 for mip6@ietf.org; Mon, 24 Apr 2006 17:10:34 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY8KH-0002Sa-7H for mip6@ietf.org; Mon, 24 Apr 2006 17:10:34 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3OLQgFr011327; Mon, 24 Apr 2006 14:26:42 -0700 (MST) Received: from [144.189.73.141] (mvp-144-189-73-141.corp.mot.com [144.189.73.141]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id k3OLOX41025777; Mon, 24 Apr 2006 16:24:34 -0500 (CDT) Message-ID: <444D3EA1.6040901@motorola.com> Date: Mon, 24 Apr 2006 23:09:53 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: changing title of the bootstrap-split draft to "DNS-based..." (was: [Mip6] Bootstrapping on the home link) References: <1487A357FD2ED544B8AD29E528FF9DF0023DD457@NAEX06.na.qualcomm.com> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF0023DD457@NAEX06.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: mip6@ietf.org, James Kempf , Vijay Devarapalli X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Soliman, Hesham wrote: > >> That's why I'm suggesting to title this draft "DNS-based MIP6 MN >> bootstrapping in split scenario" instead of the current >> all-covering "MIP6 bootstrapping in split scenario". It leaves the >> place for other drafts describing other deployments with >> "DHAAD-based MIP6 MN bootstrapping in split scenario". Would you >> agree? > > => I don't mind either way, it's pretty clear to me that it's > DNS-based. Ok, I understand you wouldn't oppose changing the title as I suggest above. >>> => Yes but this is not specific to MIP6, it's a general issue for >>> cert management. >> >> Right, it's a general issue for cert management; it's still an >> issue and the ephemerality of certs is the same as that of the >> pre-configured prefixes. Would you agree? > > => Nope. I think addresses are more likely to change. I think there are many situations where the domain names change and keep same IP addresses. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 17:10:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY8KS-0007tP-QG; Mon, 24 Apr 2006 17:10:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY8KR-0007sR-Jd for mip6@ietf.org; Mon, 24 Apr 2006 17:10:43 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY8KQ-0002Tw-A6 for mip6@ietf.org; Mon, 24 Apr 2006 17:10:43 -0400 Received: from [10.1.201.8] ([10.1.201.8]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Apr 2006 14:10:41 -0700 Message-ID: <444D3ECF.9080507@azairenet.com> Date: Mon, 24 Apr 2006 14:10:39 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Alexandru Petrescu References: <44498CEA.4050803@azairenet.com> <444CA5A6.7060905@motorola.com> <444D0FDE.508@azairenet.com> <444D339F.9010208@motorola.com> <444D34F3.8020701@azairenet.com> <444D3D57.9050604@motorola.com> In-Reply-To: <444D3D57.9050604@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Apr 2006 21:10:41.0238 (UTC) FILETIME=[8AE8AF60:01C667E3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: mip6@ietf.org Subject: [Mip6] Re: Should the MN do reverse DNS lookup to check if at home? X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Alexandru Petrescu wrote: > Vijay Devarapalli wrote: >> Alexandru Petrescu wrote: >>> Vijay, should the MN do reverse DNS lookup to check the name >>> (resolved from the IP address it receives with H bit in RA) against >>> the pre-configured HA address? It could help it decide whether it's >>> at home or not. >> >> that would work too. >> >> but then in the general case where the MN is mostly attached to >> visited link, we want the MN to always do a lookup for the HA's IP >> address instead of a reverse lookup. there could be local home agents >> on the access link and the MN could receive router advertisements >> with the 'H' bit set and the 128 bit home agent address. the MN might >> be better off doing a DNS lookup for the configured HA FQDN instead >> of reverse lookup for the IP address it received in the router >> advertisement. > > Sorry, I do not get it. You do want the MN to do a IN AAAA resolution, > ok but this does not preclude do the reverse resolution as well - it > does not break anything. the MN can do the reverse lookup yes. but in the most common case it might be the actual DNS lookup that would be most useful. > Why wouldn't MN do both the straight resolution on the pre-configured > name _and_ the reverse resolution on the RA IP address? at the same time? then its fine with me. > If it does both, then it avoids the situation where it should check the > AAAA address it got from the initial straight resolution against _all_ > the addresses in all the received RAs on a certain link. BTW, the > current proposed text does not check against _all_ addresses: > >> If at least one of the home agent address received in the DNS reply >> matches the address the mobile node received in the router > ^ > any of the ok. Vijay > >> advertisement from the home agent, then the mobile node assumes it is >> attached to the home link. > > Alex > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 17:19:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY8So-00039I-AE; Mon, 24 Apr 2006 17:19:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY8Sm-00039D-QS for mip6@ietf.org; Mon, 24 Apr 2006 17:19:20 -0400 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY8Sl-0003V4-E8 for mip6@ietf.org; Mon, 24 Apr 2006 17:19:20 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.10.03) with ESMTP id k3OLJ33Y024946; Mon, 24 Apr 2006 23:19:03 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [192.44.77.29]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.09.01) with ESMTP id k3OLIx4I024942; Mon, 24 Apr 2006 23:18:59 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id k3OLIwNK098713; Mon, 24 Apr 2006 23:18:58 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200604242118.k3OLIwNK098713@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Soliman, Hesham" Subject: Re: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt In-reply-to: Your message of Sun, 23 Apr 2006 15:31:34 PDT. <1487A357FD2ED544B8AD29E528FF9DF0023DCD1F@NAEX06.na.qualcomm.com> Date: Mon, 24 Apr 2006 23:18:58 +0200 X-Virus-Scanned: amavisd-new at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Gopal Dommety , mip6@ietf.org, jari.arkko@ericsson.com, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org In your previous mail you wrote: > => you want to use a transport mode with a HAO for the > tunneled traffic, > i.e.: > IPv6 header (src=CoA, dst=HA) > HAO (with HoA) > ESP header > IPv6 header (src=HoA, dst=*) > Payload > Is your proposal? B. For protecting payload traffic (VPN style) we can do the packet format you describe above. => so your proposal is some kind of "transport all" mode. I am not in favor of it because it adds a HAO to every packets. If we consider the HAO as a degenerate tunnel, it is a spurious double tunneling. Regards Francis.Dupont@point6.net _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 17:28:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY8bi-0007Ri-Pa; Mon, 24 Apr 2006 17:28:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY8bh-0007Rd-N6 for mip6@ietf.org; Mon, 24 Apr 2006 17:28:33 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY8bg-00046g-AZ for mip6@ietf.org; Mon, 24 Apr 2006 17:28:33 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id k3OLob5l003132; Mon, 24 Apr 2006 14:50:38 -0700 (MST) Received: from [144.189.73.141] (mvp-144-189-73-141.corp.mot.com [144.189.73.141]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id k3OLj5Sj010057; Mon, 24 Apr 2006 16:45:06 -0500 (CDT) Message-ID: <444D42F7.5010009@motorola.com> Date: Mon, 24 Apr 2006 23:28:23 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Vijay Devarapalli References: <44498CEA.4050803@azairenet.com> <444CA5A6.7060905@motorola.com> <444D0FDE.508@azairenet.com> <444D339F.9010208@motorola.com> <444D34F3.8020701@azairenet.com> <444D3D57.9050604@motorola.com> <444D3ECF.9080507@azairenet.com> In-Reply-To: <444D3ECF.9080507@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: mip6@ietf.org Subject: [Mip6] Re: Should the MN do reverse DNS lookup to check if at home? X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Vijay Devarapalli wrote: > Alexandru Petrescu wrote: >> Vijay Devarapalli wrote: >>> Alexandru Petrescu wrote: >>>> Vijay, should the MN do reverse DNS lookup to check the name >>>> (resolved from the IP address it receives with H bit in RA) >>>> against the pre-configured HA address? It could help it decide >>>> whether it's at home or not. >>> >>> that would work too. >>> >>> but then in the general case where the MN is mostly attached to >>> visited link, we want the MN to always do a lookup for the HA's >>> IP address instead of a reverse lookup. there could be local home >>> agents on the access link and the MN could receive router >>> advertisements with the 'H' bit set and the 128 bit home agent >>> address. the MN might be better off doing a DNS lookup for the >>> configured HA FQDN instead of reverse lookup for the IP address >>> it received in the router advertisement. >> >> Sorry, I do not get it. You do want the MN to do a IN AAAA >> resolution, ok but this does not preclude do the reverse resolution >> as well - it does not break anything. > > the MN can do the reverse lookup yes. but in the most common case it > might be the actual DNS lookup that would be most useful. Most useful, yes, but maybe less secure too. It's often safer to do both straight and reverse resolution for some name and address (in addition to the checks you described) and thus double-check the validity (some SMTP servers do); since not all deployed DNS is secure, there's a risk that the foreign network's DNS is propagating a rogue HA address. If you think this risk can be mitigated, think about the latest famous DNS attacks. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 17:41:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY8oM-00044d-Jd; Mon, 24 Apr 2006 17:41:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY8oM-00044Y-7C for mip6@ietf.org; Mon, 24 Apr 2006 17:41:38 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY8oK-0004kl-RC for mip6@ietf.org; Mon, 24 Apr 2006 17:41:38 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3OLfTSf013872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 24 Apr 2006 14:41:29 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3OLfNtx014286; Mon, 24 Apr 2006 14:41:28 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Apr 2006 14:41:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt Date: Mon, 24 Apr 2006 14:41:14 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF0023DD4FF@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt Thread-Index: AcZn5NXFhu2P+CfvQdyyHn0z6HrgKQAAq/gw From: "Soliman, Hesham" To: X-OriginalArrivalTime: 24 Apr 2006 21:41:16.0388 (UTC) FILETIME=[D0BE5A40:01C667E7] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Gopal Dommety , mip6@ietf.org, jari.arkko@ericsson.com, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > > =3D> you want to use a transport mode with a HAO for the=20 > > tunneled traffic, > > i.e.: > > IPv6 header (src=3DCoA, dst=3DHA) > > HAO (with HoA) > > ESP header > > IPv6 header (src=3DHoA, dst=3D*) > > Payload > > Is your proposal? > =20 > B. For protecting payload traffic (VPN style) we can do the packet > format you describe above.=20 > =20 > =3D> so your proposal is some kind of "transport all" mode. I am not > in favor of it because it adds a HAO to every packets. If we consider > the HAO as a degenerate tunnel, it is a spurious double tunneling. =3D> Well, if someone is bothered by the additional bits, they can compress it using any compression protocol we have today. you do that for the CN anyway. This is a tiny problem compared to what we have now IMO.=20 Hesham >=20 > Regards > =20 > Francis.Dupont@point6.net >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 17:43:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY8pq-0004xM-0q; Mon, 24 Apr 2006 17:43:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY8pp-0004w3-Iw for mip6@ietf.org; Mon, 24 Apr 2006 17:43:09 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY8po-0004qI-1k for mip6@ietf.org; Mon, 24 Apr 2006 17:43:09 -0400 Received: from [10.1.201.8] ([10.1.201.8]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Apr 2006 14:43:06 -0700 Message-ID: <444D466A.2060609@azairenet.com> Date: Mon, 24 Apr 2006 14:43:06 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Alexandru Petrescu References: <44498CEA.4050803@azairenet.com> <444CA5A6.7060905@motorola.com> <444D0FDE.508@azairenet.com> <444D339F.9010208@motorola.com> <444D34F3.8020701@azairenet.com> <444D3D57.9050604@motorola.com> <444D3ECF.9080507@azairenet.com> <444D42F7.5010009@motorola.com> In-Reply-To: <444D42F7.5010009@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Apr 2006 21:43:06.0854 (UTC) FILETIME=[12962060:01C667E8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: mip6@ietf.org Subject: [Mip6] Re: Should the MN do reverse DNS lookup to check if at home? X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Alexandru Petrescu wrote: >>> Sorry, I do not get it. You do want the MN to do a IN AAAA >>> resolution, ok but this does not preclude do the reverse resolution >>> as well - it does not break anything. >> >> the MN can do the reverse lookup yes. but in the most common case it >> might be the actual DNS lookup that would be most useful. > > Most useful, yes, but maybe less secure too. It's often safer to do > both straight and reverse resolution for some name and address (in > addition to the checks you described) and thus double-check the validity > (some SMTP servers do); here I assume you are talking about the MN on the visited link. since not all deployed DNS is secure, there's a > risk that the foreign network's DNS is propagating a rogue HA address. > If you think this risk can be mitigated, think about the latest famous > DNS attacks. question is, is this specific to MIP6? or is it a general concern with DNS? DNS lookup is used quite widely for many services. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 17:46:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY8su-0006y4-1P; Mon, 24 Apr 2006 17:46:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY8ss-0006xz-98 for mip6@ietf.org; Mon, 24 Apr 2006 17:46:18 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY8sr-000542-Rt for mip6@ietf.org; Mon, 24 Apr 2006 17:46:18 -0400 Message-ID: <02a201c667e9$338a4b60$026115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Alexandru Petrescu" , References: <444D1503.3020105@motorola.com> Subject: Re: [Mip6] Substitute "high risk" for "mitigated risk" in Security Considerations of draft-ietf-mip6-bootstrapping-split-02.txt Date: Mon, 24 Apr 2006 14:51:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > Per your request here are some comments and text suggestions on some parts > of the Security Considerations section of > draft-ietf-mip6-bootstrapping-split-02.txt. > >> The risk in Case 1 is mitigated because the Mobile Node is > ^^^^^^^^^ > Substitute "high" for "mitigated" because it is > very easy to set up an AP running DNS Server, HA and even fake CA, thus > fooling MN to send all its traffic to it. > >> Thus, an attacker would have to set up both a bogus DNS server and a >> bogus Home Agent, > > This leaves the reader with the impression that it is difficult to set > up a rogue laptop being AP, DNS, HA and CA. It's not: hostap, bind9, > mipl and open-ssl. > The key point here is that the MN needs to perform IKE with the home agent. If the home agent's cert fails to authenticate, the MN will know that there is a problem. The text further along in this section says that. >> and provision the Home Agent with a certificate that a victim Mobile Node >> could verify. > > Once the MN sends all its traffic to the rogue AP being CA, the MN will > query that CA about cert validity and the rogue CA will reply > positively, because it's rogue. > The MN has got a set of root certs that it will check the rogue CA's against. If it doesn't authenticate, then the MN will simply not use the bogus HA. >> If the Mobile Node can detect that the certificate is not trustworthy, > > That's a big IF. Do you have in mind a legitimate MN with two interfaces, > one spoofable and one completely secure? Because if the MN is attached > only to the rogue AP leading to a fake Internet, how could it securely > verify the certificate? > I have in mind a MN with a collection of root certs that it chains back to to check the HA's proffered cert. That is how IKE cert-checking works. If you think it would be clearer, I can spell this out, but we assumed a certain level of understanding about IKE and cert-checking when we wrote this, and it seems a bit redundant to have to repeat everything in the IKE document. >> the attack will be foiled when the Mobile Node attempts to set up the >> IKE SA. > > Yes, provided that big IF materializes into a yes. But I am pretty sure a > 802.11 laptop won't do normal traffic on one interface and security > verification traffic on another more secure interface. > > So I suggest substituting High for the Mitigated cited previously. > I'm not sure I understand what your point is. There is no need for two interfaces. All that's needed is IKE and the standard way IKE cert-checking is done. >> The risk in Case 2 is limited for a single Mobile Node to Home Agent >> transaction if the attacker does not possess proper credentials to >> authenticate with the Home Agent. The IKE SA establishment will fail when >> the attacking Mobile Node attempts to authenticate itself with the Home >> Agent. Regardless of whether the Home Agent utilizes EAP or host-side >> certificates to authenticate the Mobile Node, the authentication will >> fail unless the Mobile Node has valid credentials. > > I agree with this. However the previous risk is relatively high, not > mitigated. Would you agree? > See above. >> Explicit security measures between the DNS server and host, such DNSSEC >> [16] or TSIG/TKEY [17] [18] can mitigate the risk of 1) and 2), but these >> security measures are not widely deployed on end nodes. > > Substitute "1) and 2)" with "2) only" because I think it's easy to set-up > a fake DNS server appearing as DNSSEC to MN, with the laptop hostap I > described previously. > > Or maybe some text is needed in this section that states that the MN to > the first real IP hop (not virtual) connection is secured? There is no > such text currently here. I mean something about link-layer security? > Link layer security is won't help much. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 18:26:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY9VO-0005xN-Re; Mon, 24 Apr 2006 18:26:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY9U9-000547-Ed for mip6@ietf.org; Mon, 24 Apr 2006 18:24:49 -0400 Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY9SB-0007Rw-Ge for mip6@ietf.org; Mon, 24 Apr 2006 18:22:49 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id k3OMhsMr021898; Mon, 24 Apr 2006 15:43:54 -0700 (MST) Received: from [144.189.73.141] (mvp-144-189-73-141.corp.mot.com [144.189.73.141]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id k3OMdAMD005809; Mon, 24 Apr 2006 17:39:12 -0500 (CDT) Message-ID: <444D4FA4.8060602@motorola.com> Date: Tue, 25 Apr 2006 00:22:28 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: James Kempf Subject: Re: [Mip6] Substitute "high risk" for "mitigated risk" in Security Considerations of draft-ietf-mip6-bootstrapping-split-02.txt References: <444D1503.3020105@motorola.com> <02a201c667e9$338a4b60$026115ac@dcml.docomolabsusa.com> In-Reply-To: <02a201c667e9$338a4b60$026115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org James Kempf wrote: >> Per your request here are some comments and text suggestions on >> some parts of the Security Considerations section of >> draft-ietf-mip6-bootstrapping-split-02.txt. >> >>> The risk in Case 1 is mitigated because the Mobile Node is >> ^^^^^^^^^ Substitute "high" for "mitigated" because it is very easy >> to set up an AP running DNS Server, HA and even fake CA, thus >> fooling MN to send all its traffic to it. >> >>> Thus, an attacker would have to set up both a bogus DNS server >>> and a bogus Home Agent, >> >> This leaves the reader with the impression that it is difficult to >> set up a rogue laptop being AP, DNS, HA and CA. It's not: hostap, >> bind9, mipl and open-ssl. >> > > The key point here is that the MN needs to perform IKE with the home > agent. If the home agent's cert fails to authenticate, the MN will > know that there is a problem. The text further along in this section > says that. I've read that text, and still have doubts. >>> and provision the Home Agent with a certificate that a victim >>> Mobile Node could verify. >> >> Once the MN sends all its traffic to the rogue AP being CA, the MN >> will query that CA about cert validity and the rogue CA will reply >> positively, because it's rogue. >> > > The MN has got a set of root certs that it will check the rogue CA's All the root certs will point to the rogue AP. The HA will not understand messages coming from the MN (because encrypted with legitimate HA's or CA's public keys), but the MN will understand all messages coming from the rogue AP/HA/CA. The HA will tell MN "Binding Refresh Request", or "RA you're at home" or any other messages initiated by HA for which MN takes risky action like not using IKE. Do you think these attacks are feasible? I think so, and I think it's more than just DoS on MN. Because when MN believes it's at home it won't IKE with HA, won't encapsulate ESP, nothing. >>> If the Mobile Node can detect that the certificate is not >>> trustworthy, >> >> That's a big IF. Do you have in mind a legitimate MN with two >> interfaces, one spoofable and one completely secure? Because if >> the MN is attached only to the rogue AP leading to a fake Internet, >> how could it securely verify the certificate? >> > > I have in mind a MN with a collection of root certs that it chains > back to to check the HA's proffered cert. That is how IKE > cert-checking works. Yes, I guess so, but still much hurt can be provoked by HA sending packets to MN (even replaying responses maybe) without HA being able to understand whatever MN sends encrypted. > If you think it would be clearer, I can spell this out, but we > assumed a certain level of understanding about IKE and cert-checking > when we wrote this, and it seems a bit redundant to have to repeat > everything in the IKE document. I'll have to look at it, again. >>> the attack will be foiled when the Mobile Node attempts to set up >>> the IKE SA. >> >> Yes, provided that big IF materializes into a yes. But I am pretty >> sure a 802.11 laptop won't do normal traffic on one interface and >> security verification traffic on another more secure interface. >> >> So I suggest substituting High for the Mitigated cited previously. >> > > I'm not sure I understand what your point is. There is no need for > two interfaces. All that's needed is IKE and the standard way IKE > cert-checking is done. OCSP? Ok. >> Or maybe some text is needed in this section that states that the >> MN to the first real IP hop (not virtual) connection is secured? >> There is no such text currently here. I mean something about >> link-layer security? >> > > Link layer security is won't help much. I didn't know. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 18:27:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY9WQ-0006S9-Jd; Mon, 24 Apr 2006 18:27:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY9WO-0006Rz-Mn for mip6@ietf.org; Mon, 24 Apr 2006 18:27:08 -0400 Received: from [129.188.136.9] (helo=ftpbox.mot.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY9WN-0007n1-Dc for mip6@ietf.org; Mon, 24 Apr 2006 18:27:08 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by ftpbox.mot.com (8.12.11/Motgate7) with ESMTP id k3OMWcxq008237; Mon, 24 Apr 2006 17:32:39 -0500 (CDT) Received: from [144.189.73.141] (mvp-144-189-73-141.corp.mot.com [144.189.73.141]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id k3OMciGx008423; Mon, 24 Apr 2006 17:38:45 -0500 (CDT) Message-ID: <444D50B2.2030606@motorola.com> Date: Tue, 25 Apr 2006 00:26:58 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Vijay Devarapalli References: <44498CEA.4050803@azairenet.com> <444CA5A6.7060905@motorola.com> <444D0FDE.508@azairenet.com> <444D339F.9010208@motorola.com> <444D34F3.8020701@azairenet.com> <444D3D57.9050604@motorola.com> <444D3ECF.9080507@azairenet.com> <444D42F7.5010009@motorola.com> <444D466A.2060609@azairenet.com> In-Reply-To: <444D466A.2060609@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: mip6@ietf.org Subject: [Mip6] Re: Should the MN do reverse DNS lookup to check if at home? X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Vijay Devarapalli wrote: > Alexandru Petrescu wrote: > >>>> Sorry, I do not get it. You do want the MN to do a IN AAAA >>>> resolution, ok but this does not preclude do the reverse >>>> resolution as well - it does not break anything. >>> >>> the MN can do the reverse lookup yes. but in the most common case >>> it might be the actual DNS lookup that would be most useful. >> >> Most useful, yes, but maybe less secure too. It's often safer to >> do both straight and reverse resolution for some name and address >> (in addition to the checks you described) and thus double-check the >> validity (some SMTP servers do); > > here I assume you are talking about the MN on the visited link. YEs, both on visited and on home link, double-check DNS information by reverse resolving. The additional reverse resolving works fine because coherent information about names and IP addresses must be distributed from two different points on the Internet, into DNS. Just like MIP6 RR RO tests are assumed to offer better security than without. > since not all deployed DNS is secure, there's a >> risk that the foreign network's DNS is propagating a rogue HA >> address. If you think this risk can be mitigated, think about the >> latest famous DNS attacks. > > question is, is this specific to MIP6? or is it a general concern > with DNS? DNS lookup is used quite widely for many services. Question is, is DNS specific to SMTP? No, and that's why there's spam and safety reverse lookups. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 18:29:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY9Yw-0006d6-N4; Mon, 24 Apr 2006 18:29:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY9Yv-0006d1-Nw for mip6@ietf.org; Mon, 24 Apr 2006 18:29:45 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY9Yv-0007qK-Eu for mip6@ietf.org; Mon, 24 Apr 2006 18:29:45 -0400 Received: from [10.1.201.8] ([10.1.201.8]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Apr 2006 15:29:44 -0700 Message-ID: <444D5157.8040402@azairenet.com> Date: Mon, 24 Apr 2006 15:29:43 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Alexandru Petrescu References: <44498CEA.4050803@azairenet.com> <444CA5A6.7060905@motorola.com> <444D0FDE.508@azairenet.com> <444D339F.9010208@motorola.com> <444D34F3.8020701@azairenet.com> <444D3D57.9050604@motorola.com> <444D3ECF.9080507@azairenet.com> <444D42F7.5010009@motorola.com> <444D466A.2060609@azairenet.com> <444D50B2.2030606@motorola.com> In-Reply-To: <444D50B2.2030606@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Apr 2006 22:29:44.0302 (UTC) FILETIME=[95FED0E0:01C667EE] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: mip6@ietf.org Subject: [Mip6] Re: Should the MN do reverse DNS lookup to check if at home? X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Alexandru Petrescu wrote: > Vijay Devarapalli wrote: >> Alexandru Petrescu wrote: >> >>>>> Sorry, I do not get it. You do want the MN to do a IN AAAA >>>>> resolution, ok but this does not preclude do the reverse resolution >>>>> as well - it does not break anything. >>>> >>>> the MN can do the reverse lookup yes. but in the most common case >>>> it might be the actual DNS lookup that would be most useful. >>> >>> Most useful, yes, but maybe less secure too. It's often safer to do >>> both straight and reverse resolution for some name and address (in >>> addition to the checks you described) and thus double-check the >>> validity (some SMTP servers do); >> >> here I assume you are talking about the MN on the visited link. > > YEs, both on visited and on home link, double-check DNS information by > reverse resolving. > > The additional reverse resolving works fine because coherent information > about names and IP addresses must be distributed from two different > points on the Internet, into DNS. Just like MIP6 RR RO tests are > assumed to offer better security than without. > >> since not all deployed DNS is secure, there's a >>> risk that the foreign network's DNS is propagating a rogue HA >>> address. If you think this risk can be mitigated, think about the >>> latest famous DNS attacks. >> >> question is, is this specific to MIP6? or is it a general concern with >> DNS? DNS lookup is used quite widely for many services. > > Question is, is DNS specific to SMTP? No, and that's why there's spam > and safety reverse lookups. so what happens when the reverse lookup fails? support for the reverse tree is spotty in many cases. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 18:41:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY9ja-0007Nb-7g; Mon, 24 Apr 2006 18:40:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY9jZ-0007NW-9j for mip6@ietf.org; Mon, 24 Apr 2006 18:40:45 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY9jX-0008Cb-Ss for mip6@ietf.org; Mon, 24 Apr 2006 18:40:45 -0400 Message-ID: <02f201c667f0$c81af660$026115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Alexandru Petrescu" References: <444D1503.3020105@motorola.com> <02a201c667e9$338a4b60$026115ac@dcml.docomolabsusa.com> <444D4FA4.8060602@motorola.com> Subject: Re: [Mip6] Substitute "high risk" for "mitigated risk" in Security Considerations of draft-ietf-mip6-bootstrapping-split-02.txt Date: Mon, 24 Apr 2006 15:45:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > All the root certs will point to the rogue AP. The HA will not understand > messages coming from the MN (because encrypted with legitimate HA's or > CA's public keys), but the MN will understand all messages coming from the > rogue AP/HA/CA. The HA will tell MN "Binding Refresh Request", or "RA > you're at home" or any other messages initiated by HA for which MN takes > risky action like not using IKE. > The root certs are preprovisioned on the MN. These are the roots of trust. Unless the rogue AP can get a root cert into that set or somehow spoof one of the CAs in that set into issuing it a cert, the MN can determine if it is being faked. > Do you think these attacks are feasible? I think so, and I think it's > more than just DoS on MN. Because when MN believes it's at home it won't > IKE with HA, won't encapsulate ESP, nothing. > You are talking specifically about when the MN is at home? Then I'd say that the RA from the HA needs to have a SEND signature on it, and the MN needs to ask the HA for a cert chain using SEND CPS. It won't know from the cert that the router is an HA but having the 'H' bit on and the signature will provide assurance that the RA hasn't been modified in transit and that the orignator is a certified router. Maybe something should be said along these lines in Section 9? jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 18:43:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY9ls-00086U-FA; Mon, 24 Apr 2006 18:43:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY9lr-00086P-0g for mip6@ietf.org; Mon, 24 Apr 2006 18:43:07 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY9lo-0008H0-OL for mip6@ietf.org; Mon, 24 Apr 2006 18:43:04 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3OMxjpn023236; Mon, 24 Apr 2006 15:59:45 -0700 (MST) Received: from [144.189.73.141] (mvp-144-189-73-141.corp.mot.com [144.189.73.141]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id k3OMvaJX026817; Mon, 24 Apr 2006 17:57:37 -0500 (CDT) Message-ID: <444D5470.4090401@motorola.com> Date: Tue, 25 Apr 2006 00:42:56 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Vijay Devarapalli References: <44498CEA.4050803@azairenet.com> <444CA5A6.7060905@motorola.com> <444D0FDE.508@azairenet.com> <444D339F.9010208@motorola.com> <444D34F3.8020701@azairenet.com> <444D3D57.9050604@motorola.com> <444D3ECF.9080507@azairenet.com> <444D42F7.5010009@motorola.com> <444D466A.2060609@azairenet.com> <444D50B2.2030606@motorola.com> <444D5157.8040402@azairenet.com> In-Reply-To: <444D5157.8040402@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: mip6@ietf.org Subject: [Mip6] Re: Should the MN do reverse DNS lookup to check if at home? X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Vijay Devarapalli wrote: > Alexandru Petrescu wrote: >> Vijay Devarapalli wrote: >>> Alexandru Petrescu wrote: >>> >>>>>> Sorry, I do not get it. You do want the MN to do a IN AAAA >>>>>> resolution, ok but this does not preclude do the reverse >>>>>> resolution as well - it does not break anything. >>>>> >>>>> the MN can do the reverse lookup yes. but in the most common >>>>> case it might be the actual DNS lookup that would be most >>>>> useful. >>>> >>>> Most useful, yes, but maybe less secure too. It's often safer >>>> to do both straight and reverse resolution for some name and >>>> address (in addition to the checks you described) and thus >>>> double-check the validity (some SMTP servers do); >>> >>> here I assume you are talking about the MN on the visited link. >> >> YEs, both on visited and on home link, double-check DNS information >> by reverse resolving. >> >> The additional reverse resolving works fine because coherent >> information about names and IP addresses must be distributed from >> two different points on the Internet, into DNS. Just like MIP6 RR >> RO tests are assumed to offer better security than without. >> >>> since not all deployed DNS is secure, there's a >>>> risk that the foreign network's DNS is propagating a rogue HA >>>> address. If you think this risk can be mitigated, think about >>>> the latest famous DNS attacks. >>> >>> question is, is this specific to MIP6? or is it a general concern >>> with DNS? DNS lookup is used quite widely for many services. >> >> Question is, is DNS specific to SMTP? No, and that's why there's >> spam and safety reverse lookups. > > so what happens when the reverse lookup fails? support for the > reverse tree is spotty in many cases. It's spotty in some places because people don't deploy DNS correctly. With a correctly deployed DNS the reverse tree is right. We should go with the assumption that DNS is deployed correctly. IETF can't make assumptions on how certain protocols are deployed, can just suggest deployers how to do it. If the reverse lookup fails simply don't use that foreign network, drop all connections via it. It's same reasoning as with certs: if you don't have a cert backed by a some CA don't connect to me. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 18:59:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYA10-00045Q-Ts; Mon, 24 Apr 2006 18:58:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYA0z-000433-Lj for mip6@ietf.org; Mon, 24 Apr 2006 18:58:45 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYA0y-0000el-9E for mip6@ietf.org; Mon, 24 Apr 2006 18:58:45 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id k3ONKlqv004828; Mon, 24 Apr 2006 16:20:47 -0700 (MST) Received: from [144.189.73.141] (mvp-144-189-73-141.corp.mot.com [144.189.73.141]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id k3ONFEsf019423; Mon, 24 Apr 2006 18:15:15 -0500 (CDT) Message-ID: <444D5818.2030801@motorola.com> Date: Tue, 25 Apr 2006 00:58:32 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: James Kempf Subject: Re: [Mip6] Substitute "high risk" for "mitigated risk" in Security Considerations of draft-ietf-mip6-bootstrapping-split-02.txt References: <444D1503.3020105@motorola.com> <02a201c667e9$338a4b60$026115ac@dcml.docomolabsusa.com> <444D4FA4.8060602@motorola.com> <02f201c667f0$c81af660$026115ac@dcml.docomolabsusa.com> In-Reply-To: <02f201c667f0$c81af660$026115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org James Kempf wrote: >> All the root certs will point to the rogue AP. The HA will not >> understand messages coming from the MN (because encrypted with >> legitimate HA's or CA's public keys), but the MN will understand all >> messages coming from the rogue AP/HA/CA. The HA will tell MN "Binding >> Refresh Request", or "RA you're at home" or any other messages >> initiated by HA for which MN takes risky action like not using IKE. >> > > The root certs are preprovisioned on the MN. These are the roots of > trust. Unless the rogue AP can get a root cert into that set or somehow > spoof one of the CAs in that set into issuing it a cert, the MN can > determine if it is being faked. > > >> Do you think these attacks are feasible? I think so, and I think it's >> more than just DoS on MN. Because when MN believes it's at home it >> won't IKE with HA, won't encapsulate ESP, nothing. >> > > You are talking specifically about when the MN is at home? Yes, mainly. Rogue HA forcing legitimate MN at home means no IKE, no root certs verification, no ESP. Additionally, the rogue HA could gather two legitimate MNs under it, make them both believe they're under same subnet and at their respective homes (advertise two different prefixes), so communicate with their CoAs, so no IKE involved, no RR tests. While this communication, the rogue HA can listen all traffic between them. If both MNs bootstrapped via DNS, and DNS is rogue, this risk is related to this draft. > Then I'd say that the RA from the HA needs to have a SEND signature on > it, and the MN needs to ask the HA for a cert chain using SEND CPS. It > won't know from the cert that the router is an HA but having the 'H' bit > on and the signature will provide assurance that the RA hasn't been > modified in transit and that the orignator is a certified router. > > Maybe something should be said along these lines in Section 9? Yes. I hope it's realized that this brings SeND in the picture of secure bootstrapping, along with DNSSEC and IKE? I mean MN should run all that. And maybe something about the Binding Refresh Request too? There's no security check in 3775 about what does MN do when it receives a BRR. All it says is it should send a BU to its HA with its current location. I'm not sure though how to exploit this attack but there should be something about it. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 19:13:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYAFK-0006sS-7J; Mon, 24 Apr 2006 19:13:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYAFJ-0006s0-8n for mip6@ietf.org; Mon, 24 Apr 2006 19:13:33 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYAFI-0001Ff-V5 for mip6@ietf.org; Mon, 24 Apr 2006 19:13:33 -0400 Received: from [10.1.201.8] ([10.1.201.8]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Apr 2006 16:13:31 -0700 Message-ID: <444D5B9B.4010909@azairenet.com> Date: Mon, 24 Apr 2006 16:13:31 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Alexandru Petrescu References: <44498CEA.4050803@azairenet.com> <444CA5A6.7060905@motorola.com> <444D0FDE.508@azairenet.com> <444D339F.9010208@motorola.com> <444D34F3.8020701@azairenet.com> <444D3D57.9050604@motorola.com> <444D3ECF.9080507@azairenet.com> <444D42F7.5010009@motorola.com> <444D466A.2060609@azairenet.com> <444D50B2.2030606@motorola.com> <444D5157.8040402@azairenet.com> <444D5470.4090401@motorola.com> In-Reply-To: <444D5470.4090401@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Apr 2006 23:13:31.0581 (UTC) FILETIME=[B3F9C6D0:01C667F4] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: mip6@ietf.org Subject: [Mip6] Re: Should the MN do reverse DNS lookup to check if at home? X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Alexandru Petrescu wrote: >>>>>>> Sorry, I do not get it. You do want the MN to do a IN AAAA >>>>>>> resolution, ok but this does not preclude do the reverse >>>>>>> resolution as well - it does not break anything. >>>>>> >>>>>> the MN can do the reverse lookup yes. but in the most common case >>>>>> it might be the actual DNS lookup that would be most useful. >>>>> >>>>> Most useful, yes, but maybe less secure too. It's often safer to >>>>> do both straight and reverse resolution for some name and address >>>>> (in addition to the checks you described) and thus double-check the >>>>> validity (some SMTP servers do); >>>> >>>> here I assume you are talking about the MN on the visited link. >>> >>> YEs, both on visited and on home link, double-check DNS information >>> by reverse resolving. >>> >>> The additional reverse resolving works fine because coherent >>> information about names and IP addresses must be distributed from two >>> different points on the Internet, into DNS. Just like MIP6 RR RO >>> tests are assumed to offer better security than without. >>> >>>> since not all deployed DNS is secure, there's a >>>>> risk that the foreign network's DNS is propagating a rogue HA >>>>> address. If you think this risk can be mitigated, think about the >>>>> latest famous DNS attacks. >>>> >>>> question is, is this specific to MIP6? or is it a general concern >>>> with DNS? DNS lookup is used quite widely for many services. >>> >>> Question is, is DNS specific to SMTP? No, and that's why there's >>> spam and safety reverse lookups. >> >> so what happens when the reverse lookup fails? support for the reverse >> tree is spotty in many cases. > > It's spotty in some places because people don't deploy DNS correctly. > With a correctly deployed DNS the reverse tree is right. I can see this happening in say an Enterprise network. but not between operators and ISPs who have roaming agreements. We should go > with the assumption that DNS is deployed correctly. IETF can't make > assumptions on how certain protocols are deployed, can just suggest > deployers how to do it. > > If the reverse lookup fails simply don't use that foreign network, drop > all connections via it. this I dont agree with. I dont want MIP6 bootstrapping to fail if reverse lookup fails. > It's same reasoning as with certs: if you don't have a cert backed by a > some CA don't connect to me. but in this case, you dont use certs until you know you have the infrastructure in place. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 19:34:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYAZF-00008J-AZ; Mon, 24 Apr 2006 19:34:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYAZD-00008C-BE for mip6@ietf.org; Mon, 24 Apr 2006 19:34:07 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYAZB-00023z-10 for mip6@ietf.org; Mon, 24 Apr 2006 19:34:07 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3ONoaLt027044; Mon, 24 Apr 2006 16:50:36 -0700 (MST) Received: from [144.189.73.141] (mvp-144-189-73-141.corp.mot.com [144.189.73.141]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id k3ONlj9w021284; Mon, 24 Apr 2006 18:47:46 -0500 (CDT) Message-ID: <444D605B.5010904@motorola.com> Date: Tue, 25 Apr 2006 01:33:47 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Vijay Devarapalli References: <44498CEA.4050803@azairenet.com> <444CA5A6.7060905@motorola.com> <444D0FDE.508@azairenet.com> <444D339F.9010208@motorola.com> <444D34F3.8020701@azairenet.com> <444D3D57.9050604@motorola.com> <444D3ECF.9080507@azairenet.com> <444D42F7.5010009@motorola.com> <444D466A.2060609@azairenet.com> <444D50B2.2030606@motorola.com> <444D5157.8040402@azairenet.com> <444D5470.4090401@motorola.com> <444D5B9B.4010909@azairenet.com> In-Reply-To: <444D5B9B.4010909@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: mip6@ietf.org Subject: [Mip6] Re: Should the MN do reverse DNS lookup to check if at home? X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Vijay Devarapalli wrote: > Alexandru Petrescu wrote: > >>>>>>>> Sorry, I do not get it. You do want the MN to do a IN >>>>>>>> AAAA resolution, ok but this does not preclude do the >>>>>>>> reverse resolution as well - it does not break >>>>>>>> anything. >>>>>>> >>>>>>> the MN can do the reverse lookup yes. but in the most >>>>>>> common case it might be the actual DNS lookup that would >>>>>>> be most useful. >>>>>> >>>>>> Most useful, yes, but maybe less secure too. It's often >>>>>> safer to do both straight and reverse resolution for some >>>>>> name and address (in addition to the checks you described) >>>>>> and thus double-check the validity (some SMTP servers do); >>>>> >>>>> here I assume you are talking about the MN on the visited >>>>> link. >>>> >>>> YEs, both on visited and on home link, double-check DNS >>>> information by reverse resolving. >>>> >>>> The additional reverse resolving works fine because coherent >>>> information about names and IP addresses must be distributed >>>> from two different points on the Internet, into DNS. Just like >>>> MIP6 RR RO tests are assumed to offer better security than >>>> without. >>>> >>>>> since not all deployed DNS is secure, there's a >>>>>> risk that the foreign network's DNS is propagating a rogue >>>>>> HA address. If you think this risk can be mitigated, think >>>>>> about the latest famous DNS attacks. >>>>> >>>>> question is, is this specific to MIP6? or is it a general >>>>> concern with DNS? DNS lookup is used quite widely for many >>>>> services. >>>> >>>> Question is, is DNS specific to SMTP? No, and that's why >>>> there's spam and safety reverse lookups. >>> >>> so what happens when the reverse lookup fails? support for the >>> reverse tree is spotty in many cases. >> >> It's spotty in some places because people don't deploy DNS >> correctly. With a correctly deployed DNS the reverse tree is right. >> >> > > I can see this happening in say an Enterprise network. but not > between operators and ISPs who have roaming agreements. Not only Enterprise network. Many cell operator networks and wired ISPs for individuals. The reverse lookup working fine depends first and foremost on the owner of a certain domain setting up the reverse lookup for its assigned address space. If it doesn't, no foreign network can reverse resolve it. Some address space and domain owners would even ensure propagation of same DNS data from more than one place, for reliability. Thus, if the domain administering the HA propagates its inverse resolution then any foreign network should see it. If while in the foreign network MN doesn't see its home reverse DNS it's either because the home DNS is not set up correctly or because the foreign operator wouldn't allow reverse resolution for fear of inside DNS attacks. Many ISPs (wireless or wired) for individual customers forbid reverse resolution for security reasons. >> We should go with the assumption that DNS is deployed correctly. >> IETF can't make assumptions on how certain protocols are deployed, >> can just suggest deployers how to do it. >> >> If the reverse lookup fails simply don't use that foreign network, >> drop all connections via it. > > this I dont agree with. I dont want MIP6 bootstrapping to fail if > reverse lookup fails. I can assure you that in the case of SMTP spam, reverse lookups do get rid of a lot of spam. How about this then: if the reverse lookup fails then fallback to DHAAD, and if DHAAD fails then stop connecting to foreign network - how about that? Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 19:57:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYAvW-0008UE-MQ; Mon, 24 Apr 2006 19:57:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYAvV-0008U8-59 for mip6@ietf.org; Mon, 24 Apr 2006 19:57:09 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYAvU-0002bG-Sb for mip6@ietf.org; Mon, 24 Apr 2006 19:57:09 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3P0Dm4Z028594; Mon, 24 Apr 2006 17:13:49 -0700 (MST) Received: from [144.189.73.141] (mvp-144-189-73-141.corp.mot.com [144.189.73.141]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k3P0DutQ017448; Mon, 24 Apr 2006 19:13:57 -0500 (CDT) Message-ID: <444D65CC.2060006@motorola.com> Date: Tue, 25 Apr 2006 01:57:00 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: James Kempf References: <444D1503.3020105@motorola.com> <02a201c667e9$338a4b60$026115ac@dcml.docomolabsusa.com> <444D4FA4.8060602@motorola.com> <02f201c667f0$c81af660$026115ac@dcml.docomolabsusa.com> In-Reply-To: <02f201c667f0$c81af660$026115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: mip6@ietf.org Subject: [Mip6] Re: Should we assume SeND in foreign/visited networks? (was: Substitute "high risk" for "mitigated risk" in Security Considerations of draft-ietf-mip6-bootstrapping-split-02.txt) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org James Kempf wrote: >> All the root certs will point to the rogue AP. The HA will not >> understand messages coming from the MN (because encrypted with >> legitimate HA's or CA's public keys), but the MN will understand >> all messages coming from the rogue AP/HA/CA. The HA will tell MN >> "Binding Refresh Request", or "RA you're at home" or any other >> messages initiated by HA for which MN takes risky action like not >> using IKE. >> > > The root certs are preprovisioned on the MN. These are the roots of > trust. Unless the rogue AP can get a root cert into that set or > somehow spoof one of the CAs in that set into issuing it a cert, the > MN can determine if it is being faked. > > >> Do you think these attacks are feasible? I think so, and I think >> it's more than just DoS on MN. Because when MN believes it's at >> home it won't IKE with HA, won't encapsulate ESP, nothing. >> > > You are talking specifically about when the MN is at home? > > Then I'd say that the RA from the HA needs to have a SEND signature > on it, and the MN needs to ask the HA for a cert chain using SEND > CPS. James, I think I didn't make myself clear (if you got my message please skip this). It's the DNS bootstrapping method that tells MN whether it's at home or not. Clearly, a rogue AP/AR/DNS server can instruct a MN as apparently being at home. This indication doesn't involve cert verification, because comes from RA and DNS. You're proposing this attack be foiled by running SeND on the home network. But it should actually run on all foreign networks where MN attaches. To foil the attack, the MN shouldn't talk to any network that is not able to send SeND signatures on RAs. So, do you propose to assume SeND is deployed on many access networks? If not, I think the risk you and I described above should be evaluated as "high" and not "mitigated" in the section Security Considerations of the draft. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 21:46:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYCdY-00038O-Am; Mon, 24 Apr 2006 21:46:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYCdW-000381-G0 for mip6@ietf.org; Mon, 24 Apr 2006 21:46:42 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYCdT-0008Ak-7F for mip6@ietf.org; Mon, 24 Apr 2006 21:46:42 -0400 Received: from [10.1.201.8] ([10.1.201.8]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Apr 2006 18:46:37 -0700 Message-ID: <444D7F7D.6010204@azairenet.com> Date: Mon, 24 Apr 2006 18:46:37 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Alexandru Petrescu References: <44498CEA.4050803@azairenet.com> <444CA5A6.7060905@motorola.com> <444D0FDE.508@azairenet.com> <444D339F.9010208@motorola.com> <444D34F3.8020701@azairenet.com> <444D3D57.9050604@motorola.com> <444D3ECF.9080507@azairenet.com> <444D42F7.5010009@motorola.com> <444D466A.2060609@azairenet.com> <444D50B2.2030606@motorola.com> <444D5157.8040402@azairenet.com> <444D5470.4090401@motorola.com> <444D5B9B.4010909@azairenet.com> <444D605B.5010904@motorola.com> In-Reply-To: <444D605B.5010904@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Apr 2006 01:46:37.0245 (UTC) FILETIME=[170EDED0:01C6680A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: mip6@ietf.org Subject: [Mip6] Re: Should the MN do reverse DNS lookup to check if at home? X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Alexandru Petrescu wrote: > How about this then: if the reverse lookup fails then fallback to DHAAD, > and if DHAAD fails then stop connecting to foreign network - how about > that? but then this requires configuring the MN with the home prefix. this is not in the minimal set of configuration on the MN as described in the bootstrapping problem statement draft. I dont see a way out. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 24 22:15:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYD5F-0003Ye-OB; Mon, 24 Apr 2006 22:15:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYD5E-0003YZ-D9 for mip6@ietf.org; Mon, 24 Apr 2006 22:15:20 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYD5E-0001dg-14 for mip6@ietf.org; Mon, 24 Apr 2006 22:15:20 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3P2FGNR009223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 24 Apr 2006 19:15:16 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3P2FFId006706; Mon, 24 Apr 2006 19:15:15 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Apr 2006 19:15:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: summary of discussion was [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt Date: Mon, 24 Apr 2006 19:15:13 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF00247CF0C@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: summary of discussion was [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt Thread-Index: AcZn5NXFhu2P+CfvQdyyHn0z6HrgKQAJou5Q From: "Soliman, Hesham" To: X-OriginalArrivalTime: 25 Apr 2006 02:15:14.0719 (UTC) FILETIME=[16C09AF0:01C6680E] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: Gopal Dommety , Francis.Dupont@point6.net, jari.arkko@ericsson.com, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Folks,=20 I'm sure following this discussion was difficult for a lot of people, so here's a summary of what was discussed publicly and privately.=20 My understanding from the answers to my comments is that the intention of changing section 3 is to clarify something that is thought to be already=20 "implicitly" supported in the current specs. Other arguments for adding this new format included the privacy issue, VPN support and simplification or reduction of SAs.=20 I think we disagree on whether the format in section 3 is new or simply=20 a clarification of an existing format. I believe the BU format is clearly stated in section 11.7.1 in RFC 3775 and that the one in section 3 is a different format. I'm attaching the relevant part to the end of this email. I'm not against adding new things in general, we do that all the time.=20 However, my objections are (not in order of importance): - Defining a new format for the BU is outside the scope of this=20 doc which deals with making sure that MIP6 and IPsec (ng) work together. This does not involve defining new MIP6 messages.=20 - The privacy argument is weak for several reasons. There are already several approaches that address this in a more comprehensive manner. Doing things piecemeal will cause the overall solution to be heavier for no gain. Also, if we need to do something for privacy it should be done separately and a deeper discussion should take place. So why the rush? - Simplfiying things: Actually, things would be much simpler if we don't require a MIP6-IPsec API and K flags to detect what the MN can do. This=20 means that doing everything in transport mode with the HAO *is* the simpler option here and will reduce the number of SAs and work perfectly fine for the VPN=20 case. Vijay already stated that this will require the implementations to change,=20 I agree, but so would tunnel mode for the BU.=20 So here's what I'm suggesting:=20 1. Revert to the old section 3 in the previous version.=20 2. If the WG thinks that we need to define one mode for IPsec between the MN and HA, then the sensible way to go here is to use transport mode for all. If we decide that this is not needed then we can keep things as they are. I'm fine with either case.=20 Hesham Excerpt from 11.7.1 o The Home Registration (H) bit MUST be set in the Binding Update. o The Acknowledge (A) bit MUST be set in the Binding Update. o The packet MUST contain a Home Address destination option, giving the mobile node's home address for the binding. o The care-of address for the binding MUST be used as the Source Address in the packet's IPv6 header, unless an Alternate Care-of Address mobility option is included in the Binding Update. This option MUST be included in all home registrations, as the ESP protocol will not be able to protect care-of addresses in the IPv6 header. (Mobile IPv6 implementations that know they are using IPsec AH to protect a particular message might avoid this option. For brevity the usage of AH is not discussed in this document.) _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 25 01:19:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYFxh-0003Ot-NM; Tue, 25 Apr 2006 01:19:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYFxg-0003O8-6m for mip6@ietf.org; Tue, 25 Apr 2006 01:19:44 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYFxe-0001ox-SE for mip6@ietf.org; Tue, 25 Apr 2006 01:19:44 -0400 Received: from [10.1.210.16] ([10.1.210.16]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Apr 2006 22:19:40 -0700 Message-ID: <444DB16C.3050108@azairenet.com> Date: Mon, 24 Apr 2006 22:19:40 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: summary of discussion was [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt References: <1487A357FD2ED544B8AD29E528FF9DF00247CF0C@NAEX06.na.qualcomm.com> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF00247CF0C@NAEX06.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Apr 2006 05:19:40.0527 (UTC) FILETIME=[DA7CE7F0:01C66827] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: Gopal Dommety , mip6@ietf.org, Basavaraj Patil , jari.arkko@ericsson.com, Francis.Dupont@point6.net X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Soliman, Hesham wrote: > Folks, > > I'm sure following this discussion was difficult for a lot of people, > so here's a summary of what was discussed publicly and privately. unfortunately this isnt a summary. its how you saw the discussion. > My understanding from the answers to my comments is that the intention > of changing section 3 is to clarify something that is thought to be > already > "implicitly" supported in the current specs. more than "thought". we *know* it is implicitly supported because we wrote up the text in a specific way. moreover it is used. > - Defining a new format for the BU is outside the scope of this > doc which deals with making sure that MIP6 and IPsec (ng) work together. how to encapsulate a mip6 packet with an ESP header is actually very much in scope of this draft. > This does not involve defining new MIP6 messages. we are not defining new MIP6 messages. > - The privacy argument is weak for several reasons. There are already > several approaches that address this in a more comprehensive manner. > Doing > things piecemeal will cause the overall solution to be heavier for no > gain. > Also, if we need to do something for privacy it should be done > separately > and a deeper discussion should take place. So why the rush? the privacy solutions have actually advanced quite well. a tunnel BU is complementary to these solutions. the work is progressing quite well in mobopts and should make it to the MIP6 WG quite soon. the privacy problem statement is already a MIP6 WG document. it was initially written up in the mobopts group. http://www.ietf.org/internet-drafts/draft-ietf-mip6-location-privacy-ps-01.txt I dont know what "rush" you are talking about. > So here's what I'm suggesting: > > 1. Revert to the old section 3 in the previous version. you are asking for "status quo". I am afraid thats not an option. reverting to old section 3 leaves the format for tunnel mode BU ambiguous. thats what is being fixed here. > 2. If the WG thinks that we need to define one mode for IPsec > between the MN and HA, then the sensible way to go here is to > use transport mode for all. please write it up and propose it to the WG. I am fine with multiple ways of sending a BU. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 25 07:03:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYLJs-0003sg-Pn; Tue, 25 Apr 2006 07:03:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYLJr-0003sS-78 for mip6@ietf.org; Tue, 25 Apr 2006 07:02:59 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYKNz-0006CN-M7 for mip6@ietf.org; Tue, 25 Apr 2006 06:03:11 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FYK9u-000773-K3 for mip6@ietf.org; Tue, 25 Apr 2006 05:48:40 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3PA5KSi012239; Tue, 25 Apr 2006 03:05:20 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k3PA5tFM020998; Tue, 25 Apr 2006 05:05:56 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 9E0D8865980; Tue, 25 Apr 2006 11:48:32 +0200 (CEST) Message-ID: <444DF070.1070100@motorola.com> Date: Tue, 25 Apr 2006 11:48:32 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Vijay Devarapalli References: <44498CEA.4050803@azairenet.com> <444CA5A6.7060905@motorola.com> <444D0FDE.508@azairenet.com> <444D339F.9010208@motorola.com> <444D34F3.8020701@azairenet.com> <444D3D57.9050604@motorola.com> <444D3ECF.9080507@azairenet.com> <444D42F7.5010009@motorola.com> <444D466A.2060609@azairenet.com> <444D50B2.2030606@motorola.com> <444D5157.8040402@azairenet.com> <444D5470.4090401@motorola.com> <444D5B9B.4010909@azairenet.com> <444D605B.5010904@motorola.com> <444D7F7D.6010204@azairenet.com> In-Reply-To: <444D7F7D.6010204@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: -2.2 (--) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: mip6@ietf.org Subject: [Mip6] Re: Add home prefix to the minimal set of pre-config? (was: Should the MN do reverse DNS lookup to check if at home?) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Vijay Devarapalli wrote: > Alexandru Petrescu wrote: > >> How about this then: if the reverse lookup fails then fallback to >> DHAAD, and if DHAAD fails then stop connecting to foreign network - >> how about that? > > but then this requires configuring the MN with the home prefix. this > is not in the minimal set of configuration on the MN as described in > the bootstrapping problem statement draft. I agree, the home prefix is not currently in the minimal set of configuration of MN as described in the bootstrapping PS draft. > I dont see a way out. I suggest to add the home prefix in the list of pre-config data. This would help integrate DHAAD and MPD in the bootstrapping flow, with side effects of ensuring a higher level of security using DNS and facing renumbering events with MPD. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 25 07:06:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYLMr-00049Z-Bx; Tue, 25 Apr 2006 07:06:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYLMq-00048Y-En for mip6@ietf.org; Tue, 25 Apr 2006 07:06:04 -0400 Received: from nproxy.gmail.com ([64.233.182.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYLMo-000808-RT for mip6@ietf.org; Tue, 25 Apr 2006 07:06:04 -0400 Received: by nproxy.gmail.com with SMTP id l36so873093nfa for ; Tue, 25 Apr 2006 04:06:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=srlT265oJmMd0FXPHq8OaZ846Tseu9ZTOb77rtYiKqhn8YK+RZ0/CPPOfh6cBV25TGp3vdngN529jZlwL+iCYjvL4T9CNLJl6PcG1S0bbr8Q9IxKnYr85azcowBzTj+kZdvAzK+pnVTaQyLHwd/yN3ktPLxkRCqpHb4CZrZWLvc= Received: by 10.48.12.19 with SMTP id 19mr2954789nfl; Tue, 25 Apr 2006 04:06:01 -0700 (PDT) Received: by 10.49.40.20 with HTTP; Tue, 25 Apr 2006 04:06:01 -0700 (PDT) Message-ID: Date: Tue, 25 Apr 2006 13:06:01 +0200 From: "Gerardo Giaretta" To: "Alexandru Petrescu" Subject: Re: [Mip6] Comments while reading draft-ietf-mip6-bootstrapping-split-02.txt In-Reply-To: <444CD11C.2050807@motorola.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <444CD11C.2050807@motorola.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Alex, thank you very much for your questions and comments about tha draft. I'll try to reply to all comments below. On 4/24/06, Alexandru Petrescu wrote: > Dear authors of draft-ietf-mip6-bootstrapping-split-02.txt, I have read > the draft and I have several comments. > > > Mobile IPv6 [2] requires the Mobile Node to know its Home Agent > > Address, its own Home Address and the cryptographic materials (e.g. > > shared keys or certificates) needed to set up IPsec security > > associations with the Home Agent in order to protect Mobile IPv6 > > signaling. This is generally referred to as the Mobile IPv6 > > bootstrapping problem [4]. [...] Mobile IPv6 base protocol does not > > specify any method to automatically acquire this information, > > That is wrong from many respects. The first and foremost is with respect > to the HA address. rfc3775 does specify how to automatically acquire > the HA address - DHAAD. > I disagree. The paragraph simply mentions that the MN needs to know: - HA address - HoA - crypto materials This is described deeply in the bootstrapping PS draft (currently in IESG approval). The paragraph does not mention anything about what is in rfc3775 and what is not. > With respect to the Home Address, although rfc3775 does not > specify how MN could derive its Home Address, it still describes MPD > (Mobile Prefix Discovery) and the MPA (Advertisement) could be used by > MN to derive its Home Address by simple stateless auto-configuration. > Same comment as above, at least for this first paragraph. However, it seems that your comment on DHAAD and MPD is related to the whole specification and not only to this paragraph. During the DT discussion, we have discussed a lot about DHAAD as possible dynamic HA discovery mechanism. You can find the DT discussion archives at http://vesuvio.ipv6.cselt.it/pipermail/mip6-boot-sol/ I will try to give more details on this topic below. Note however that the draft is not deprecating DHAAD nor MPD. The draft is specifying a bootstrapping procedure that the WG thinks it is needed, even though someone may keep using DHAAD. > With respect to the crypto material, the certificates more specifically. > Neither Mobile IPv6 nor any other method I'm aware off will allow MN to > "automatically" acquire a cert. To acquire a cert one must prove > its/his/her identity with an out-of-band method, non-automatisable. > > So stating that the bootstrapping problem lies in the fact that Mobile > IPv6 can't distribute certs makes one think that a solution to that > problem may be this draft which will help to distribute certs. It doesn'= t. > certs are one example. The main mechanism described in the documet relies on IKEv2+EAP. What you mention is that the credentials (e.g. certs, SIM card) need to be distributed to the MNs; I agree, but I think this is acceptable. > > which means that network administrators are normally required to > > manually set configuration data on Mobile Nodes and HAs. However, in > > real deployments, manual configuration does not scale as the Mobile > > Nodes increase in number. > > This leaves the reader the impression that while by RFC3775 the admins > will need to manually configure data on MN, this spec would require no > such pre-configuration, thus apparently more scalable. The first part > is plain wrong. This spec does require the pre-configuration of > something: the HA FQDN. Should be acknowledged here, not deep in the > document. > > The second part (the one that gives the impression that pre-configuring > data on MN is not scaling with the number of MNs) suddenly becomes a > non-supportive argument for this draft. Because if pre-configuring data > on MN is not scalable then pre-configuring the FQDN is not scalable eithe= r. > > Moreover, this spec requires additional data to be pre-configured on the > MN, not just the domain name. It's the certificates. They must be > pre-configured on MN in order to somehow avoid the fallacies of the > still insecure HA Discovery phase (as opposed to the insecure DHAAD). > As mentioned, I would like to rule out from this discussion the configuration of credentials. There are several ways to provide users with the right credentials and this is a common problem to all bootstrapping solutions. Concerning configuration of FQDN, you are right. The draft is based on the configuration of a FQDN of the MSP on the MN. The idea is that this is less cumbersome than configuring IPv6 addresses, in my view for two reasons: FQDN are more user friendly and do not change, whereas IPv6 home link prefixes might change. > (There is no automatic way to securely distribute certificates to MNs, > so this must be a pre-configuration too.) > > > o HA address discovery. The Mobile Node needs to discover the > > address of its Home Agent. The main objective of a bootstrapping > > solution is to minimize the data pre-configured on the Mobile Node. > > Ok, so the objective is to minimize the data pre-configured on the MN. > The objective is to design a bootstrapping solution that is scalable. The list of detailed goals is provided in the PS draft. > > For this reason, the DHAAD defined in [2] may not be applicable in > > real deployments since it is required that the Mobile Node is > > pre-configured with the home network prefix > > Ok, so pre-configuring the home network prefix on the MN is not minimal. > > > and it does not allow an operator to load balance by having Mobile > > Nodes dynamically assigned to Home Agents located in different > > subnets. > > But was load balancing an objective? The objective was to minimize > pre-configured data, not to offer load balancing capability. > This is a second-priority goal. This is something that you may simply achieve using FQDNs. > > This document defines a solution for Home Agent address discovery > > that is based on Domain Name Service (DNS), introducing a new DNS SRV > > record [5]. The unique information that needs to be pre-configured > > on the Mobile Node is the domain name of the MSP. > > So there is a need to pre-configure data on the MN, except that this > time we pre-configure the domain name instead of the home prefix. > > Is pre-configuring the domain name more minimal than pre-configuring the > home prefix? I don't think we can talk in absolute terms here. In > terms of memory required, a prefix can take maximum 39 ASCII characters > while a domain name may take any length ("domain" in domain.com can have > up to 255 characters). So apparently pre-configuring a prefix could be > shorter than pre-configuring a domain name. > I think there is a clear difference: home prefixes might change. Moreover a DNS-based solution gives the flexibility to network operators to have different home prefixes and not only a fixed one. > > An optional part of bootstrapping involves providing a way for the > > Mobile Node to have its FQDN updated in the DNS with a dynamically > > assigned home address. > > More correct language would be to update the IN Resource Record > corresponding to its permanent FQDN. Because "updating the FQDN with > something" may be read as changing the FQDN. It doesn't change normally. > > > The Mobile Node needs to obtain the IP address of the DNS server > > before it can send a DNS request. This can be pre-configured on the > > Mobile Node or obtained through DHCPv6 from the visited link [11]. > > "DNS server pre-configured on the MN"? More data pre-configured? > Remark this would come in addition to the domain name pre-configured on > the MN. > > But I do agree the DNS server address could come from the local DHCP serv= er. > Good. So are you suggesting we should rephrase? Can you come up with a proposed text? > > In this case, the Mobile Node is configured with the Fully Qualified > > Domain Name of the Home Agent. As an example, the Mobile Node could > > be configured with the name "ha1.example.com", where "example.com" is > > the domain name of the MSP granting the mobility service. > > I find this method relatively more flexible than the method SRV RR, > because it allows a specific HA to be associated to a specific subnet in > example.com (the SRV method doesn't). However, it's still data to be > pre-configured on the MN, just like the home prefix. > > > The service name for Mobile IPv6 Home Agent service as required by > > RFC 2782 is "mip6" and the protocol name is "ipv6". Note that a > > transport name cannot be used here because Mobile IPv6 does not run > > over a transport protocol. > > Would this require modifications to rfc2782 to explain that the Port > number in a SRV RR be optional? > > The second question is: do we need IANA action for being able to use the > service name in SRV "mip6" ? Because the IANA Considerations section > doesn't seem to mention it. > > > The SRV RR has a DNS type code of 33. As an example, the Mobile > > constructs a request with QNAME set to "_mip6._ipv6.example.com" and > > QTYPE to SRV. > > Thus, for a given domain example.com only one HA will be sent back by > DNS to MN. Presumably, in a domain there are several subnets, and > various MNs have various subnets as their homes, all in the same domain. > How would DNS resolve the right HA for the right MN when the only key > used is "_mip6._ipv6"? > Vijay already replied to this. So, it seems that your main concern is related to the fact that DHAAD is not considered in this draft. I think that DHAAD is not deprecated by this draft, simply there are deployment scenarios where a DNS-based (or a DHCP-based for integrated scenario) solution is considered more useful. Would you suggest any way to improve the draft? Thanks, --Gerardo > Alex > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 25 09:18:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYNRD-0004jd-TS; Tue, 25 Apr 2006 09:18:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYNRC-0004jY-86 for mip6@ietf.org; Tue, 25 Apr 2006 09:18:42 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYNR9-000868-M0 for mip6@ietf.org; Tue, 25 Apr 2006 09:18:42 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id k3PDVo7h017918; Tue, 25 Apr 2006 06:31:50 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id k3PDeoFr001876; Tue, 25 Apr 2006 08:40:51 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 2F9CF8637E6; Tue, 25 Apr 2006 15:18:33 +0200 (CEST) Message-ID: <444E21A8.1020000@motorola.com> Date: Tue, 25 Apr 2006 15:18:32 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Gerardo Giaretta Subject: Re: [Mip6] Comments while reading draft-ietf-mip6-bootstrapping-split-02.txt References: <444CD11C.2050807@motorola.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Gerardo, thanks for the reply. Gerardo Giaretta wrote: > Hi Alex, > > thank you very much for your questions and comments about tha draft. > I'll try to reply to all comments below. > > On 4/24/06, Alexandru Petrescu > wrote: >> Dear authors of draft-ietf-mip6-bootstrapping-split-02.txt, I have >> read the draft and I have several comments. >> >>> Mobile IPv6 [2] requires the Mobile Node to know its Home Agent >>> Address, its own Home Address and the cryptographic materials >>> (e.g. shared keys or certificates) needed to set up IPsec >>> security associations with the Home Agent in order to protect >>> Mobile IPv6 signaling. This is generally referred to as the >>> Mobile IPv6 bootstrapping problem [4]. [...] Mobile IPv6 base >>> protocol does not specify any method to automatically acquire >>> this information, >> That is wrong from many respects. The first and foremost is with >> respect to the HA address. rfc3775 does specify how to >> automatically acquire the HA address - DHAAD. >> > > I disagree. The paragraph simply mentions that the MN needs to know: > - HA address - HoA - crypto materials This is described deeply in > the bootstrapping PS draft (currently in IESG approval). The > paragraph does not mention anything about what is in rfc3775 and what > is not. But the text says this: >>> Mobile IPv6 base protocol does not specify any method to >>> automatically acquire this information That is plain wrong, MIP6 does specify such things. Please remove this phrase. > I will try to give more details on this topic below. Note however > that the draft is not deprecating DHAAD nor MPD. The draft is > specifying a bootstrapping procedure that the WG thinks it is needed, > even though someone may keep using DHAAD. Ok. May I also see it the other way around: someone may use the DNS-based bootstrapping method but the WG thought at some point that the 3775 was to become an RFC. >> With respect to the crypto material, the certificates more >> specifically. Neither Mobile IPv6 nor any other method I'm aware >> off will allow MN to "automatically" acquire a cert. To acquire a >> cert one must prove its/his/her identity with an out-of-band >> method, non-automatisable. >> >> So stating that the bootstrapping problem lies in the fact that >> Mobile IPv6 can't distribute certs makes one think that a solution >> to that problem may be this draft which will help to distribute >> certs. It doesn't. >> > > certs are one example. The main mechanism described in the documet > relies on IKEv2+EAP. What you mention is that the credentials (e.g. > certs, SIM card) need to be distributed to the MNs; I agree, but I > think this is acceptable. Yes, but is it scalable? >>> which means that network administrators are normally required to >>> manually set configuration data on Mobile Nodes and HAs. >>> However, in real deployments, manual configuration does not scale >>> as the Mobile Nodes increase in number. >> This leaves the reader the impression that while by RFC3775 the >> admins will need to manually configure data on MN, this spec would >> require no such pre-configuration, thus apparently more scalable. >> The first part is plain wrong. This spec does require the >> pre-configuration of something: the HA FQDN. Should be >> acknowledged here, not deep in the document. >> >> The second part (the one that gives the impression that >> pre-configuring data on MN is not scaling with the number of MNs) >> suddenly becomes a non-supportive argument for this draft. Because >> if pre-configuring data on MN is not scalable then pre-configuring >> the FQDN is not scalable either. >> >> Moreover, this spec requires additional data to be pre-configured >> on the MN, not just the domain name. It's the certificates. They >> must be pre-configured on MN in order to somehow avoid the >> fallacies of the still insecure HA Discovery phase (as opposed to >> the insecure DHAAD). >> > > As mentioned, I would like to rule out from this discussion the > configuration of credentials. There are several ways to provide users > with the right credentials and this is a common problem to all > bootstrapping solutions. Ok, I agree. > Concerning configuration of FQDN, you are right. The draft is based > on the configuration of a FQDN of the MSP on the MN. The idea is that > this is less cumbersome than configuring IPv6 addresses, in my view > for two reasons: FQDN are more user friendly and do not change, > whereas IPv6 home link prefixes might change. Please mention in the draft the reasoning that FQDN is more user friendly than IP addresses and that FQDN would change less frequently than the prefix. >>> o HA address discovery. The Mobile Node needs to discover the >>> address of its Home Agent. The main objective of a bootstrapping >>> solution is to minimize the data pre-configured on the Mobile >>> Node. >> Ok, so the objective is to minimize the data pre-configured on the >> MN. >> > > The objective is to design a bootstrapping solution that is scalable. > The list of detailed goals is provided in the PS draft. I've read that. As with "minimal", "Scalable" is not defined. "Scalable" doesn't even appear in the PS text. Scalable of what with respect to what? Do you have a rough idea about what "scalable" is? Other than just claiming it as an advantage of a proposed method over a vaguely assummed non-scalable method? In some contexts, it's like this: the effort to locally maintain name-address association (/etc/hosts) at each site about each other site grows exponentially with the number of sites. It doesn't scale. The effort to distributely maintain that database with DNS grows linearly with the number of sites. That's more scalable. So what is "scalable" in the context of DNS-based bootstrapping? Is it more scalable to pre-configure fqdn instead of prefixes? No. What is exactly scalable about the DNS-based bootstrapping? >>> For this reason, the DHAAD defined in [2] may not be applicable >>> in real deployments since it is required that the Mobile Node is >>> pre-configured with the home network prefix >> Ok, so pre-configuring the home network prefix on the MN is not >> minimal. >> >>> and it does not allow an operator to load balance by having >>> Mobile Nodes dynamically assigned to Home Agents located in >>> different subnets. >> But was load balancing an objective? The objective was to minimize >> pre-configured data, not to offer load balancing capability. >> > > This is a second-priority goal. Ok. > This is something that you may simply achieve using FQDNs. It's not sufficient to just use FQDNs to move some MN from one HA to another, in a different subnet. There's need for protocols that haven't been specified too. >>> This document defines a solution for Home Agent address discovery >>> that is based on Domain Name Service (DNS), introducing a new >>> DNS SRV record [5]. The unique information that needs to be >>> pre-configured on the Mobile Node is the domain name of the MSP. >> So there is a need to pre-configure data on the MN, except that >> this time we pre-configure the domain name instead of the home >> prefix. >> >> Is pre-configuring the domain name more minimal than >> pre-configuring the home prefix? I don't think we can talk in >> absolute terms here. In terms of memory required, a prefix can >> take maximum 39 ASCII characters while a domain name may take any >> length ("domain" in domain.com can have up to 255 characters). So >> apparently pre-configuring a prefix could be shorter than >> pre-configuring a domain name. >> > > I think there is a clear difference: home prefixes might change. Domain names might change too. A known peninsular operator research arm changed just recently, you must be aware of it. > Moreover a DNS-based solution gives the flexibility to network > operators to have different home prefixes and not only a fixed one. I hope the operators are aware that with that flexibility comes also the lack of session continuity. I can explain separately if needed. >>> The Mobile Node needs to obtain the IP address of the DNS server >>> before it can send a DNS request. This can be pre-configured on >>> the Mobile Node or obtained through DHCPv6 from the visited link >>> [11]. >> "DNS server pre-configured on the MN"? More data pre-configured? >> Remark this would come in addition to the domain name >> pre-configured on the MN. >> >> But I do agree the DNS server address could come from the local >> DHCP server. >> > > Good. So are you suggesting we should rephrase? Can you come up with > a proposed text? Please remove the entire paragraph stating that MN could be pre-configured with the DNS Server address (of all visited networks) or obtained with DHCP. > So, it seems that your main concern is related to the fact that DHAAD > is not considered in this draft. I think that DHAAD is not > deprecated by this draft, simply there are deployment scenarios where > a DNS-based (or a DHCP-based for integrated scenario) solution is > considered more useful. We seem to be talking past each other. But I agree with you that there are deployments that may need this solution. But just don't say there's a problem because MIP6 doesn't do this and that. Some deployments need something different than what exists not because what exists don't satisfy them, but because what these deployment prefer is more scalable and more minimal. > Would you suggest any way to improve the draft? As I said above: (1) please define "scalable" and "minimal", (2) please remove the phrase in the introduction saying MIP6 doesn't deliver the HA address to the MN (3) please remove the text saying the DNS server address could be pre-configured on the MN or obtained by DHCP and (4) please mention in the draft that you've decided to use FQDN instead of IP addresses as pre-config data because they're more user-friendly and change less often. In two separate threads I also suggest: (1) please change the title to "DNS-based..." and (2) do double-check with straight and reverse DNS resolution whenever querying the DNS. Thanks, Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 25 09:21:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYNTg-0005l8-8e; Tue, 25 Apr 2006 09:21:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYNTf-0005iy-1w for mip6@ietf.org; Tue, 25 Apr 2006 09:21:15 -0400 Received: from smtpproxy2.mitre.org ([192.80.55.71] helo=smtp-mclean.mitre.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYNTd-0008CR-NC for mip6@ietf.org; Tue, 25 Apr 2006 09:21:15 -0400 Received: from smtp-mclean.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-mclean.mitre.org (8.12.11.20060308/8.12.11) with SMTP id k3PDL1kZ002737 for ; Tue, 25 Apr 2006 09:21:01 -0400 Received: from smtp-mclean.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-mclean.mitre.org (Postfix) with ESMTP id 4CDF71BD82 for ; Tue, 25 Apr 2006 09:21:01 -0400 (EDT) Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-mclean.mitre.org (8.12.11.20060308/8.12.11) with ESMTP id k3PDKusO002661 for ; Tue, 25 Apr 2006 09:20:56 -0400 Received: from IMCSRV3.MITRE.ORG ([129.83.20.198]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Apr 2006 09:20:55 -0400 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 25 Apr 2006 09:20:55 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: unsubscribe Thread-Index: AcZoaxUbQAWFonYkREmeeGJBedpApw== From: "Nour, Nina N." To: X-OriginalArrivalTime: 25 Apr 2006 13:20:55.0981 (UTC) FILETIME=[159985D0:01C6686B] X-Spam-Score: 0.2 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Subject: [Mip6] unsubscribe X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0154593919==" Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============0154593919== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6686B.15A21D14" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6686B.15A21D14 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please delete my email from this list. Thank you. ------_=_NextPart_001_01C6686B.15A21D14 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please delete my email from this list.  Thank = you.

------_=_NextPart_001_01C6686B.15A21D14-- --===============0154593919== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0154593919==-- From mip6-bounces@ietf.org Tue Apr 25 10:13:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYOIM-0004ot-U3; Tue, 25 Apr 2006 10:13:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYOIL-0004ol-3K for mip6@ietf.org; Tue, 25 Apr 2006 10:13:37 -0400 Received: from nproxy.gmail.com ([64.233.182.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYOIK-0002Di-Gq for mip6@ietf.org; Tue, 25 Apr 2006 10:13:37 -0400 Received: by nproxy.gmail.com with SMTP id l36so903352nfa for ; Tue, 25 Apr 2006 07:13:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ryWQKrDj3Wp4w13iArdHSiIv5RTun3hoF6ZJcvg3V61iiIsa30oJ+oWTjyxSJ2pBa0x+jzh9MVGZW5vVWVNZGVrR+6kVhS/DztYmRArU+W5i+v0FDcl255h/M5Mlqdie3u2NInEKy4FG23prd7CQBSrufDPYWdgzVI35mBQMXsY= Received: by 10.49.14.20 with SMTP id r20mr404280nfi; Tue, 25 Apr 2006 07:13:34 -0700 (PDT) Received: by 10.49.40.20 with HTTP; Tue, 25 Apr 2006 07:13:34 -0700 (PDT) Message-ID: Date: Tue, 25 Apr 2006 16:13:34 +0200 From: "Gerardo Giaretta" To: "Alexandru Petrescu" Subject: Re: [Mip6] Comments while reading draft-ietf-mip6-bootstrapping-split-02.txt In-Reply-To: <444E21A8.1020000@motorola.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <444CD11C.2050807@motorola.com> <444E21A8.1020000@motorola.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > >>> Mobile IPv6 [2] requires the Mobile Node to know its Home Agent > >>> Address, its own Home Address and the cryptographic materials > >>> (e.g. shared keys or certificates) needed to set up IPsec > >>> security associations with the Home Agent in order to protect > >>> Mobile IPv6 signaling. This is generally referred to as the > >>> Mobile IPv6 bootstrapping problem [4]. [...] Mobile IPv6 base > >>> protocol does not specify any method to automatically acquire > >>> this information, > >> That is wrong from many respects. The first and foremost is with > >> respect to the HA address. rfc3775 does specify how to > >> automatically acquire the HA address - DHAAD. > >> > > > > I disagree. The paragraph simply mentions that the MN needs to know: > > - HA address - HoA - crypto materials This is described deeply in > > the bootstrapping PS draft (currently in IESG approval). The > > paragraph does not mention anything about what is in rfc3775 and what > > is not. > > But the text says this: > >>> Mobile IPv6 base protocol does not specify any method to > >>> automatically acquire this information > > That is plain wrong, MIP6 does specify such things. Please remove this > phrase. > rfc3775 specifies a discovery mechanism based on MN knowing the home link prefix. This is something is not needed in bootstrapping solutions and I think the PS document is quite clear. However, if you think it is needed, we can state that in some scenarios netwrok operators may still rely on DHAAD, if all MNs are configured with home link prefixes. > > I will try to give more details on this topic below. Note however > > that the draft is not deprecating DHAAD nor MPD. The draft is > > specifying a bootstrapping procedure that the WG thinks it is needed, > > even though someone may keep using DHAAD. > > Ok. May I also see it the other way around: someone may use the > DNS-based bootstrapping method but the WG thought at some point that the > 3775 was to become an RFC. > And then WG chairs decided to have a DT to solve the bootstrapping problem = :) You may like DHAAD more than DNS-based discovery: that's ok, no problem to me. This is why I'm not in favor of deprecating DHAAD. > >> With respect to the crypto material, the certificates more > >> specifically. Neither Mobile IPv6 nor any other method I'm aware > >> off will allow MN to "automatically" acquire a cert. To acquire a > >> cert one must prove its/his/her identity with an out-of-band > >> method, non-automatisable. > >> > >> So stating that the bootstrapping problem lies in the fact that > >> Mobile IPv6 can't distribute certs makes one think that a solution > >> to that problem may be this draft which will help to distribute > >> certs. It doesn't. > >> > > > > certs are one example. The main mechanism described in the documet > > relies on IKEv2+EAP. What you mention is that the credentials (e.g. > > certs, SIM card) need to be distributed to the MNs; I agree, but I > > think this is acceptable. > > Yes, but is it scalable? > Judging from the number of GSM terminals in the world, I think that having a SIM card with the configured credentials in it, it's quite scalable. > >> Moreover, this spec requires additional data to be pre-configured > >> on the MN, not just the domain name. It's the certificates. They > >> must be pre-configured on MN in order to somehow avoid the > >> fallacies of the still insecure HA Discovery phase (as opposed to > >> the insecure DHAAD). > >> > > > > As mentioned, I would like to rule out from this discussion the > > configuration of credentials. There are several ways to provide users > > with the right credentials and this is a common problem to all > > bootstrapping solutions. > > Ok, I agree. > > > Concerning configuration of FQDN, you are right. The draft is based > > on the configuration of a FQDN of the MSP on the MN. The idea is that > > this is less cumbersome than configuring IPv6 addresses, in my view > > for two reasons: FQDN are more user friendly and do not change, > > whereas IPv6 home link prefixes might change. > > Please mention in the draft the reasoning that FQDN is more user > friendly than IP addresses and that FQDN would change less frequently > than the prefix. > This can be done, if other authors agree to have a comparison between DNS-based and DHAAD mechanisms. Not sure it is needed, but we can do that if the WG agrees. > >>> o HA address discovery. The Mobile Node needs to discover the > >>> address of its Home Agent. The main objective of a bootstrapping > >>> solution is to minimize the data pre-configured on the Mobile > >>> Node. > >> Ok, so the objective is to minimize the data pre-configured on the > >> MN. > >> > > > > The objective is to design a bootstrapping solution that is scalable. > > The list of detailed goals is provided in the PS draft. > > I've read that. As with "minimal", "Scalable" is not defined. > "Scalable" doesn't even appear in the PS text. Scalable of what with > respect to what? > > Do you have a rough idea about what "scalable" is? Other than just > claiming it as an advantage of a proposed method over a vaguely assummed > non-scalable method? > > In some contexts, it's like this: the effort to locally maintain > name-address association (/etc/hosts) at each site about each other site > grows exponentially with the number of sites. It doesn't scale. The > effort to distributely maintain that database with DNS grows linearly > with the number of sites. That's more scalable. > > So what is "scalable" in the context of DNS-based bootstrapping? Is it > more scalable to pre-configure fqdn instead of prefixes? No. What is > exactly scalable about the DNS-based bootstrapping? > As mentioned, I think the most important advantage of DNS-based is that FQDN change rarely. And an operator may change the binding between names and addresses in the DNS, whereas it cannot change the home prefixes configured in the terminals. It seems to me that this is a quite obvious advantage in a real wide deployment scenario. > >>> For this reason, the DHAAD defined in [2] may not be applicable > >>> in real deployments since it is required that the Mobile Node is > >>> pre-configured with the home network prefix > >> Ok, so pre-configuring the home network prefix on the MN is not > >> minimal. > >> > >>> and it does not allow an operator to load balance by having > >>> Mobile Nodes dynamically assigned to Home Agents located in > >>> different subnets. > >> But was load balancing an objective? The objective was to minimize > >> pre-configured data, not to offer load balancing capability. > >> > > > > This is a second-priority goal. > > Ok. > > > This is something that you may simply achieve using FQDNs. > > It's not sufficient to just use FQDNs to move some MN from one HA to > another, in a different subnet. There's need for protocols that haven't > been specified too. > I'm not saying that you can achieve a fine grained load balancing. This is clearly stated in the draft. But the operator can change the addresses that are registered in the DNS. This is not possible if the addresses are configured in the terminals. > >>> This document defines a solution for Home Agent address discovery > >>> that is based on Domain Name Service (DNS), introducing a new > >>> DNS SRV record [5]. The unique information that needs to be > >>> pre-configured on the Mobile Node is the domain name of the MSP. > >> So there is a need to pre-configure data on the MN, except that > >> this time we pre-configure the domain name instead of the home > >> prefix. > >> > >> Is pre-configuring the domain name more minimal than > >> pre-configuring the home prefix? I don't think we can talk in > >> absolute terms here. In terms of memory required, a prefix can > >> take maximum 39 ASCII characters while a domain name may take any > >> length ("domain" in domain.com can have up to 255 characters). So > >> apparently pre-configuring a prefix could be shorter than > >> pre-configuring a domain name. > >> > > > > I think there is a clear difference: home prefixes might change. > > Domain names might change too. A known peninsular operator research arm > changed just recently, you must be aware of it. > Good point :) But the latter happened once in the last 6 years and our mail servers changed their IP addresses several times during this period. It's a matter of how much frequent is the event. > >>> The Mobile Node needs to obtain the IP address of the DNS server > >>> before it can send a DNS request. This can be pre-configured on > >>> the Mobile Node or obtained through DHCPv6 from the visited link > >>> [11]. > >> "DNS server pre-configured on the MN"? More data pre-configured? > >> Remark this would come in addition to the domain name > >> pre-configured on the MN. > >> > >> But I do agree the DNS server address could come from the local > >> DHCP server. > >> > > > > Good. So are you suggesting we should rephrase? Can you come up with > > a proposed text? > > Please remove the entire paragraph stating that MN could be > pre-configured with the DNS Server address (of all visited networks) or > obtained with DHCP. > > > So, it seems that your main concern is related to the fact that DHAAD > > is not considered in this draft. I think that DHAAD is not > > deprecated by this draft, simply there are deployment scenarios where > > a DNS-based (or a DHCP-based for integrated scenario) solution is > > considered more useful. > > We seem to be talking past each other. But I agree with you that there > are deployments that may need this solution. But just don't say there's > a problem because MIP6 doesn't do this and that. Some deployments need > something different than what exists not because what exists don't > satisfy them, but because what these deployment prefer is more scalable > and more minimal. > > > Would you suggest any way to improve the draft? > > As I said above: (1) please define "scalable" and "minimal", (2) please > remove the phrase in the introduction saying MIP6 doesn't deliver the HA > address to the MN (3) please remove the text saying the DNS server > address could be pre-configured on the MN or obtained by DHCP and (4) > please mention in the draft that you've decided to use FQDN instead of > IP addresses as pre-config data because they're more user-friendly and > change less often. > > In two separate threads I also suggest: (1) please change the title to > "DNS-based..." and (2) do double-check with straight and reverse DNS > resolution whenever querying the DNS. > I will discuss these proposed changes with other co-authors. I am against to change the title since the draft specifies several other procedures and not only HA address discovery. --Gerardo > Thanks, > > Alex > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 25 11:31:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYPVj-0002qr-DN; Tue, 25 Apr 2006 11:31:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYPVi-0002qm-V8 for mip6@ietf.org; Tue, 25 Apr 2006 11:31:30 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYPVh-0005Vd-I9 for mip6@ietf.org; Tue, 25 Apr 2006 11:31:30 -0400 Message-ID: <008e01c6687e$07943800$026115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Alexandru Petrescu" References: <444D1503.3020105@motorola.com> <02a201c667e9$338a4b60$026115ac@dcml.docomolabsusa.com> <444D4FA4.8060602@motorola.com> <02f201c667f0$c81af660$026115ac@dcml.docomolabsusa.com> <444D5818.2030801@motorola.com> Subject: Re: [Mip6] Substitute "high risk" for "mitigated risk" in Security Considerations of draft-ietf-mip6-bootstrapping-split-02.txt Date: Tue, 25 Apr 2006 08:36:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org >> You are talking specifically about when the MN is at home? > > Yes, mainly. Rogue HA forcing legitimate MN at home means no IKE, no root > certs verification, no ESP. > > Additionally, the rogue HA could gather two legitimate MNs under it, make > them both believe they're under same subnet and at their respective homes > (advertise two different prefixes), so communicate with their CoAs, so no > IKE involved, no RR tests. While this communication, the rogue HA can > listen all traffic between them. If both MNs bootstrapped via DNS, and > DNS is rogue, this risk is related to this draft. > >> Then I'd say that the RA from the HA needs to have a SEND signature on >> it, and the MN needs to ask the HA for a cert chain using SEND CPS. It >> won't know from the cert that the router is an HA but having the 'H' bit >> on and the signature will provide assurance that the RA hasn't been >> modified in transit and that the orignator is a certified router. >> >> Maybe something should be said along these lines in Section 9? > > Yes. I hope it's realized that this brings SeND in the picture of secure > bootstrapping, along with DNSSEC and IKE? I mean MN should run all that. > Well, one possibiity is for the MN to run IKE on the home link too. And there is nothing in RFC 3775 to prevent it. Also, as mentioned, SEND can be used on the RA. I'll see if I can come up with some text for Section 9. > And maybe something about the Binding Refresh Request too? > > There's no security check in 3775 about what does MN do when it receives a > BRR. All it says is it should send a BU to its HA with its current > location. I'm not sure though how to exploit this attack but there should > be something about it. > I'll deal with this in a separate thread. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 25 11:32:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYPWz-0003Et-EJ; Tue, 25 Apr 2006 11:32:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYPWx-0003Eo-Ql for mip6@ietf.org; Tue, 25 Apr 2006 11:32:47 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYPWw-0005Xt-Ev for mip6@ietf.org; Tue, 25 Apr 2006 11:32:47 -0400 Message-ID: <009301c6687e$35f89790$026115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Alexandru Petrescu" References: <444D1503.3020105@motorola.com> <02a201c667e9$338a4b60$026115ac@dcml.docomolabsusa.com> <444D4FA4.8060602@motorola.com> <02f201c667f0$c81af660$026115ac@dcml.docomolabsusa.com> <444D5818.2030801@motorola.com> Subject: Binding Refresh Request Security (was: Re: [Mip6] Substitute "high risk" for "mitigated risk" in Security Considerations of draft-ietf-mip6-bootstrapping-split-02.txt) Date: Tue, 25 Apr 2006 08:37:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > And maybe something about the Binding Refresh Request too? > > There's no security check in 3775 about what does MN do when it receives a > BRR. All it says is it should send a BU to its HA with its current > location. I'm not sure though how to exploit this attack but there should > be something about it. > I don't see the threat here as necessarily part of bootstrapping, but I'd like to hear a little more first. What exactly is the attack you had in mind? jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 25 11:36:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYPaD-0004Zr-OA; Tue, 25 Apr 2006 11:36:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYPaC-0004Zm-15 for mip6@ietf.org; Tue, 25 Apr 2006 11:36:08 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYPaA-0005fJ-KP for mip6@ietf.org; Tue, 25 Apr 2006 11:36:07 -0400 Message-ID: <009801c6687e$adefcde0$026115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Alexandru Petrescu" , "Vijay Devarapalli" References: <44498CEA.4050803@azairenet.com> <444CA5A6.7060905@motorola.com><444D0FDE.508@azairenet.com> <444D339F.9010208@motorola.com><444D34F3.8020701@azairenet.com> <444D3D57.9050604@motorola.com><444D3ECF.9080507@azairenet.com> <444D42F7.5010009@motorola.com><444D466A.2060609@azairenet.com> <444D50B2.2030606@motorola.com><444D5157.8040402@azairenet.com> <444D5470.4090401@motorola.com> Subject: Re: [Mip6] Re: Should the MN do reverse DNS lookup to check if at home? Date: Tue, 25 Apr 2006 08:41:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > It's spotty in some places because people don't deploy DNS correctly. With > a correctly deployed DNS the reverse tree is right. We should go with the > assumption that DNS is deployed correctly. IETF can't make assumptions on > how certain protocols are deployed, can just suggest deployers how to do > it. > > If the reverse lookup fails simply don't use that foreign network, drop > all connections via it. > I don't think we are talking about failure of the reverse lookup. One can certainly argue convincingly that if the reverse lookup fails, the MN should drop the address. On the other hand, if the reverse tree is not deployed, there will just be no response. It is not clear to me that this is sufficient justification for the MN to drop the address. The MN can go ahead and try to set up an IKE transaction with the HA, and, if it succeeds, it's just an indication that the network sysadmins are not so diligent about how they deploy the DNS, not that there is an attacker spoofing a DNS server and HA. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 25 11:39:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYPdp-0005TF-P8; Tue, 25 Apr 2006 11:39:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYPdp-0005TA-8R for mip6@ietf.org; Tue, 25 Apr 2006 11:39:53 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYPdn-0005lw-S6 for mip6@ietf.org; Tue, 25 Apr 2006 11:39:53 -0400 Message-ID: <00a501c6687f$3474e850$026115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Alexandru Petrescu" , "Vijay Devarapalli" References: <44498CEA.4050803@azairenet.com> <444CA5A6.7060905@motorola.com><444D0FDE.508@azairenet.com> <444D339F.9010208@motorola.com><444D34F3.8020701@azairenet.com> <444D3D57.9050604@motorola.com><444D3ECF.9080507@azairenet.com> <444D42F7.5010009@motorola.com><444D466A.2060609@azairenet.com> <444D50B2.2030606@motorola.com><444D5157.8040402@azairenet.com> <444D5470.4090401@motorola.com><444D5B9B.4010909@azairenet.com> <444D605B.5010904@motorola.com> Subject: Re: [Mip6] Re: Should the MN do reverse DNS lookup to check if at home? Date: Tue, 25 Apr 2006 08:44:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > How about this then: if the reverse lookup fails then fallback to DHAAD, > and if DHAAD fails then stop connecting to foreign network - how about > that? > If the reverse lookup fails to return a response, the MN can try IKE anyway, so there is no need for DHAAD. If the response is negative, then of course the MN should drop the address. In any case, reverse lookup should be a MAY due to the patchy deployment status of reverse trees, which, as you note earlier in the message, is partly due to security concerns. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 25 11:53:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYPqv-0008Q6-E6; Tue, 25 Apr 2006 11:53:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYPqt-0008Q1-EP for mip6@ietf.org; Tue, 25 Apr 2006 11:53:23 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYPqt-0006PT-C8 for mip6@ietf.org; Tue, 25 Apr 2006 11:53:23 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FYPqs-0002Z3-SM for mip6@ietf.org; Tue, 25 Apr 2006 11:53:23 -0400 Message-ID: <00ae01c66881$17503480$026115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Alexandru Petrescu" References: <444D1503.3020105@motorola.com> <02a201c667e9$338a4b60$026115ac@dcml.docomolabsusa.com> <444D4FA4.8060602@motorola.com> <02f201c667f0$c81af660$026115ac@dcml.docomolabsusa.com> <444D65CC.2060006@motorola.com> Date: Tue, 25 Apr 2006 08:58:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: mip6@ietf.org Subject: [Mip6] Re: Should we assume SeND in foreign/visited networks? (was: Substitute "high risk" for "mitigated risk" in Security Considerations of draft-ietf-mip6-bootstrapping-split-02.txt) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > James, I think I didn't make myself clear (if you got my message please > skip this). It's the DNS bootstrapping method that tells MN whether > it's at home or not. Clearly, a rogue AP/AR/DNS server can instruct a > MN as apparently being at home. This indication doesn't involve cert > verification, because comes from RA and DNS. > > You're proposing this attack be foiled by running SeND on the home > network. But it should actually run on all foreign networks where MN > attaches. To foil the attack, the MN shouldn't talk to any network that > is not able to send SeND signatures on RAs. > Right, if the 'H' bit is set on an RA in a foreign network, how can the MN trust it? This is something for the updated version of RFC 3775, I think. Beyond the scope of the bootstrapping draft. > So, do you propose to assume SeND is deployed on many access networks? > Well, I think SEND should be deployed on all last hop IPv6 networks. Having been the victim of an ARP spoofing attack (on IPv4) myself , I can categorically state that the threat is real, but most people don't seem to take it seriously. In fact, I just got email the other day from a former IETF SEC AD that he had suffered some kind of attack due to an unsecured RA in IPv6. I don't know what the implementation status of SEND is, but some people seem to be unhappy about the fact that it contains IPR, even if the IPR is royalty-free, which might be holding it up. > If not, I think the risk you and I described above should be evaluated > as "high" and not "mitigated" in the section Security Considerations of > the draft. Like I said, this is really beyond the bootstrapping draft. RFC 3775 should recommend SEND to mitigate the risk of bogus HA advertisement. But since RFC 3775 was written before SEND was completed, there is nothing in it. Something for RFC 3775bis. jak jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 25 11:57:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYPut-0000FO-ON; Tue, 25 Apr 2006 11:57:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYPur-0000FE-O8 for mip6@ietf.org; Tue, 25 Apr 2006 11:57:29 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYPur-0006Xk-Bg for mip6@ietf.org; Tue, 25 Apr 2006 11:57:29 -0400 Message-ID: <00dd01c66881$ac99ac60$026115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Alexandru Petrescu" , "Vijay Devarapalli" References: <44498CEA.4050803@azairenet.com> <444CA5A6.7060905@motorola.com><444D0FDE.508@azairenet.com> <444D339F.9010208@motorola.com><444D34F3.8020701@azairenet.com> <444D3D57.9050604@motorola.com><444D3ECF.9080507@azairenet.com> <444D42F7.5010009@motorola.com><444D466A.2060609@azairenet.com> <444D50B2.2030606@motorola.com><444D5157.8040402@azairenet.com> <444D5470.4090401@motorola.com><444D5B9B.4010909@azairenet.com> <444D605B.5010904@motorola.com><444D7F7D.6010204@azairenet.com> <444DF070.1070100@motorola.com> Subject: Re: [Mip6] Re: Add home prefix to the minimal set of pre-config? (was: Should the MN do reverse DNS lookup to check if at home?) Date: Tue, 25 Apr 2006 09:02:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Alex, The whole point of boostrapping is to get rid of the need to preconfigure with topological data. This would obviate the entire design. jak ----- Original Message ----- From: "Alexandru Petrescu" To: "Vijay Devarapalli" Cc: Sent: Tuesday, April 25, 2006 2:48 AM Subject: [Mip6] Re: Add home prefix to the minimal set of pre-config? (was: Should the MN do reverse DNS lookup to check if at home?) > Vijay Devarapalli wrote: >> Alexandru Petrescu wrote: >> >>> How about this then: if the reverse lookup fails then fallback to DHAAD, >>> and if DHAAD fails then stop connecting to foreign network - >>> how about that? >> >> but then this requires configuring the MN with the home prefix. this >> is not in the minimal set of configuration on the MN as described in >> the bootstrapping problem statement draft. > > I agree, the home prefix is not currently in the minimal set of > configuration of MN as described in the bootstrapping PS draft. > >> I dont see a way out. > > I suggest to add the home prefix in the list of pre-config data. This > would help integrate DHAAD and MPD in the bootstrapping flow, with side > effects of ensuring a higher level of security using DNS and facing > renumbering events with MPD. > > Alex > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 25 11:58:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYPw2-0000MG-Mm; Tue, 25 Apr 2006 11:58:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYPw1-0000MB-Bs for mip6@ietf.org; Tue, 25 Apr 2006 11:58:41 -0400 Received: from gwstaff.wit.ie ([193.1.184.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYPw1-0006aW-0w for mip6@ietf.org; Tue, 25 Apr 2006 11:58:41 -0400 Received: from WIT-STAFF-MTA by gwstaff.wit.ie with Novell_GroupWise; Tue, 25 Apr 2006 16:58:39 +0100 Message-Id: <444E552D.1F00.0002.1@wit.ie> X-Mailer: Novell GroupWise Internet Agent 7.0 Date: Tue, 25 Apr 2006 16:58:23 +0100 From: "Richard Frisby" To: Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Mip6] HA reliability issue X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0990062718==" Errors-To: mip6-bounces@ietf.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --===============0990062718== Content-Type: multipart/alternative; boundary="=__Part2A0F2D0F.0__=" This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part2A0F2D0F.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Can anyone on the HA reliability design team tell me what the status of the problem/scope/solution documents are ? --=__Part2A0F2D0F.0__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: HTML Can anyone on the HA reliability design team tell me what the status of the problem/scope/solution documents are ? --=__Part2A0F2D0F.0__=-- --===============0990062718== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0990062718==-- From mip6-bounces@ietf.org Tue Apr 25 12:10:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYQ7W-0007kZ-AM; Tue, 25 Apr 2006 12:10:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYQ7V-0007kD-8h for mip6@ietf.org; Tue, 25 Apr 2006 12:10:33 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYQ7U-0007bO-ME for mip6@ietf.org; Tue, 25 Apr 2006 12:10:33 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id k3PGWbIf002995; Tue, 25 Apr 2006 09:32:37 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id k3PGNmm1001594; Tue, 25 Apr 2006 11:23:49 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 325AA865980; Tue, 25 Apr 2006 18:10:22 +0200 (CEST) Message-ID: <444E49ED.6010902@motorola.com> Date: Tue, 25 Apr 2006 18:10:21 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Gerardo Giaretta Subject: Re: [Mip6] Comments while reading draft-ietf-mip6-bootstrapping-split-02.txt References: <444CD11C.2050807@motorola.com> <444E21A8.1020000@motorola.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Gerardo Giaretta wrote: > rfc3775 specifies a discovery mechanism based on MN knowing the home > link prefix. This is something is not needed in bootstrapping > solutions and I think the PS document is quite clear. We talk past each other. I'll re-iterate. The following text in this draft says: > Mobile IPv6 [2] requires the Mobile Node to know its Home Agent > Address, its own Home Address and the cryptographic materials (e.g. > shared keys or certificates) needed to set up IPsec security > associations with the Home Agent in order to protect Mobile IPv6 > signaling. I agree. > This is generally referred to as the Mobile IPv6 bootstrapping > problem [4]. I don't agree that if MN needs to know its HA/HoA/crypto it means there's a problem. > Mobile IPv6 base protocol does not specify any method to > automatically acquire this information [HA/HoA/crypto], This is wrong - it does. If you wrote it something like "MIP6 requires MN to pre-configure its home link prefix, otherwise MIP6 MN can't acquire its HA and HoA" the it would have expressed what you say in this email. But it's not written so! You could write it like this: A MIP6 MN needs its HA address, its HoA and crypto material for proper protocol operation. MIP6 offers MN means to bootstrap the HA address and HoA with DHAAD and MPD, if the MN is pre-configured with the home link prefix. Some operators don't accept to pre-configure the home link prefix on the MN because it's not minimal, not scalable, not user-friendly and for various other reasons (see the PS draft). Hence a MN bootstrapping issue. To address it some operators choose to pre-configure the MN with the fqdn of its HA (instead of home link prefix) and crypto material. The bootstrapping protocol in this document helps MN dynamically acquire its HA address and HoA, based only on the HA's fqdn (not on home link prefix) and on crypto material; the initial phase uses stateless address auto-configuration and DNS querying (to obtain the HA address) while subsequent phases involve IKE with the HA (obtain HoA and SAs). > However, if you think it is needed, we can state that in some > scenarios netwrok operators may still rely on DHAAD, if all MNs are > configured with home link prefixes. I hope this is captured above, do you think so? Would you copy paste it in the draft or modify it? >>> I will try to give more details on this topic below. Note however >>> that the draft is not deprecating DHAAD nor MPD. The draft is >>> specifying a bootstrapping procedure that the WG thinks it is >>> needed, even though someone may keep using DHAAD. >> Ok. May I also see it the other way around: someone may use the >> DNS-based bootstrapping method but the WG thought at some point >> that the 3775 was to become an RFC. >> > > And then WG chairs decided to have a DT to solve the bootstrapping > problem :) > > You may like DHAAD more than DNS-based discovery: that's ok, no > problem to me. This is why I'm not in favor of deprecating DHAAD. Ok. >>>> With respect to the crypto material, the certificates more >>>> specifically. Neither Mobile IPv6 nor any other method I'm >>>> aware off will allow MN to "automatically" acquire a cert. To >>>> acquire a cert one must prove its/his/her identity with an >>>> out-of-band method, non-automatisable. >>>> >>>> So stating that the bootstrapping problem lies in the fact that >>>> Mobile IPv6 can't distribute certs makes one think that a >>>> solution to that problem may be this draft which will help to >>>> distribute certs. It doesn't. >>>> >>> certs are one example. The main mechanism described in the >>> documet relies on IKEv2+EAP. What you mention is that the >>> credentials (e.g. certs, SIM card) need to be distributed to the >>> MNs; I agree, but I think this is acceptable. >> Yes, but is it scalable? >> > > Judging from the number of GSM terminals in the world, I think that > having a SIM card with the configured credentials in it, it's quite > scalable. So you just defined what _is_ scalable. Now what is _not_ scalable? It's not scalable to pre-configure the home link prefix on each mobile? >>>> Moreover, this spec requires additional data to be >>>> pre-configured on the MN, not just the domain name. It's the >>>> certificates. They must be pre-configured on MN in order to >>>> somehow avoid the fallacies of the still insecure HA Discovery >>>> phase (as opposed to the insecure DHAAD). >>>> >>> As mentioned, I would like to rule out from this discussion the >>> configuration of credentials. There are several ways to provide >>> users with the right credentials and this is a common problem to >>> all bootstrapping solutions. >> Ok, I agree. >> >>> Concerning configuration of FQDN, you are right. The draft is >>> based on the configuration of a FQDN of the MSP on the MN. The >>> idea is that this is less cumbersome than configuring IPv6 >>> addresses, in my view for two reasons: FQDN are more user >>> friendly and do not change, whereas IPv6 home link prefixes might >>> change. >> Please mention in the draft the reasoning that FQDN is more user >> friendly than IP addresses and that FQDN would change less >> frequently than the prefix. >> > > This can be done, if other authors agree to have a comparison between > DNS-based and DHAAD mechanisms. Not sure it is needed, but we can do > that if the WG agrees. I'm not sure we need to compete two different proposals. I think one is already RFC for some time and implemented. I also think that some operators may prefer the DNS-based bootstrapping. >> So what is "scalable" in the context of DNS-based bootstrapping? Is >> it more scalable to pre-configure fqdn instead of prefixes? No. >> What is exactly scalable about the DNS-based bootstrapping? >> > > As mentioned, I think the most important advantage of DNS-based is > that FQDN change rarely. Ok, while I agree that apparently the fqdn and DNS-based method may help apps hardcode server names - I don't agree MIP6 plays in the apps league; I don't agree that the DNS-based has any "scalability" advantage over the DHAAD-based. If one can't explain what's and what's not scalable then probably better don't use the word scalable. > And an operator may change the binding between names and addresses in > the DNS, whereas it cannot change the home prefixes configured in the > terminals. Yes, but an operator can't change the binding between different names (an old one and a new one) even with the DNS-based bootstrapping method. When a domain name changes, the way SRV record is spec'ed is such it must point to a real record (not a CNAME). In which case the operator will have to change the fqdn's stored in mobiles. > It seems to me that this is a quite obvious advantage in a real wide > deployment scenario. It is, but not perfect. One can't claim it as _the_ bootstrapping method. One should accept its limitations, in the draft. >>>>> For this reason, the DHAAD defined in [2] may not be >>>>> applicable in real deployments since it is required that the >>>>> Mobile Node is pre-configured with the home network prefix >>>> Ok, so pre-configuring the home network prefix on the MN is not >>>> minimal. >>>> >>>>> and it does not allow an operator to load balance by having >>>>> Mobile Nodes dynamically assigned to Home Agents located in >>>>> different subnets. >>>> But was load balancing an objective? The objective was to >>>> minimize pre-configured data, not to offer load balancing >>>> capability. >>>> >>> This is a second-priority goal. >> Ok. >> >>> This is something that you may simply achieve using FQDNs. >> It's not sufficient to just use FQDNs to move some MN from one HA >> to another, in a different subnet. There's need for protocols that >> haven't been specified too. >> > > I'm not saying that you can achieve a fine grained load balancing. > This is clearly stated in the draft. But the operator can change the > addresses that are registered in the DNS. This is not possible if > the addresses are configured in the terminals. If the home link prefixes are pre-configured in the terminals, the operators can achieve load balancing by re-routing the respective home link prefixes in the home network, presumably with netlmm. MIP6 load balancing can be achieved with DHAAD. DHAAD was designed for load balancing between HAs on the same home link. Moving the prefix from one link to another (within the same home network) is not a MIP6 problem, but a netlmm problem. >>>>> This document defines a solution for Home Agent address >>>>> discovery that is based on Domain Name Service (DNS), >>>>> introducing a new DNS SRV record [5]. The unique information >>>>> that needs to be pre-configured on the Mobile Node is the >>>>> domain name of the MSP. >>>> So there is a need to pre-configure data on the MN, except that >>>> this time we pre-configure the domain name instead of the home >>>> prefix. >>>> >>>> Is pre-configuring the domain name more minimal than >>>> pre-configuring the home prefix? I don't think we can talk in >>>> absolute terms here. In terms of memory required, a prefix >>>> can take maximum 39 ASCII characters while a domain name may >>>> take any length ("domain" in domain.com can have up to 255 >>>> characters). So apparently pre-configuring a prefix could be >>>> shorter than pre-configuring a domain name. >>>> >>> I think there is a clear difference: home prefixes might change. >> Domain names might change too. A known peninsular operator >> research arm changed just recently, you must be aware of it. >> > > Good point :) > > But the latter happened once in the last 6 years and our mail servers > changed their IP addresses several times during this period. It's a > matter of how much frequent is the event. I see it differently. It is much easier to change a domain name in the DNS point it to same previous IP address range than to change the IP address block allocated to a certain domain name (witness the reverse DNS resolution Vijay expressed previously as being spotty). Registering a domain name is cheap and getting rid of the old one is simply a expiration delay. Obtaining an IP address range is very expensive and one must make sure s/he properly gives back the old address range. Hence, people change much often their domain names than their IP address ranges. > I will discuss these proposed changes with other co-authors. I am > against to change the title since the draft specifies several other > procedures and not only HA address discovery. Right, I was not proposing to put "HA address discovery" in the title. I suggested: "DNS-based MIP6 MN bootstrapping in split scenario" "DNS-based" because it is the first and most fundamental block of all the procedure, the most sensitive to security attacks, the strongest argument for user-friendliness and scalability. One co-author seemed to not oppose this title change. What do you think? Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 25 12:22:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYQJ4-0003oQ-Aq; Tue, 25 Apr 2006 12:22:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYQJ2-0003oL-Es for mip6@ietf.org; Tue, 25 Apr 2006 12:22:28 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYQJ1-000051-3e for mip6@ietf.org; Tue, 25 Apr 2006 12:22:28 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id k3PGiX4x008606; Tue, 25 Apr 2006 09:44:33 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id k3PGY4SP001390; Tue, 25 Apr 2006 11:34:04 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 59A1C865980; Tue, 25 Apr 2006 18:22:18 +0200 (CEST) Message-ID: <444E4CBA.6020901@motorola.com> Date: Tue, 25 Apr 2006 18:22:18 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: James Kempf Subject: Re: [Mip6] Re: Should the MN do reverse DNS lookup to check if at home? References: <44498CEA.4050803@azairenet.com> <444CA5A6.7060905@motorola.com><444D0FDE.508@azairenet.com> <444D339F.9010208@motorola.com><444D34F3.8020701@azairenet.com> <444D3D57.9050604@motorola.com><444D3ECF.9080507@azairenet.com> <444D42F7.5010009@motorola.com><444D466A.2060609@azairenet.com> <444D50B2.2030606@motorola.com><444D5157.8040402@azairenet.com> <444D5470.4090401@motorola.com> <009801c6687e$adefcde0$026115ac@dcml.docomolabsusa.com> In-Reply-To: <009801c6687e$adefcde0$026115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: mip6@ietf.org, Vijay Devarapalli X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org I understand you oppose running DHAAD in case reverse resolution fails or reverse resolution returns an address that doesn't match the pre-configured HA fqdn. James Kempf wrote: >> It's spotty in some places because people don't deploy DNS >> correctly. With a correctly deployed DNS the reverse tree is right. >> We should go with the assumption that DNS is deployed correctly. >> IETF can't make assumptions on how certain protocols are deployed, >> can just suggest deployers how to do it. >> >> If the reverse lookup fails simply don't use that foreign network, >> drop all connections via it. >> > > I don't think we are talking about failure of the reverse lookup. One > can certainly argue convincingly that if the reverse lookup fails, > the MN should drop the address. On the other hand, if the reverse > tree is not deployed, there will just be no response. It is not clear > to me that this is sufficient justification for the MN to drop the > address. The MN can go ahead and try to set up an IKE transaction > with the HA, MN going ahead IKE to HA but not being sure about HA being the right one may lead to HA telling it it is at home so don't use IKE. Depending on how the text about sequence of DNS resolving and IKE is written there can be security holes. > and, if it succeeds, it's just an indication that the network > sysadmins are not so diligent about how they deploy the DNS, not that > there is an attacker spoofing a DNS server and HA. I agree. The text could just say that MN checks whether the fqdn returned by a reverse resolution of the IP address obtained from resolving the pre-configured fqdn - is the same. If not the same then it MUST run IKE to the HA even if it believes it is at home. Becaue the HA may be rogue. Or so. If the reverse resolution returns NULL or fails to respond within 5 minutes then also run IKE even if it believes it is at home. Or so. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 25 12:30:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYQQY-0005HR-8J; Tue, 25 Apr 2006 12:30:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYQQW-0005HM-SF for mip6@ietf.org; Tue, 25 Apr 2006 12:30:12 -0400 Received: from s31xub.systems.smu.edu ([129.119.70.73]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYQQV-0000f0-JR for mip6@ietf.org; Tue, 25 Apr 2006 12:30:12 -0400 Received: from s31xs5.systems.smu.edu ([129.119.70.75]) by s31xub.systems.smu.edu with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Apr 2006 11:28:25 -0500 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] HA reliability issue Date: Tue, 25 Apr 2006 11:28:25 -0500 Message-ID: <1D490807747A4840A8F4316CFB2A80FD27E50C@s31xs5.systems.smu.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] HA reliability issue Thread-Index: AcZogSC0il61KYK9Q2ewZIMD2k8SjwAAsRsq From: "Faizan, Jahanzeb" To: "Richard Frisby" , X-OriginalArrivalTime: 25 Apr 2006 16:28:25.0710 (UTC) FILETIME=[46F5F0E0:01C66885] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org HA reliability is already a "solved" problem. Look at the references = below. I am not sure though what the design team is trying to = do.....reinventing the wheel or something else? =20 [1] J. Faizan, H. El-Rewini, and M. Khalil, "Problem Statement: Home = Agent Reliability," IETF Draft, = draft-jfaizan-mipv6-ha-reliability-01.txt (work in progress), November = 2003. =20 [2] J. Faizan, H. El-Rewini, and M. Khalil, "Virtual Home Agent = Reliability Protocol (VHARP)," IETF Draft, = draft-jfaizan-mipv6-vhar-02.txt (work in progress), April 2004. =20 [3] J. Faizan, H. El-Rewini, and M. Khalil, "VHARP: Virtual Home = Agent Reliability Protocol for Mobile IPv6 based Networks," in = Proceedings of IEEE International Conference of Wireless Networks, = Communications, and Mobile Computing - WirelessCom 2005, Hawaii, USA, = June 13-16, 2005. =20 [4] J. Faizan, H. El-Rewini, and M. Khalil, "Efficient Dynamic Load = Balancing for Multiple Home Agents in Mobile IPv6 based Networks," in = Proceedings of IEEE International Conference on Pervasive Services - = ICPS 2005, Santorini, Greece, July 11-14, 2005.=20 =20 [5] J. Faizan, H. El-Rewini, and M. Khalil, "Introducing Reliability = and Load Balancing in Mobile IPv6 based Networks," submitted to Wireless = Communications and Mobile Computing, Wiely. =20 [6] J. Faizan, H. El-Rewini, and M. Khalil, "Introducing Reliability = and Load Balancing in Home Link of Mobile IPv6 based Networks," = submitted to IEEE International Conference on Pervasive Services - ICPS = 2006, Santorini, , Lyon, France, June 26-29, 2006. =20 [7] J. Faizan, H. El-Rewini, and M. Khalil, "Virtual Home Agent = Reliability Protocol - Implementation Details," Southern Methodist = University, Technical Report (04-CSE-03), May 2005. =20 [8] J.Faizan, "INTRODUCING RELIABILITY AND LOAD BALANCING IN MOBILE IPV6 = BASED NETWORKS", Southern Methodist University, Ph.D. Thesis, December = 2005. Thanks Jahanzeb Faizan ________________________________ From: Richard Frisby [mailto:RFRISBY@wit.ie] Sent: Tue 4/25/2006 10:58 AM To: mip6@ietf.org Subject: [Mip6] HA reliability issue Can anyone on the HA reliability design team tell me what the status of = the problem/scope/solution documents are ? _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 25 12:36:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYQVn-0005UY-OV; Tue, 25 Apr 2006 12:35:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYQVm-0005UT-96 for mip6@ietf.org; Tue, 25 Apr 2006 12:35:38 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYQVl-0001DK-24 for mip6@ietf.org; Tue, 25 Apr 2006 12:35:38 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3PGpXQO002966; Tue, 25 Apr 2006 09:51:33 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k3PGpfXn029129; Tue, 25 Apr 2006 11:51:42 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 883A2865980; Tue, 25 Apr 2006 18:34:45 +0200 (CEST) Message-ID: <444E4FA5.7090107@motorola.com> Date: Tue, 25 Apr 2006 18:34:45 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: James Kempf Subject: Re: [Mip6] Re: Add home prefix to the minimal set of pre-config? References: <44498CEA.4050803@azairenet.com> <444CA5A6.7060905@motorola.com><444D0FDE.508@azairenet.com> <444D339F.9010208@motorola.com><444D34F3.8020701@azairenet.com> <444D3D57.9050604@motorola.com><444D3ECF.9080507@azairenet.com> <444D42F7.5010009@motorola.com><444D466A.2060609@azairenet.com> <444D50B2.2030606@motorola.com><444D5157.8040402@azairenet.com> <444D5470.4090401@motorola.com><444D5B9B.4010909@azairenet.com> <444D605B.5010904@motorola.com><444D7F7D.6010204@azairenet.com> <444DF070.1070100@motorola.com> <00dd01c66881$ac99ac60$026115ac@dcml.docomolabsusa.com> In-Reply-To: <00dd01c66881$ac99ac60$026115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: mip6@ietf.org, Vijay Devarapalli X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org James Kempf wrote: > Alex, > > The whole point of boostrapping is to get rid of the need to > preconfigure with topological data. Ah! Apparently sounds logical. But MIP6 addresses exactly this problem, that the topology is stable and _can't_ change. That's why Home Address-CoA bindings. I was always thinking topological data must be there as is, at least about the home link, otherwise sessions get interrupted. One can't bootstrap now a MN with a HoA and 2 hours later with a different prefixed HoA without loosing reachability at the permanent home address. That's why this prefix must be stable, that's why should be pre-configured on MN, or that's why it should be returned in the SRV record too. > This would obviate the entire design. Not my goal. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 25 13:05:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYQyA-0000PU-U6; Tue, 25 Apr 2006 13:04:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYQy9-0000PP-Kj for mip6@ietf.org; Tue, 25 Apr 2006 13:04:57 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYQy9-0002om-CK for mip6@ietf.org; Tue, 25 Apr 2006 13:04:57 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3PHLfoV008165; Tue, 25 Apr 2006 10:21:43 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id k3PHJWvY003350; Tue, 25 Apr 2006 12:19:32 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id C5D90865980; Tue, 25 Apr 2006 19:04:52 +0200 (CEST) Message-ID: <444E56B4.4070900@motorola.com> Date: Tue, 25 Apr 2006 19:04:52 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: James Kempf References: <444D1503.3020105@motorola.com> <02a201c667e9$338a4b60$026115ac@dcml.docomolabsusa.com> <444D4FA4.8060602@motorola.com> <02f201c667f0$c81af660$026115ac@dcml.docomolabsusa.com> <444D65CC.2060006@motorola.com> <00ae01c66881$17503480$026115ac@dcml.docomolabsusa.com> In-Reply-To: <00ae01c66881$17503480$026115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: mip6@ietf.org Subject: [Mip6] Re: Not using SeND is insecure for DNS-based bootstrapping, but irrelevant if DHAAD-based (was: Should we assume SeND in foreign/visited networks?) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org James Kempf wrote: >> James, I think I didn't make myself clear (if you got my message >> please skip this). It's the DNS bootstrapping method that tells MN >> whether it's at home or not. Clearly, a rogue AP/AR/DNS server can >> instruct a MN as apparently being at home. This indication doesn't >> involve cert verification, because comes from RA and DNS. >> >> You're proposing this attack be foiled by running SeND on the home >> network. But it should actually run on all foreign networks where >> MN attaches. To foil the attack, the MN shouldn't talk to any >> network that is not able to send SeND signatures on RAs. >> > > Right, if the 'H' bit is set on an RA in a foreign network, how can > the MN trust it? > > This is something for the updated version of RFC 3775, I think. > Beyond the scope of the bootstrapping draft. The DNS-based bootstrapping draft could still acknowledge some security risks induced by this method and by not using SeND. >> So, do you propose to assume SeND is deployed on many access >> networks? >> > > Well, I think SEND should be deployed on all last hop IPv6 networks. > Having been the victim of an ARP spoofing attack (on IPv4) myself , > I can categorically state that the threat is real, but most people > don't seem to take it seriously. In fact, I just got email the other > day from a former IETF SEC AD that he had suffered some kind of > attack due to an unsecured RA in IPv6. > I don't know what the implementation status of SEND is, but some > people seem to be unhappy about the fact that it contains IPR, even > if the IPR is royalty-free, which might be holding it up. > >> If not, I think the risk you and I described above should be >> evaluated as "high" and not "mitigated" in the section Security >> Considerations of the draft. > > Like I said, this is really beyond the bootstrapping draft. RFC 3775 > should recommend SEND to mitigate the risk of bogus HA > advertisement. But since RFC 3775 was written before SEND was > completed, there is nothing in it. Something for RFC 3775bis. Remark that if DHAAD is used, and the home link prefix pre-configured on the MN, the MN is not subject to a security risk where the rogue AP sends it a fake RA to fool it believing it is at home; simply because rogue AP doesn't know the real MN's home prefix. With the currently described DNS-based bootstrapping method, rogue AP can easily fool MN believing it is at home: DNS response and RA contains same data. And this distinction happens regardless of SeND being or not being used. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 25 13:09:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYR2U-0000d4-F7; Tue, 25 Apr 2006 13:09:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYR2S-0000cz-Bw for mip6@ietf.org; Tue, 25 Apr 2006 13:09:24 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYR2Q-00032f-2I for mip6@ietf.org; Tue, 25 Apr 2006 13:09:24 -0400 Received: from [10.1.201.8] ([10.1.201.8]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Apr 2006 10:09:18 -0700 Message-ID: <444E57BE.5010706@azairenet.com> Date: Tue, 25 Apr 2006 10:09:18 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: James Kempf Subject: Re: [Mip6] Re: Should the MN do reverse DNS lookup to check if at home? References: <44498CEA.4050803@azairenet.com> <444CA5A6.7060905@motorola.com><444D0FDE.508@azairenet.com> <444D339F.9010208@motorola.com><444D34F3.8020701@azairenet.com> <444D3D57.9050604@motorola.com><444D3ECF.9080507@azairenet.com> <444D42F7.5010009@motorola.com><444D466A.2060609@azairenet.com> <444D50B2.2030606@motorola.com><444D5157.8040402@azairenet.com> <444D5470.4090401@motorola.com> <009801c6687e$adefcde0$026115ac@dcml.docomolabsusa.com> In-Reply-To: <009801c6687e$adefcde0$026115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Apr 2006 17:09:18.0681 (UTC) FILETIME=[FD0B9C90:01C6688A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: mip6@ietf.org, Alexandru Petrescu X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org James Kempf wrote: >> It's spotty in some places because people don't deploy DNS correctly. >> With a correctly deployed DNS the reverse tree is right. We should go >> with the assumption that DNS is deployed correctly. IETF can't make >> assumptions on how certain protocols are deployed, can just suggest >> deployers how to do it. >> >> If the reverse lookup fails simply don't use that foreign network, drop >> all connections via it. >> > > I don't think we are talking about failure of the reverse lookup. One > can certainly argue convincingly that if the reverse lookup fails, the > MN should drop the address. On the other hand, if the reverse tree is > not deployed, there will just be no response. It is not clear to me that > this is sufficient justification for the MN to drop the address. The MN > can go ahead and try to set up an IKE transaction with the HA, and, if > it succeeds, it's just an indication that the network sysadmins are not > so diligent about how they deploy the DNS, not that there is an attacker > spoofing a DNS server and HA. I agree with this. there is an IKE authentication that follows anyway. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 25 13:16:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYR8a-0001AT-TW; Tue, 25 Apr 2006 13:15:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYR8Z-0001AO-S2 for mip6@ietf.org; Tue, 25 Apr 2006 13:15:43 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYR8Y-0003SZ-Kn for mip6@ietf.org; Tue, 25 Apr 2006 13:15:43 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3PHWOkv009813; Tue, 25 Apr 2006 10:32:24 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id k3PHTZGd016205; Tue, 25 Apr 2006 12:29:35 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id DB631865980; Tue, 25 Apr 2006 19:15:35 +0200 (CEST) Message-ID: <444E5937.2080000@motorola.com> Date: Tue, 25 Apr 2006 19:15:35 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: James Kempf References: <444D1503.3020105@motorola.com> <02a201c667e9$338a4b60$026115ac@dcml.docomolabsusa.com> <444D4FA4.8060602@motorola.com> <02f201c667f0$c81af660$026115ac@dcml.docomolabsusa.com> <444D5818.2030801@motorola.com> <009301c6687e$35f89790$026115ac@dcml.docomolabsusa.com> In-Reply-To: <009301c6687e$35f89790$026115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: mip6@ietf.org Subject: [Mip6] Re: Binding Refresh Request Security X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org James Kempf wrote: >> And maybe something about the Binding Refresh Request too? >> >> There's no security check in 3775 about what does MN do when it >> receives a BRR. All it says is it should send a BU to its HA with its >> current location. I'm not sure though how to exploit this attack but >> there should be something about it. >> > > I don't see the threat here as necessarily part of bootstrapping, but > I'd like to hear a little more first. What exactly is the attack you had > in mind? I'm not sure about the following attack. However, I do sense a risk in rogue AP making MN think it's at home and being able to send it a BRR. Legitimate MN is connected to legitimate AP and sends legitimate BUs to legitimate HA. Rogue AP shows up, MN attaches to it, rogue AP makes it think it is at home, rogue AP instructs MN to send BU (with BRR), at which point rogue AP turns off. MN will probably send BU to legitimate HA, telling it it is at home, which is not. It's probably a minor risk though, just inducing delays, with re-establishing proper connection with IKE soon after rogue AP turned off. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 25 13:16:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYR9X-0002he-JN; Tue, 25 Apr 2006 13:16:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYR9W-0002hZ-Ax for mip6@ietf.org; Tue, 25 Apr 2006 13:16:42 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYR9V-0003Va-Sc for mip6@ietf.org; Tue, 25 Apr 2006 13:16:42 -0400 Message-ID: <015901c6688c$b19acc20$026115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Alexandru Petrescu" References: <444D1503.3020105@motorola.com> <02a201c667e9$338a4b60$026115ac@dcml.docomolabsusa.com> <444D4FA4.8060602@motorola.com> <02f201c667f0$c81af660$026115ac@dcml.docomolabsusa.com> <444D65CC.2060006@motorola.com> <00ae01c66881$17503480$026115ac@dcml.docomolabsusa.com> <444E56B4.4070900@motorola.com> Date: Tue, 25 Apr 2006 10:21:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: mip6@ietf.org Subject: [Mip6] Re: Not using SeND is insecure for DNS-based bootstrapping, but irrelevant if DHAAD-based (was: Should we assume SeND in foreign/visited networks?) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Alex, We don't seem to be making much progress here. Clearly, you have a preference for DHAAD. Nobody is saying that it should be deprecated, just that it does not provide enough support. I don't agree that DNS bootstrapping is insecure, the need for the IKE is sufficient on the foreign link. You've brought up an issue about the home link, and I'm going to work up some text on the topic for Section 9, but that is basically all I have to say on this. We'll just have to agree to disagree on the rest. jak ----- Original Message ----- From: "Alexandru Petrescu" To: "James Kempf" Cc: Sent: Tuesday, April 25, 2006 10:04 AM Subject: Re: Not using SeND is insecure for DNS-based bootstrapping, but irrelevant if DHAAD-based (was: Should we assume SeND in foreign/visited networks?) > James Kempf wrote: >>> James, I think I didn't make myself clear (if you got my message >>> please skip this). It's the DNS bootstrapping method that tells MN >>> whether it's at home or not. Clearly, a rogue AP/AR/DNS server can >>> instruct a MN as apparently being at home. This indication doesn't >>> involve cert verification, because comes from RA and DNS. >>> >>> You're proposing this attack be foiled by running SeND on the home >>> network. But it should actually run on all foreign networks where >>> MN attaches. To foil the attack, the MN shouldn't talk to any >>> network that is not able to send SeND signatures on RAs. >>> >> >> Right, if the 'H' bit is set on an RA in a foreign network, how can >> the MN trust it? >> >> This is something for the updated version of RFC 3775, I think. >> Beyond the scope of the bootstrapping draft. > > The DNS-based bootstrapping draft could still acknowledge some security > risks induced by this method and by not using SeND. > >>> So, do you propose to assume SeND is deployed on many access >>> networks? >>> >> >> Well, I think SEND should be deployed on all last hop IPv6 networks. >> Having been the victim of an ARP spoofing attack (on IPv4) myself , >> I can categorically state that the threat is real, but most people >> don't seem to take it seriously. In fact, I just got email the other >> day from a former IETF SEC AD that he had suffered some kind of >> attack due to an unsecured RA in IPv6. > > >> I don't know what the implementation status of SEND is, but some >> people seem to be unhappy about the fact that it contains IPR, even >> if the IPR is royalty-free, which might be holding it up. >> >>> If not, I think the risk you and I described above should be >>> evaluated as "high" and not "mitigated" in the section Security >>> Considerations of the draft. >> >> Like I said, this is really beyond the bootstrapping draft. RFC 3775 >> should recommend SEND to mitigate the risk of bogus HA >> advertisement. But since RFC 3775 was written before SEND was >> completed, there is nothing in it. Something for RFC 3775bis. > > Remark that if DHAAD is used, and the home link prefix pre-configured on > the MN, the MN is not subject to a security risk where the rogue AP sends > it a fake RA to fool it believing it is at home; simply because rogue AP > doesn't know the real MN's home prefix. > > With the currently described DNS-based bootstrapping method, rogue AP can > easily fool MN believing it is at home: DNS response and RA contains same > data. > > And this distinction happens regardless of SeND being or not being used. > > Alex > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 25 13:20:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYRCe-0004KJ-Jq; Tue, 25 Apr 2006 13:19:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYRCd-0004Ik-4s for mip6@ietf.org; Tue, 25 Apr 2006 13:19:55 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYRCb-0003qH-TF for mip6@ietf.org; Tue, 25 Apr 2006 13:19:55 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3PHab4F010503; Tue, 25 Apr 2006 10:36:38 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k3PHbDMx013206; Tue, 25 Apr 2006 12:37:14 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id A344C865980; Tue, 25 Apr 2006 19:19:49 +0200 (CEST) Message-ID: <444E5A35.9020708@motorola.com> Date: Tue, 25 Apr 2006 19:19:49 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip6] Re: Should the MN do reverse DNS lookup to check if at home? References: <44498CEA.4050803@azairenet.com> <444CA5A6.7060905@motorola.com><444D0FDE.508@azairenet.com> <444D339F.9010208@motorola.com><444D34F3.8020701@azairenet.com> <444D3D57.9050604@motorola.com><444D3ECF.9080507@azairenet.com> <444D42F7.5010009@motorola.com><444D466A.2060609@azairenet.com> <444D50B2.2030606@motorola.com><444D5157.8040402@azairenet.com> <444D5470.4090401@motorola.com> <009801c6687e$adefcde0$026115ac@dcml.docomolabsusa.com> <444E57BE.5010706@azairenet.com> In-Reply-To: <444E57BE.5010706@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: mip6@ietf.org, James Kempf X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Vijay Devarapalli wrote: > James Kempf wrote: >>> It's spotty in some places because people don't deploy DNS >>> correctly. With a correctly deployed DNS the reverse tree is >>> right. We should go with the assumption that DNS is deployed >>> correctly. IETF can't make assumptions on how certain protocols >>> are deployed, can just suggest deployers how to do it. >>> >>> If the reverse lookup fails simply don't use that foreign >>> network, drop all connections via it. >>> >> >> I don't think we are talking about failure of the reverse lookup. >> One can certainly argue convincingly that if the reverse lookup >> fails, the MN should drop the address. On the other hand, if the >> reverse tree is not deployed, there will just be no response. It is >> not clear to me that this is sufficient justification for the MN to >> drop the address. The MN can go ahead and try to set up an IKE >> transaction with the HA, and, if it succeeds, it's just an >> indication that the network sysadmins are not so diligent about how >> they deploy the DNS, not that there is an attacker spoofing a DNS >> server and HA. > > I agree with this. there is an IKE authentication that follows > anyway. It follows _if_ MN still believes it is at home. Sorry for insisting on this... Many things were discussed and I'm not sure what you (Vijay) took or not into account. I'll wait for your current text about DNS-based decision of being at home or not and I'll remark on it then. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 25 13:28:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYRL9-0000Ks-Ua; Tue, 25 Apr 2006 13:28:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYRL9-0000Km-Cg for mip6@ietf.org; Tue, 25 Apr 2006 13:28:43 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYRL9-0004T6-0t for mip6@ietf.org; Tue, 25 Apr 2006 13:28:43 -0400 Message-ID: <016b01c6688e$60cefb20$026115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Alexandru Petrescu" References: <444D1503.3020105@motorola.com> <02a201c667e9$338a4b60$026115ac@dcml.docomolabsusa.com> <444D4FA4.8060602@motorola.com> <02f201c667f0$c81af660$026115ac@dcml.docomolabsusa.com> <444D5818.2030801@motorola.com> <009301c6687e$35f89790$026115ac@dcml.docomolabsusa.com> <444E5937.2080000@motorola.com> Date: Tue, 25 Apr 2006 10:33:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: mip6@ietf.org Subject: [Mip6] Re: Binding Refresh Request Security X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > I'm not sure about the following attack. However, I do sense a risk in > rogue AP making MN think it's at home and being able to send it a BRR. > > Legitimate MN is connected to legitimate AP and sends legitimate BUs to > legitimate HA. Rogue AP shows up, MN attaches to it, rogue AP makes it > think it is at home, rogue AP instructs MN to send BU (with BRR), at which > point rogue AP turns off. MN will probably send BU to legitimate HA, > telling it it is at home, which is not. > Even if the rouge AP is able to get packets out with the MN's home address on them as the source address (because the access network doesn't implement ingress filtering), the return packets won't arrive. So just having the rouge AP convince the MN it is at home essentially constitutes a DoS attack on the MN. I don't see what additional risk is added for BRR. > It's probably a minor risk though, just inducing delays, with > re-establishing proper connection with IKE soon after rogue AP turned off. > I think a rouge AP that could spoof an HA would certainly be able to do much more serious damage than send a bogus BRR. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 25 13:54:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYRjh-0007GS-FO; Tue, 25 Apr 2006 13:54:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYRjg-0007GN-39 for mip6@ietf.org; Tue, 25 Apr 2006 13:54:04 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYRje-0005fM-O8 for mip6@ietf.org; Tue, 25 Apr 2006 13:54:04 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id k3PI7C2Z012693; Tue, 25 Apr 2006 11:07:12 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id k3PI5gaC026842; Tue, 25 Apr 2006 13:05:43 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id A9AC1865980; Tue, 25 Apr 2006 19:53:56 +0200 (CEST) Message-ID: <444E6234.9030104@motorola.com> Date: Tue, 25 Apr 2006 19:53:56 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: James Kempf References: <444D1503.3020105@motorola.com> <02a201c667e9$338a4b60$026115ac@dcml.docomolabsusa.com> <444D4FA4.8060602@motorola.com> <02f201c667f0$c81af660$026115ac@dcml.docomolabsusa.com> <444D5818.2030801@motorola.com> <009301c6687e$35f89790$026115ac@dcml.docomolabsusa.com> <444E5937.2080000@motorola.com> <016b01c6688e$60cefb20$026115ac@dcml.docomolabsusa.com> In-Reply-To: <016b01c6688e$60cefb20$026115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: mip6@ietf.org Subject: [Mip6] Re: Binding Refresh Request Security X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org James Kempf wrote: >> I'm not sure about the following attack. However, I do sense a risk >> in rogue AP making MN think it's at home and being able to send it a BRR. >> >> Legitimate MN is connected to legitimate AP and sends legitimate BUs >> to legitimate HA. Rogue AP shows up, MN attaches to it, rogue AP >> makes it think it is at home, rogue AP instructs MN to send BU (with >> BRR), at which point rogue AP turns off. MN will probably send BU to >> legitimate HA, telling it it is at home, which is not. >> > > Even if the rouge AP is able to get packets out with the MN's home > address on them as the source address (because the access network > doesn't implement ingress filtering), the return packets won't arrive. > So just having the rouge AP convince the MN it is at home essentially > constitutes a DoS attack on the MN. I don't see what additional risk is > added for BRR. Probably right... rogue AP could turn off right after the RA/DNS Response too, not necessarily after BRR. >> It's probably a minor risk though, just inducing delays, with >> re-establishing proper connection with IKE soon after rogue AP turned >> off. >> > > I think a rouge AP that could spoof an HA would certainly be able to do > much more serious damage than send a bogus BRR. Right, I was not thinking about real address spoofing, but about simple attacks with rogue AP running AR and DNS server. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 25 14:21:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYS9d-0002fw-Si; Tue, 25 Apr 2006 14:20:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYS9c-0002fr-Hd for mip6@ietf.org; Tue, 25 Apr 2006 14:20:52 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYS9c-00079K-5Y for mip6@ietf.org; Tue, 25 Apr 2006 14:20:52 -0400 Received: from [10.1.201.8] ([10.1.201.8]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Apr 2006 11:20:50 -0700 Message-ID: <444E6882.6000209@azairenet.com> Date: Tue, 25 Apr 2006 11:20:50 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [Mip6] Bootstrapping from the home link References: <44498CEA.4050803@azairenet.com> <444CA5A6.7060905@motorola.com> <444D0FDE.508@azairenet.com> In-Reply-To: <444D0FDE.508@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Apr 2006 18:20:50.0907 (UTC) FILETIME=[FB6952B0:01C66894] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Alex, here is the latest text with the two changes I agreed to make in the email below. 9. Bootstrapping from the home link The mechanisms described in this document also support a mobile node bootstrapping from the home link. When the mobile node is on the home link it receives router advertisements from the home agent with the 'H' bit set and the 128 bit address of the home agent in the modified prefix information option [RFC3775]. When the mobile node bootstraps, the first operation it does is to perform a DNS lookup for the home agent. It is assumed that the mobile node has an IPv6 address, either auto-configured or acquired through DHCPv6 before sending a DNS request. If at least one of the home agent address received in the DNS response matches any of the address the mobile node received in the router advertisement from the home agent, then the mobile node assumes it is attached to the home link. For configuring a home address, the mobile node can either auto- configure a home address, use DHCPv6 or run IKEv2 with its home agent as described in section 5.3. The mobile node MAY setup IPsec security associations to send and receive Mobile IPv6 signaling messages while still attached to the home link. This would help avoid the latency involved in setting up the security associations during a handoff when the mobile node moves out of the home link. The existence of an IPsec SA for protecting a Binding Update does not depend on the existence of a valid binding cache entry. Therefore the mobile node is free to setup the required security associations at any time. the reverse DNS lookup for the HA's IP address could have an impact on this section. but lets agree on something before we add text. I would assume the reverse DNS lookup belongs in the security considerations section. Vijay Vijay Devarapalli wrote: > Alexandru Petrescu wrote: >> Vijay Devarapalli wrote: >>> hello, >>> >>> after some discussions offlist, we came up with some text that could >>> be added to draft-ietf-mip6-bootstrapping-split-02.txt to address >>> bootstrapping from the home link. the proposal is to have this in a >>> new section before the security considerations section. >>> >>> 9. Bootstrapping from the home link >>> >>> The mechanisms described in this document also support a mobile node >>> bootstrapping from the home link. When the mobile node is on the >>> home link it receives router advertisements from the home agent with >>> the 'H' bit set and the 128 bit address of the home agent in the >>> modified prefix information option [RFC3775]. When the mobile node >>> bootstraps, the first operation it does is to perform a DNS lookup >>> for the home agent. >> >> Can MN do DNS lookup before having an Address? I guess no. So I doubt >> the first operation it does is to perform a DNS loookup for the HA. I >> think the first operation it does is to auto-configure an address. > > yes. I guess the current text is confusing. the fact > that the MN configures an address before doing a DNS > lookup was left implicit. > >>> If at least one of the home agent address received in the DNS reply >> >> Isn't that a "DNS Response" or "answer" but not "reply"? > > will change it to "DNS Response". > > Vijay > >> >>> matches the address the mobile node received in the router >>> advertisement from the home agent, then the mobile node assumes it is >>> attached to the home link. >>> >>> For configuring a home address, the mobile node can either auto- >>> configure a home address, use DHCPv6 or run IKEv2 with its home agent >>> as described in section 5.3. >> >> Would MN auto-configure a Address first or decide first whether it >> is at home or not (and do DNS)? >> >> Alex > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 25 15:07:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYSsT-0008SF-47; Tue, 25 Apr 2006 15:07:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYSrj-0007wN-CE for mip6@ietf.org; Tue, 25 Apr 2006 15:06:27 -0400 Received: from atlrel7.hp.com ([156.153.255.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYSgw-0000Sc-QL for mip6@ietf.org; Tue, 25 Apr 2006 14:55:20 -0400 Received: from taynzmail03.nz-tay.cpqcorp.net (relay.cpqcorp.net [16.47.4.103]) by atlrel7.hp.com (Postfix) with ESMTP id EA32934D0B; Tue, 25 Apr 2006 14:55:15 -0400 (EDT) Received: from kitche.zk3.dec.com (kitche1.zk3.dec.com [16.140.160.161]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id 9E6D37A5D; Tue, 25 Apr 2006 14:55:15 -0400 (EDT) Received: from [16.116.96.215] by kitche.zk3.dec.com (8.11.1/1.1.27.5/27Oct00-1235PM) id k3PItCv0000821444; Tue, 25 Apr 2006 14:55:12 -0400 (EDT) Message-ID: <444E7090.50907@hp.com> Date: Tue, 25 Apr 2006 14:55:12 -0400 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051010) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Faizan, Jahanzeb" Subject: Re: [Mip6] HA reliability issue References: <1D490807747A4840A8F4316CFB2A80FD27E50C@s31xs5.systems.smu.edu> In-Reply-To: <1D490807747A4840A8F4316CFB2A80FD27E50C@s31xs5.systems.smu.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: mip6@ietf.org, Richard Frisby X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Faizan, Jahanzeb wrote: > HA reliability is already a "solved" problem. Look at the references below. I am not sure though what the design team is trying to do.....reinventing the wheel or something else? > > > [1] J. Faizan, H. El-Rewini, and M. Khalil, "Problem Statement: Home Agent Reliability," IETF Draft, draft-jfaizan-mipv6-ha-reliability-01.txt (work in progress), November 2003. > > > > [2] J. Faizan, H. El-Rewini, and M. Khalil, "Virtual Home Agent Reliability Protocol (VHARP)," IETF Draft, draft-jfaizan-mipv6-vhar-02.txt (work in progress), April 2004. These drafts all expired in 2004, and have references to other expired drafts. I also noticed that the CUR message isn't implementable since it doesn't precisely define the "data" portion of the message, there might be more. Are there any updates planned? -Brian _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 25 15:12:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYSxZ-0001xi-Fq; Tue, 25 Apr 2006 15:12:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYSxY-0001xd-HW for mip6@ietf.org; Tue, 25 Apr 2006 15:12:28 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYSxX-0001SV-8q for mip6@ietf.org; Tue, 25 Apr 2006 15:12:28 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3PJT8CC000908; Tue, 25 Apr 2006 12:29:08 -0700 (MST) Received: from [144.189.73.111] (mvp-144-189-73-111.corp.mot.com [144.189.73.111]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k3PJTiO3002487; Tue, 25 Apr 2006 14:29:45 -0500 (CDT) Message-ID: <444E7493.6030300@motorola.com> Date: Tue, 25 Apr 2006 21:12:19 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip6] Bootstrapping from the home link References: <44498CEA.4050803@azairenet.com> <444CA5A6.7060905@motorola.com> <444D0FDE.508@azairenet.com> <444E6882.6000209@azairenet.com> In-Reply-To: <444E6882.6000209@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Vijay, thanks for sending this so quickly! Vijay Devarapalli wrote: > Hi Alex, > > here is the latest text with the two changes I agreed to make in the > email below. > > 9. Bootstrapping from the home link > > The mechanisms described in this document also support a mobile node > bootstrapping from the home link. When the mobile node is on the > home link it receives router advertisements from the home agent with > the 'H' bit set and the 128 bit address of the home agent in the > modified prefix information option [RFC3775]. When the mobile node > bootstraps, the first operation it does is to perform a DNS lookup > for the home agent. It is assumed that the mobile node has an IPv6 > address, either auto-configured or acquired through DHCPv6 before ^statelessly ^or derived from EUI-64 (link-local), (because DHCPv6 is auto-configuration too) > sending a DNS request. If at least one of the home agent address > received in the DNS response matches any of the address the mobile > node received in the router advertisement from the home agent, then > the mobile node assumes it is attached to the home link. > > For configuring a home address, the mobile node can either auto- ^sl > configure a home address, use DHCPv6 or run IKEv2 with its home agent > as described in section 5.3. > > The mobile node MAY setup IPsec security associations to send and > receive Mobile IPv6 signaling messages while still attached to the > home link. Ok, agreed. > This would help avoid the latency involved in setting up the security > associations during a handoff when the mobile node moves out of the > home link. The existence of an IPsec SA for protecting a Binding > Update does not depend on the existence of a valid binding cache > entry. Therefore the mobile node is free to setup the required > security associations at any time. Ok, I agree. > the reverse DNS lookup for the HA's IP address could have an impact > on this section. YEs. > but lets agree on something before we add text. So the question is: should MN do both straight and reverse lookups for the pre-configured HA fqdn? Or only straight is sufficient? I'd say both, for avoiding some risks. > I would assume the reverse DNS lookup belongs in the security > considerations section. Ok that too, let's see. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 25 15:14:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYSzs-0002vk-J7; Tue, 25 Apr 2006 15:14:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYSzq-0002vf-Ra for mip6@ietf.org; Tue, 25 Apr 2006 15:14:50 -0400 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYSzp-0001ZB-Kt for mip6@ietf.org; Tue, 25 Apr 2006 15:14:50 -0400 Received: from az33exr02.mot.com ([10.64.251.232]) by motgate7.mot.com (8.12.11/Motgate7) with ESMTP id k3PJkQMB007624; Tue, 25 Apr 2006 12:46:26 -0700 (MST) Received: from [144.189.73.111] (mvp-144-189-73-111.corp.mot.com [144.189.73.111]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id k3PJS7jb025765; Tue, 25 Apr 2006 14:28:09 -0500 (CDT) Message-ID: <444E751F.8090907@motorola.com> Date: Tue, 25 Apr 2006 21:14:39 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: James Kempf References: <444D1503.3020105@motorola.com> <02a201c667e9$338a4b60$026115ac@dcml.docomolabsusa.com> <444D4FA4.8060602@motorola.com> <02f201c667f0$c81af660$026115ac@dcml.docomolabsusa.com> <444D65CC.2060006@motorola.com> <00ae01c66881$17503480$026115ac@dcml.docomolabsusa.com> <444E56B4.4070900@motorola.com> <015901c6688c$b19acc20$026115ac@dcml.docomolabsusa.com> In-Reply-To: <015901c6688c$b19acc20$026115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: mip6@ietf.org Subject: [Mip6] Re: Not using SeND is insecure for DNS-based bootstrapping, but irrelevant if DHAAD-based X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org James Kempf wrote: > Alex, > > We don't seem to be making much progress here. Clearly, you have a > preference for DHAAD. I do, just like many people are biased. It's normal to have preferences from some protocols when implementing them, no? About making progress: I'm trying to, don't get me wrong. > foreign link. You've brought up an issue about the home link, and I'm > going to work up some text on the topic for Section 9, Thanks! Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 25 15:22:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYT7A-00039e-OY; Tue, 25 Apr 2006 15:22:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYT7A-00039Z-2l for mip6@ietf.org; Tue, 25 Apr 2006 15:22:24 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYT74-0001mR-8I for mip6@ietf.org; Tue, 25 Apr 2006 15:22:24 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IYA008JRM6I2G@szxga03-in.huawei.com> for mip6@ietf.org; Wed, 26 Apr 2006 03:30:18 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IYA00FOHM6IWJ@szxga03-in.huawei.com> for mip6@ietf.org; Wed, 26 Apr 2006 03:30:18 +0800 (CST) Received: from [10.124.8.204] by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IYA00KQAMGEF2@szxml02-in.huawei.com>; Wed, 26 Apr 2006 03:36:16 +0800 (CST) Date: Tue, 25 Apr 2006 14:22:04 -0500 From: Behcet Sarikaya Subject: Re: [Mip6] HA reliability issue In-reply-to: <444E7090.50907@hp.com> To: Brian Haley Message-id: <444E76DC.5000504@yahoo.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) References: <1D490807747A4840A8F4316CFB2A80FD27E50C@s31xs5.systems.smu.edu> <444E7090.50907@hp.com> X-Spam-Score: 2.2 (++) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: mip6@ietf.org, "Faizan, Jahanzeb" , Richard Frisby X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Brian Haley wrote: > Faizan, Jahanzeb wrote: > >> HA reliability is already a "solved" problem. Look at the references >> below. I am not sure though what the design team is trying to >> do.....reinventing the wheel or something else? >> >> >> [1] J. Faizan, H. El-Rewini, and M. Khalil, "Problem Statement: >> Home Agent Reliability," IETF Draft, >> draft-jfaizan-mipv6-ha-reliability-01.txt (work in progress), >> November 2003. >> >> >> >> [2] J. Faizan, H. El-Rewini, and M. Khalil, "Virtual Home Agent >> Reliability Protocol (VHARP)," IETF Draft, >> draft-jfaizan-mipv6-vhar-02.txt (work in progress), April 2004. > > > These drafts all expired in 2004, and have references to other expired > drafts. I also noticed that the CUR message isn't implementable since > it doesn't precisely define the "data" portion of the message, there > might be more. Are there any updates planned? > > -Brian > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > Please take this thread to the HA reliability DT mailing list. Thanks. Behcet _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 25 15:38:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYTME-0001Ab-8x; Tue, 25 Apr 2006 15:37:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYTMD-0001AW-3k for mip6@ietf.org; Tue, 25 Apr 2006 15:37:57 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYTMC-0002Id-Qy for mip6@ietf.org; Tue, 25 Apr 2006 15:37:57 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3PJsg9p005238 for ; Tue, 25 Apr 2006 12:54:42 -0700 (MST) Received: from [144.189.73.111] (mvp-144-189-73-111.corp.mot.com [144.189.73.111]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k3PJtIoe013006 for ; Tue, 25 Apr 2006 14:55:19 -0500 (CDT) Message-ID: <444E7A91.7010909@motorola.com> Date: Tue, 25 Apr 2006 21:37:53 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: mip6@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Mip6] How to store DNS records about HAs, (draft-ietf-mip6-bootstrapping-split-02.txt)? X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org I have a question about deploying a home network supporting the bootstrapping solution described in draft-ietf-mip6-bootstrapping-split-02.txt. If it's been already discussed please ignore it: how to store DNS records that would work for this bootstrapping? Suppose I'm owner of domain example.com that has a bunch of subnets and I'd like all the hosts to be able to move, i.e. run MIP6. Subnet1 is served by ha1 and ha2 and subnet2 by other ha1 and ha2. Should I store in DNS: ha1.subnet1.example.com, ha2.subnet1.example.com... ha1.subnet2.example.com, ha2.subnet2.example.com ? Because I guess it is not sufficient to store all HAs directly under example.com, because DNS wouldn't know to return which HAs to which MN. And also because I think there are many deployments that don't do a sub-domain per IP subnet. Second, would this recommendation apply when the SRV method is used too? If the above recommendations is right, it could be put in various ways in the draft. The simplest way would be to go where example.com is first mentioned and say: "(it is assumed that example.com is not subnetted for MNs, all MNs served by example.com are under a unique subnet)". The longer recommendation would try to describe an example deployment. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 25 16:01:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYTij-0004DX-Mv; Tue, 25 Apr 2006 16:01:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYTii-0004CN-ST for mip6@ietf.org; Tue, 25 Apr 2006 16:01:12 -0400 Received: from s31xua.systems.smu.edu ([129.119.70.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYTih-0004D7-L4 for mip6@ietf.org; Tue, 25 Apr 2006 16:01:12 -0400 Received: from s31xs5.systems.smu.edu ([129.119.70.75]) by s31xua.systems.smu.edu with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Apr 2006 15:01:11 -0500 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] HA reliability issue Date: Tue, 25 Apr 2006 15:01:10 -0500 Message-ID: <1D490807747A4840A8F4316CFB2A80FD27E50D@s31xs5.systems.smu.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] HA reliability issue Thread-Index: AcZomcrAK04Y4mDPQ3G8fjcKPItjXwAB6g8R From: "Faizan, Jahanzeb" To: "Brian Haley" X-OriginalArrivalTime: 25 Apr 2006 20:01:11.0038 (UTC) FILETIME=[FFB069E0:01C668A2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: mip6@ietf.org, Richard Frisby X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org We came up with the HA reliability problem statement and initial = solution (VHARP) in Nov 2003 and April 2004, respectively. Later, there = was a consensus call on the list about the hardware or protocol solution = of this problem. The chairs decided to go for the hardware solution and = that's why we stopped updating these drafts. However, we continued our = work on this issue and now have several publications. Thanks Jahanzeb ________________________________ From: Brian Haley [mailto:brian.haley@hp.com] Sent: Tue 4/25/2006 1:55 PM To: Faizan, Jahanzeb Cc: Richard Frisby; mip6@ietf.org Subject: Re: [Mip6] HA reliability issue Faizan, Jahanzeb wrote: > HA reliability is already a "solved" problem. Look at the references = below. I am not sure though what the design team is trying to = do.....reinventing the wheel or something else? >=20 > > [1] J. Faizan, H. El-Rewini, and M. Khalil, "Problem Statement: = Home Agent Reliability," IETF Draft, = draft-jfaizan-mipv6-ha-reliability-01.txt (work in progress), November = 2003. > >=20 > > [2] J. Faizan, H. El-Rewini, and M. Khalil, "Virtual Home Agent = Reliability Protocol (VHARP)," IETF Draft, = draft-jfaizan-mipv6-vhar-02.txt (work in progress), April 2004. These drafts all expired in 2004, and have references to other expired drafts. I also noticed that the CUR message isn't implementable since it doesn't precisely define the "data" portion of the message, there might be more. Are there any updates planned? -Brian _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 25 21:48:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYZ8S-0004KK-41; Tue, 25 Apr 2006 21:48:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYZ8Q-0004KC-6x for mip6@ietf.org; Tue, 25 Apr 2006 21:48:06 -0400 Received: from mout.perfora.net ([217.160.230.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYZ8P-0007x7-13 for mip6@ietf.org; Tue, 25 Apr 2006 21:48:06 -0400 Received: from [202.20.193.195] (helo=sysadmin13c23c) by mrelay.perfora.net (node=mrelayus1) with ESMTP (Nemesis), id 0MKp2t-1FYZ8F2iV5-0001yJ; Tue, 25 Apr 2006 21:48:02 -0400 From: "Alper Yegin" To: "'Alexandru Petrescu'" , "'Soliman, Hesham'" Subject: RE: changing title of the bootstrap-split draft to "DNS-based..."(was: [Mip6] Bootstrapping on the home link) Date: Wed, 26 Apr 2006 10:47:53 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-reply-to: <444D3EA1.6040901@motorola.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-index: AcZn44yO4/ckhu6BQZO7r1rPL+XomQBIcVqQ Message-ID: <0MKp2t-1FYZ8F2iV5-0001yJ@mrelay.perfora.net> X-Provags-ID: perfora.net abuse@perfora.net login:abf7a4bb310ea4dfc9b6841113e2970f X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: mip6@ietf.org, 'James Kempf' , 'Vijay Devarapalli' X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > >> That's why I'm suggesting to title this draft "DNS-based MIP6 MN > >> bootstrapping in split scenario" instead of the current > >> all-covering "MIP6 bootstrapping in split scenario". It leaves the > >> place for other drafts describing other deployments with > >> "DHAAD-based MIP6 MN bootstrapping in split scenario". Would you > >> agree? > > > > => I don't mind either way, it's pretty clear to me that it's > > DNS-based. > > Ok, I understand you wouldn't oppose changing the title as I suggest above. I'd oppose :-) The document states that both DNS and DHCP-based discovery is possible. The DHCP protocol details are not in the document, as we have a separate document for that. We had a very lengthy discussion on that during the design team discussions, and decided to allow both in the same document. The suggested title would not be representative of the text in the document. Alper _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 26 02:16:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYdJr-0008NH-Gn; Wed, 26 Apr 2006 02:16:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYdJq-0008NB-7v for mip6@ietf.org; Wed, 26 Apr 2006 02:16:10 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYdJh-0005sS-Ib for mip6@ietf.org; Wed, 26 Apr 2006 02:16:10 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IYB00L39G1VWW@szxga01-in.huawei.com> for mip6@ietf.org; Wed, 26 Apr 2006 14:15:32 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IYB003I2G1V3M@szxga01-in.huawei.com> for mip6@ietf.org; Wed, 26 Apr 2006 14:15:31 +0800 (CST) Received: from y52774 ([10.164.44.184]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IYB00FBYGUW4O@szxml01-in.huawei.com> for mip6@ietf.org; Wed, 26 Apr 2006 14:33:04 +0800 (CST) Date: Wed, 26 Apr 2006 14:15:01 +0800 From: yechengping In-reply-to: To: mip6@ietf.org Message-id: <000101c668f8$c36d0dc0$b82ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Mip6] About roaming between MIP4 and MIP6! X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi all, There will be a fact that roaming between MIP4 and MIP6 must be considered with deployment of MIP6. There , However,is no solution for the roaming . What do you think about this roaming?Please give your opinions,thanks. BR Chengping Ye _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 26 02:43:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYdjk-0008Hs-Dg; Wed, 26 Apr 2006 02:42:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYdji-0008Hn-0T for mip6@ietf.org; Wed, 26 Apr 2006 02:42:54 -0400 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYdjg-0007Nf-JH for mip6@ietf.org; Wed, 26 Apr 2006 02:42:53 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.10.03) with ESMTP id k3Q6gjmC020992; Wed, 26 Apr 2006 08:42:45 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [192.44.77.29]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.09.01) with ESMTP id k3Q6giv6020984; Wed, 26 Apr 2006 08:42:44 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id k3Q6ghWC005034; Wed, 26 Apr 2006 08:42:43 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200604260642.k3Q6ghWC005034@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Soliman, Hesham" Subject: Re: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt In-reply-to: Your message of Mon, 24 Apr 2006 14:41:14 PDT. <1487A357FD2ED544B8AD29E528FF9DF0023DD4FF@NAEX06.na.qualcomm.com> Date: Wed, 26 Apr 2006 08:42:43 +0200 X-Virus-Scanned: amavisd-new at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Gopal Dommety , mip6@ietf.org, jari.arkko@ericsson.com, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org In your previous mail you wrote: > => so your proposal is some kind of "transport all" mode. I am not > in favor of it because it adds a HAO to every packets. If we consider > the HAO as a degenerate tunnel, it is a spurious double tunneling. => Well, if someone is bothered by the additional bits, => this is not my concern (this is already a tunnel so to avoid MTU madness the internal packet will be limited to 1280, the extra header doesn't really matter). I don't like the transport all mode for architectural reasons. Regards Francis.Dupont@point6.net PS: my concern is specific to MIPv6/NEMO, look at my comment about draft-ietf-v6ops-ipsec-tunnels-02.txt for the other cases. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 26 03:18:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYeIE-00014k-6U; Wed, 26 Apr 2006 03:18:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYe7m-0000NO-75 for mip6@ietf.org; Wed, 26 Apr 2006 03:07:46 -0400 Received: from nav2.lgsoftindia.com ([203.200.13.13] helo=NAV2.LGE.NET) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FYdyz-0007zb-Ky for mip6@ietf.org; Wed, 26 Apr 2006 02:58:46 -0400 Received: from SI-RD10-MS01.LGE.NET ([172.24.1.101]) by NAV2.LGE.NET (SMSSMTP 4.1.2.20) with SMTP id M2006042612241918197 ; Wed, 26 Apr 2006 12:24:19 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mip6] About roaming between MIP4 and MIP6! Date: Wed, 26 Apr 2006 12:27:55 +0530 Message-ID: <607194575BD8CE46BCC8D747996FA7F9CA4092@SI-RD10-MS01.LGE.NET> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] About roaming between MIP4 and MIP6! Thread-Index: AcZo+2QNjOX13YJHQdaTjZg+m1xlaQAAHFDg From: "Shashidhar P Reddy" To: "yechengping" , X-Spam-Score: 0.4 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1103224049==" Errors-To: mip6-bounces@ietf.org --===============1103224049== Content-class: urn:content-classes:message Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 SGkgQ2hlbmdwaW5nLA0KDQpJIGRvIGFncmVlIHdpdGggeW91LiBNSVA2IHNob3VsZCBiZSBt YWRlIGludGVyb3BlcmFibGUgd2l0aCBNSVA0Lg0KDQpUaGVyZSBhcmUgdHdvIHNjZW5hcmlv cyB3aGljaCBjb21lIGludG8gcGljdHVyZSBoZXJlOg0KDQoxLiBJUHY2IE5vZGUgcm9hbWlu ZyBpbiBJUHY0IG5ldHdvcmsuDQoyLiBJUHY0IE5vZGUgcm9hbWluZyBpbiBJUHY2IG5ldHdv cmsuDQoNCjFzdCBzY2VuYXJpbyBjYW4gYmUgaGFuZGxlZCBieSBlbmQgdG8gZW5kIHR1bm5l bGluZyBvZiBJUHY2IHBhY2tldCBpbg0KSVB2NCBwYWNrZXQuIFdvdWxkIHJlcXVpcmUgQ29y cmVzcG9uZGVudCBub2RlICwgSG9tZSBhZ2VudCBhbmQgbW9iaWxlDQpub2RlIHRvDQpNYWlu dGFpbiBCaW5kaW5nIGNhY2hlIG1hcHBpbmcgZm9yIGZvcmVpZ24gSVB2NCBhZGRyZXNzZXMg YWNjb3JkaW5nbHkuDQoNCjJuZCBzY2VuYXJpbyBjYW4gYWxzbyBiZSBoYW5kbGVkIGJ5IHNv bWUgTUlQNiBub2RlIGludGVyY2VwdGluZyB0aGUNCnBhY2tldHMgZm9yIG1vYmlsZSBpcHY0 IG5vZGUgd2hpY2ggYXJlIGluIHRoZSBmb3JtIG9mIElQdjQgcGFja2V0cw0KdHVubmVsZWQg aW4gSVB2Ni4NClRoaXMgTUlQNiBub2RlIHNob3VsZCByZW1vdmUgdGhlIHR1bm5lbCBhbmQg Zm9yd2FyZCBpdCB0byBtb2JpbGUgSVB2NA0Kbm9kZS4NCg0KUGxlYXNlIHBvdXIgaW4geW91 ciBvcGluaW9ucy4NCg0KVGhhbmtzLA0KU2hhc2hpZGhhciBSZWRkeQ0KDQoNCg0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogeWVjaGVuZ3BpbmcgW21haWx0bzp5ZWNo ZW5ncGluZ0BodWF3ZWkuY29tXSANClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMjYsIDIwMDYg MTE6NDUgQU0NClRvOiBtaXA2QGlldGYub3JnDQpTdWJqZWN0OiBbTWlwNl0gQWJvdXQgcm9h bWluZyBiZXR3ZWVuIE1JUDQgYW5kIE1JUDYhDQoNCg0KDQpIaSBhbGwsDQoJVGhlcmUgd2ls bCBiZSBhIGZhY3QgdGhhdCByb2FtaW5nIGJldHdlZW4gTUlQNCBhbmQgTUlQNiBtdXN0IGJl DQpjb25zaWRlcmVkIHdpdGggZGVwbG95bWVudCBvZiBNSVA2LiBUaGVyZSAsIEhvd2V2ZXIs aXMgbm8gc29sdXRpb24gZm9yDQp0aGUgcm9hbWluZyAuIFdoYXQgZG8geW91IHRoaW5rIGFi b3V0IHRoaXMgcm9hbWluZz9QbGVhc2UgZ2l2ZSB5b3VyDQpvcGluaW9ucyx0aGFua3MuDQoN Cg0KQlINCkNoZW5ncGluZyBZZQ0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCk1pcDYgbWFpbGluZyBsaXN0DQpNaXA2QGlldGYub3Jn DQpodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taXA2DQoNCg0KDQoj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMNClRISVMgRU1BSUwgTUVTU0FHRSBJUyBGT1IgVEhFIFNPTEUgVVNFIE9GIFRIRSBJTlRF TkRFRA0KUkVDSVBJRU5UKFMpIEFORCBNQVkgQ09OVEFJTiBDT05GSURFTlRJQUwgQU5EIFBS SVZJTEVHRUQNCklORk9STUFUSU9OLiBBTlkgVU5BVVRIT1JJWkVEIFJFVklFVywgVVNFLCBE SVNDTE9TVVJFIE9SDQpESVNUUklCVVRJT04gSVMgUFJPSElCSVRFRC5CRUZPUkUgT1BFTklO RyBBTlkgQVRUQUNITUVOVFMNClBMRUFTRSBDSEVDSyBGT1IgVklSVVNFUyBBTkQgREVGRUNU Uy5JRiBZT1UgQVJFIE5PVCBUSEUNCklOVEVOREVEIFJFQ0lQSUVOVCwgUExFQVNFIE5PVElG WSBVUyBJTU1FRElBVEVMWSBCWSBSRVBMWQ0KRS1NQUlMIEFORCBERUxFVEUgVEhFIE9SSUdJ TkFMIE1FU1NBR0UuDQojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMj --===============1103224049== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1103224049==-- From mip6-bounces@ietf.org Wed Apr 26 03:45:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYeiR-0005g7-Mb; Wed, 26 Apr 2006 03:45:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYeiP-0005g2-Gf for mip6@ietf.org; Wed, 26 Apr 2006 03:45:37 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYeiI-0002Mk-JY for mip6@ietf.org; Wed, 26 Apr 2006 03:45:37 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IYB00MWCKOGJU@szxga02-in.huawei.com> for mip6@ietf.org; Wed, 26 Apr 2006 15:55:28 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IYB00FG8KOFPQ@szxga02-in.huawei.com> for mip6@ietf.org; Wed, 26 Apr 2006 15:55:28 +0800 (CST) Received: from q52443 ([10.164.45.67]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IYB000X4KNULO@szxml02-in.huawei.com>; Wed, 26 Apr 2006 15:55:17 +0800 (CST) Date: Wed, 26 Apr 2006 15:40:55 +0800 From: qinxia Subject: RE: [Mip6] How to store DNS records about HAs,(draft-ietf-mip6-bootstrapping-split-02.txt)? In-reply-to: <444E7A91.7010909@motorola.com> To: 'Alexandru Petrescu' , mip6@ietf.org Message-id: <000901c66904$c36241e0$712ea40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: 'qinxia' X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hello all, I am pretty much instrersted in this question. In split senario, MNs look up the HA address with HA domain name in DNS system. However,there is a such a question which you present. Something come into my mind. In the draft " draft-melia-mobopts-niho-ps-01", there are some Mobility and Roaming Managers such as MRMH and MRMV. I think something may act as the mobility and roaming entity among ASP and MSP, the entity may provide the MN's subscribe Information such as HA address or HA FQDN. The FQDN should mean only one address. So, it will be easy to look up HA address In DNS system with this FQDN, -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] Sent: Wednesday, April 26, 2006 3:38 AM To: mip6@ietf.org Subject: [Mip6] How to store DNS records about HAs,(draft-ietf-mip6-bootstrapping-split-02.txt)? I have a question about deploying a home network supporting the bootstrapping solution described in draft-ietf-mip6-bootstrapping-split-02.txt. If it's been already discussed please ignore it: how to store DNS records that would work for this bootstrapping? Suppose I'm owner of domain example.com that has a bunch of subnets and I'd like all the hosts to be able to move, i.e. run MIP6. Subnet1 is served by ha1 and ha2 and subnet2 by other ha1 and ha2. Should I store in DNS: ha1.subnet1.example.com, ha2.subnet1.example.com... ha1.subnet2.example.com, ha2.subnet2.example.com ? Because I guess it is not sufficient to store all HAs directly under example.com, because DNS wouldn't know to return which HAs to which MN. And also because I think there are many deployments that don't do a sub-domain per IP subnet. Second, would this recommendation apply when the SRV method is used too? If the above recommendations is right, it could be put in various ways in the draft. The simplest way would be to go where example.com is first mentioned and say: "(it is assumed that example.com is not subnetted for MNs, all MNs served by example.com are under a unique subnet)". The longer recommendation would try to describe an example deployment. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 26 03:45:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYeib-0005hJ-0U; Wed, 26 Apr 2006 03:45:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYeiZ-0005hE-Dm for mip6@ietf.org; Wed, 26 Apr 2006 03:45:47 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYeiT-0002Mk-Ro for mip6@ietf.org; Wed, 26 Apr 2006 03:45:47 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IYB00MGDKUWJU@szxga02-in.huawei.com> for mip6@ietf.org; Wed, 26 Apr 2006 15:59:20 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IYB00A2IKUVW9@szxga02-in.huawei.com> for mip6@ietf.org; Wed, 26 Apr 2006 15:59:20 +0800 (CST) Received: from y52774 ([10.164.44.184]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IYB000NPKUDLO@szxml02-in.huawei.com>; Wed, 26 Apr 2006 15:59:09 +0800 (CST) Date: Wed, 26 Apr 2006 15:44:48 +0800 From: yechengping Subject: RE: [Mip6] About roaming between MIP4 and MIP6! In-reply-to: <607194575BD8CE46BCC8D747996FA7F9CA4092@SI-RD10-MS01.LGE.NET> To: 'Shashidhar P Reddy' , mip6@ietf.org Message-id: <000001c66905$4e81f310$b82ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.2 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Shashidhar, You list two main scenarios with MN'roaming between MIPv6 and MIPv4. I think this roaming shoud include handover,security and bootstrapping.Handover involved in HAv4 (a home agent in MIPv4),HAv6(a home agent in MIPv6),MA(a router between MIPv4 and MIPv6) and so on.And new security perhaps emerged from the handover,so how to solve this problem is also very important. Of cause ,Bootstrapping is also necessary. As far as MN,it is its own characteristic.And it perhaps is with MIPv4,MIPv6 and both MIPv4 and MIPv6. Pour in your opinions,please. BR, Chengping Ye -----Original Message----- From: Shashidhar P Reddy [mailto:shashidhar.p@lgsoftindia.com] Sent: Wednesday, April 26, 2006 2:58 PM To: yechengping; mip6@ietf.org Subject: RE: [Mip6] About roaming between MIP4 and MIP6! Hi Chengping, I do agree with you. MIP6 should be made interoperable with MIP4. There are two scenarios which come into picture here: 1. IPv6 Node roaming in IPv4 network. 2. IPv4 Node roaming in IPv6 network. 1st scenario can be handled by end to end tunneling of IPv6 packet in IPv4 packet. Would require Correspondent node , Home agent and mobile node to Maintain Binding cache mapping for foreign IPv4 addresses accordingly. 2nd scenario can also be handled by some MIP6 node intercepting the packets for mobile ipv4 node which are in the form of IPv4 packets tunneled in IPv6. This MIP6 node should remove the tunnel and forward it to mobile IPv4 node. Please pour in your opinions. Thanks, Shashidhar Reddy -----Original Message----- From: yechengping [mailto:yechengping@huawei.com] Sent: Wednesday, April 26, 2006 11:45 AM To: mip6@ietf.org Subject: [Mip6] About roaming between MIP4 and MIP6! Hi all, There will be a fact that roaming between MIP4 and MIP6 must be considered with deployment of MIP6. There , However,is no solution for the roaming . What do you think about this roaming?Please give your opinions,thanks. BR Chengping Ye _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 ######################################################### THIS EMAIL MESSAGE IS FOR THE SOLE USE OF THE INTENDED RECIPIENT(S) AND MAY CONTAIN CONFIDENTIAL AND PRIVILEGED INFORMATION. ANY UNAUTHORIZED REVIEW, USE, DISCLOSURE OR DISTRIBUTION IS PROHIBITED.BEFORE OPENING ANY ATTACHMENTS PLEASE CHECK FOR VIRUSES AND DEFECTS.IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE NOTIFY US IMMEDIATELY BY REPLY E-MAIL AND DELETE THE ORIGINAL MESSAGE. ########################################################## _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 26 04:09:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYf5O-0005f9-Bv; Wed, 26 Apr 2006 04:09:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYf5M-0005f4-Kv for mip6@ietf.org; Wed, 26 Apr 2006 04:09:20 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYf5L-0004k7-51 for mip6@ietf.org; Wed, 26 Apr 2006 04:09:20 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IYB00MFXLM70P@szxga03-in.huawei.com> for mip6@ietf.org; Wed, 26 Apr 2006 16:15:44 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IYB009U8LM77X@szxga03-in.huawei.com> for mip6@ietf.org; Wed, 26 Apr 2006 16:15:43 +0800 (CST) Received: from y52774 ([10.164.44.184]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IYB00I6UM2BQ9@szxml01-in.huawei.com>; Wed, 26 Apr 2006 16:25:26 +0800 (CST) Date: Wed, 26 Apr 2006 16:07:28 +0800 From: yechengping Subject: RE:RE: [Mip6] About roaming between MIP4 and MIP6! In-reply-to: To: 'Shashidhar P Reddy' , mip6@ietf.org Message-id: <000101c66908$75d13ea0$b82ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.2 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Shashidhar, You list two main scenarios with MN'roaming between MIPv6 and MIPv4. I think this roaming shoud include handover,security and bootstrapping.Handover involved in HAv4 (a home agent in MIPv4),HAv6(a home agent in MIPv6),MA(a router between MIPv4 and MIPv6) and so on.And new security perhaps emerged from the handover,so how to solve this problem is also very important. Of cause ,Bootstrapping is also necessary. As far as MN,it is its own characteristic.And it perhaps is with MIPv4,MIPv6 and both MIPv4 and MIPv6. Pour in your opinions,please. BR, Chengping Ye -----Original Message----- From: Shashidhar P Reddy [mailto:shashidhar.p@lgsoftindia.com] Sent: Wednesday, April 26, 2006 2:58 PM To: yechengping; mip6@ietf.org Subject: RE: [Mip6] About roaming between MIP4 and MIP6! Hi Chengping, I do agree with you. MIP6 should be made interoperable with MIP4. There are two scenarios which come into picture here: 1. IPv6 Node roaming in IPv4 network. 2. IPv4 Node roaming in IPv6 network. 1st scenario can be handled by end to end tunneling of IPv6 packet in IPv4 packet. Would require Correspondent node , Home agent and mobile node to Maintain Binding cache mapping for foreign IPv4 addresses accordingly. 2nd scenario can also be handled by some MIP6 node intercepting the packets for mobile ipv4 node which are in the form of IPv4 packets tunneled in IPv6. This MIP6 node should remove the tunnel and forward it to mobile IPv4 node. Please pour in your opinions. Thanks, Shashidhar Reddy -----Original Message----- From: yechengping [mailto:yechengping@huawei.com] Sent: Wednesday, April 26, 2006 11:45 AM To: mip6@ietf.org Subject: [Mip6] About roaming between MIP4 and MIP6! Hi all, There will be a fact that roaming between MIP4 and MIP6 must be considered with deployment of MIP6. There , However,is no solution for the roaming . What do you think about this roaming?Please give your opinions,thanks. BR Chengping Ye _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 ######################################################### THIS EMAIL MESSAGE IS FOR THE SOLE USE OF THE INTENDED RECIPIENT(S) AND MAY CONTAIN CONFIDENTIAL AND PRIVILEGED INFORMATION. ANY UNAUTHORIZED REVIEW, USE, DISCLOSURE OR DISTRIBUTION IS PROHIBITED.BEFORE OPENING ANY ATTACHMENTS PLEASE CHECK FOR VIRUSES AND DEFECTS.IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE NOTIFY US IMMEDIATELY BY REPLY E-MAIL AND DELETE THE ORIGINAL MESSAGE. ########################################################## _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 26 06:22:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYhA1-0003DN-Q4; Wed, 26 Apr 2006 06:22:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYhA0-0003Cb-9C for mip6@ietf.org; Wed, 26 Apr 2006 06:22:16 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYh9z-0002It-0X for mip6@ietf.org; Wed, 26 Apr 2006 06:22:16 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3QAcfTm000451; Wed, 26 Apr 2006 03:38:41 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id k3QAZsxG001723; Wed, 26 Apr 2006 05:35:54 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id B73E9865980; Wed, 26 Apr 2006 12:21:53 +0200 (CEST) Message-ID: <444F49C1.9050900@motorola.com> Date: Wed, 26 Apr 2006 12:21:53 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Alper Yegin Subject: Re: deployment of MIP6 (was: changing title of the bootstrap-split draft to "DNS-based..."(was: [Mip6] Bootstrapping on the home link)) References: <0MKp2t-1FYZ8F2iV5-0001yJ@mrelay.perfora.net> In-Reply-To: <0MKp2t-1FYZ8F2iV5-0001yJ@mrelay.perfora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: mip6@ietf.org, 'James Kempf' , 'Vijay Devarapalli' , "'Soliman, Hesham'" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Alper Yegin wrote: >>>> That's why I'm suggesting to title this draft "DNS-based MIP6 >>>> MN bootstrapping in split scenario" instead of the current >>>> all-covering "MIP6 bootstrapping in split scenario". It leaves >>>> the place for other drafts describing other deployments with >>>> "DHAAD-based MIP6 MN bootstrapping in split scenario". Would >>>> you agree? >>> => I don't mind either way, it's pretty clear to me that it's >>> DNS-based. >> >> Ok, I understand you wouldn't oppose changing the title as I >> suggest above. > > I'd oppose :-) Ok. > The document states that both DNS and DHCP-based discovery is > possible. The DHCP protocol details are not in the document, as we > have a separate document for that. A MN can't discover the address of its HA via DHCP, in split scenario, because DHCP is a local domain configuration. The foreign domain DHCP server wouldn't know the home domain's HA address, no? Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 26 08:03:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYijf-0004QZ-31; Wed, 26 Apr 2006 08:03:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYijd-0004QU-T8 for mip6@ietf.org; Wed, 26 Apr 2006 08:03:09 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYijc-00005l-Lg for mip6@ietf.org; Wed, 26 Apr 2006 08:03:09 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3QCJt3T013827; Wed, 26 Apr 2006 05:19:55 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k3QCKWK8024994; Wed, 26 Apr 2006 07:20:32 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 39CF0865980; Wed, 26 Apr 2006 14:03:07 +0200 (CEST) Message-ID: <444F617A.4010806@motorola.com> Date: Wed, 26 Apr 2006 14:03:06 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: yechengping Subject: Re: [Mip6] About roaming between MIP4 and MIP6! References: <000101c668f8$c36d0dc0$b82ca40a@china.huawei.com> In-Reply-To: <000101c668f8$c36d0dc0$b82ca40a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org yechengping wrote: > > Hi all, > There will be a fact that roaming between MIP4 and MIP6 must be > considered with deployment of MIP6. There , However,is no solution for > the roaming . What do you think about this roaming?Please give your > opinions,thanks. A MIP6 node accessing a v4 or a v6 network is addressed by the mip6trans DT with document draft-ietf-mip6-nemo-v4traversal-01.txt (DSMIPv6) In the MIP4 WG there's currently discussion about a MIP4 node accessing a v4 or a v6 network, draft-tsirtsis-v4v6-mipv4-01.txt. At the last IETF there was a presentation about DSMIPv4, but apparently no draft. What kind of roaming between MIP4 and MIP6 are you referring to? What does the MN software run? What does the access network offer, v4 or v6 or both? Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 26 08:05:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYimG-000564-Pc; Wed, 26 Apr 2006 08:05:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYimG-00055p-6S for mip6@ietf.org; Wed, 26 Apr 2006 08:05:52 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYimG-0000DT-4x for mip6@ietf.org; Wed, 26 Apr 2006 08:05:52 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FYiYs-0004vh-VJ for mip6@ietf.org; Wed, 26 Apr 2006 07:52:03 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3QC8noi012234; Wed, 26 Apr 2006 05:08:49 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id k3QC6h8D010136; Wed, 26 Apr 2006 07:06:43 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 38D8C865980; Wed, 26 Apr 2006 13:52:01 +0200 (CEST) Message-ID: <444F5EE1.3080506@motorola.com> Date: Wed, 26 Apr 2006 13:52:01 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: qinxia Subject: Re: [Mip6] How to store DNS records about HAs, (draft-ietf-mip6-bootstrapping-split-02.txt)? References: <000901c66904$c36241e0$712ea40a@china.huawei.com> In-Reply-To: <000901c66904$c36241e0$712ea40a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: -2.3 (--) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org qinxia wrote: > Hello all, > > I am pretty much instrersted in this question. > > In split senario, MNs look up the HA address with HA domain name in > DNS system. However,there is a such a question which you present. > > Something come into my mind. In the draft " > draft-melia-mobopts-niho-ps-01", there are some Mobility and Roaming > Managers such as MRMH and MRMV. Ok, if these entities (MRMH and MRMV) run DNS then the question is how to deploy the HA-related data in DNS. > I think something may act as the mobility and roaming entity among > ASP and MSP, the entity may provide the MN's subscribe Information > such as HA address or HA FQDN. The FQDN should mean only one > address. So, it will be easy to look up HA address In DNS system with > this FQDN, Ok, but the question is still how to related the fqdn of a HA to the home link prefix it serves, and I believe only in DNS it could be done. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 26 09:39:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYkEz-00022G-Qj; Wed, 26 Apr 2006 09:39:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYkEz-000227-4Z for mip6@ietf.org; Wed, 26 Apr 2006 09:39:37 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYkEx-00052V-Ms for mip6@ietf.org; Wed, 26 Apr 2006 09:39:37 -0400 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Apr 2006 15:39:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Re: Should we assume SeND in foreign/visited networks? (was:Substitute "high risk" for "mitigated risk" in SecurityConsiderations of draft-ietf-mip6-bootstrapping-split-02.txt) Date: Wed, 26 Apr 2006 15:39:32 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Re: Should we assume SeND in foreign/visited networks? (was:Substitute "high risk" for "mitigated risk" in SecurityConsiderations of draft-ietf-mip6-bootstrapping-split-02.txt) Thread-Index: AcZogvwZ4LuMRsBXRNGj4KbQITI+wgAsrDAw From: "COMBES Jean-Michel RD-MAPS-ISS" To: "James Kempf" , "Alexandru Petrescu" X-OriginalArrivalTime: 26 Apr 2006 13:39:33.0051 (UTC) FILETIME=[D9D6A0B0:01C66936] X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com]=20 > Sent: Tuesday, April 25, 2006 5:58 PM > To: Alexandru Petrescu > Cc: mip6@ietf.org > Subject: [Mip6] Re: Should we assume SeND in foreign/visited=20 > networks? (was:Substitute "high risk" for "mitigated risk" in=20 > SecurityConsiderations of draft-ietf-mip6-bootstrapping-split-02.txt) >=20 > > James, I think I didn't make myself clear (if you got my message=20 > > please skip this). It's the DNS bootstrapping method that tells MN=20 > > whether it's at home or not. Clearly, a rogue AP/AR/DNS server can=20 > > instruct a MN as apparently being at home. This indication doesn't=20 > > involve cert verification, because comes from RA and DNS. > > > > You're proposing this attack be foiled by running SeND on the home=20 > > network. But it should actually run on all foreign=20 > networks where MN=20 > > attaches. To foil the attack, the MN shouldn't talk to any network=20 > > that is not able to send SeND signatures on RAs. > > >=20 > Right, if the 'H' bit is set on an RA in a foreign network,=20 > how can the MN trust it? >=20 > This is something for the updated version of RFC 3775, I=20 > think. Beyond the scope of the bootstrapping draft. >=20 > > So, do you propose to assume SeND is deployed on many=20 > access networks? > > >=20 > Well, I think SEND should be deployed on all last hop IPv6=20 > networks. Having been the victim of an ARP spoofing attack=20 > (on IPv4) myself , I can categorically state that the threat=20 > is real, but most people don't seem to take it seriously. In=20 > fact, I just got email the other day from a former IETF SEC=20 > AD that he had suffered some kind of attack due to an=20 > unsecured RA in IPv6. I don't know what the implementation=20 > status of SEND is, but some people seem to be unhappy about=20 > the fact that it contains IPR, even if the IPR is=20 > royalty-free, which might be holding it up. ... and, AFAIK, IPR are only regarding CGA part of SeND. Correct? >=20 > > If not, I think the risk you and I described above should=20 > be evaluated=20 > > as "high" and not "mitigated" in the section Security=20 > Considerations=20 > > of the draft. >=20 > Like I said, this is really beyond the bootstrapping draft.=20 > RFC 3775 should recommend SEND to mitigate the risk of bogus=20 > HA advertisement. But since RFC > 3775 was written before SEND was completed, there is nothing in it.=20 > Something for RFC 3775bis. >=20 > jak >=20 > jak=20 >=20 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 Best regards. JMC. France Telecom - R&D Division - MAPS/NSS =20 Jean-Michel COMBES, Internet/Intranet Security E-Mail: jeanmichel.combes@francetelecom.com Phone: +33 (0)1 45 29 45 94 Fax: +33 (0)1 45 29 65 19 Mobile: +33 (0)6 07 29 30 16=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 26 09:52:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYkRm-0006Hk-On; Wed, 26 Apr 2006 09:52:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYkRl-0006Hf-7E for mip6@ietf.org; Wed, 26 Apr 2006 09:52:49 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYkRk-0005WM-PC for mip6@ietf.org; Wed, 26 Apr 2006 09:52:49 -0400 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Apr 2006 15:52:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] How to store DNS records about HAs, (draft-ietf-mip6-bootstrapping-split-02.txt)? Date: Wed, 26 Apr 2006 15:52:42 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] How to store DNS records about HAs, (draft-ietf-mip6-bootstrapping-split-02.txt)? Thread-Index: AcZoojwHS50H4uR0RruxlRREyGImzQAlXP1Q From: "COMBES Jean-Michel RD-MAPS-ISS" To: "Alexandru Petrescu" , X-OriginalArrivalTime: 26 Apr 2006 13:52:48.0014 (UTC) FILETIME=[B3AC5AE0:01C66938] X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi, =20 > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com]=20 > Sent: Tuesday, April 25, 2006 9:38 PM > To: mip6@ietf.org > Subject: [Mip6] How to store DNS records about=20 > HAs,(draft-ietf-mip6-bootstrapping-split-02.txt)? >=20 > I have a question about deploying a home network supporting=20 > the bootstrapping solution described in=20 > draft-ietf-mip6-bootstrapping-split-02.txt. If it's been=20 > already discussed please ignore it: how to store DNS records=20 > that would work for this bootstrapping? For me: store the HA anycast address in the DNS (+ DNSSEC) and after use draft-dupont-ikev2-haassign-01.txt to get the right HA The advantages of such a solution: + Only one address to store in the DNS + HA assignment + Security >=20 > Suppose I'm owner of domain example.com that has a bunch of=20 > subnets and I'd like all the hosts to be able to move, i.e.=20 > run MIP6. Subnet1 is served by ha1 and ha2 and subnet2 by=20 > other ha1 and ha2. Should I store in DNS: >=20 > ha1.subnet1.example.com, ha2.subnet1.example.com... > ha1.subnet2.example.com, ha2.subnet2.example.com ? >=20 > Because I guess it is not sufficient to store all HAs=20 > directly under example.com, because DNS wouldn't know to=20 > return which HAs to which MN.=20 > And also because I think there are many deployments that=20 > don't do a sub-domain per IP subnet. >=20 > Second, would this recommendation apply when the SRV method=20 > is used too? >=20 > If the above recommendations is right, it could be put in=20 > various ways in the draft. The simplest way would be to go=20 > where example.com is first mentioned and say: "(it is assumed=20 > that example.com is not subnetted for MNs, all MNs served by=20 > example.com are under a unique subnet)". The longer=20 > recommendation would try to describe an example deployment. >=20 > Alex >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > Best regards. JMC. France Telecom - R&D Division - MAPS/NSS =20 Jean-Michel COMBES, Internet/Intranet Security E-Mail: jeanmichel.combes@francetelecom.com Phone: +33 (0)1 45 29 45 94 Fax: +33 (0)1 45 29 65 19 Mobile: +33 (0)6 07 29 30 16 =20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 26 09:58:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYkWt-0008B9-Lf; Wed, 26 Apr 2006 09:58:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYkWs-00087x-GN for mip6@ietf.org; Wed, 26 Apr 2006 09:58:06 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYkWs-0005iH-8v for mip6@ietf.org; Wed, 26 Apr 2006 09:58:06 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3QEEXMx006254; Wed, 26 Apr 2006 07:14:33 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k3QEEik6014242; Wed, 26 Apr 2006 09:14:45 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 2385E865980; Wed, 26 Apr 2006 15:57:45 +0200 (CEST) Message-ID: <444F7C58.9040905@motorola.com> Date: Wed, 26 Apr 2006 15:57:44 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: COMBES Jean-Michel RD-MAPS-ISS Subject: Re: about deploying SeND (was: [Mip6] Re: Should we assume SeND in foreign/visited networks?) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: mip6@ietf.org, James Kempf X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org COMBES Jean-Michel RD-MAPS-ISS wrote: >>> So, do you propose to assume SeND is deployed on many >> access networks? Well, I think SEND should be deployed on all last >> hop IPv6 networks. Having been the victim of an ARP spoofing attack >> (on IPv4) myself , I can categorically state that the threat is >> real, but most people don't seem to take it seriously. In fact, I >> just got email the other day from a former IETF SEC AD that he had >> suffered some kind of attack due to an unsecured RA in IPv6. I >> don't know what the implementation status of SEND is, but some >> people seem to be unhappy about the fact that it contains IPR, even >> if the IPR is royalty-free, which might be holding it up. > > ... and, AFAIK, IPR are only regarding CGA part of SeND. Once again, I think the issue here is about properly evangelizing this particular protocol. I think we are good at launching good intelligent things but forget about deploying it, and considering that somehow less of an intellectual challenge. In this view I regret the fact the respective mailing list is closed. I.e., if this RF/RAND aspect of this protocol were explained clearly and at each time the question of using SeND comes up, as part of SeND evangelizing, then we could advance and obtain quicker deployment, or at least find out what else (than just IPR aspects) holds SeND deployment back. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 26 10:16:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYkoA-0005Qe-Mw; Wed, 26 Apr 2006 10:15:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYko9-0005QZ-Ur for mip6@ietf.org; Wed, 26 Apr 2006 10:15:57 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYko9-0006pJ-SA for mip6@ietf.org; Wed, 26 Apr 2006 10:15:57 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FYko8-0006Lx-U6 for mip6@ietf.org; Wed, 26 Apr 2006 10:15:57 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3QEWaus010642; Wed, 26 Apr 2006 07:32:36 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k3QEWj7E026112; Wed, 26 Apr 2006 09:32:47 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id D8201865980; Wed, 26 Apr 2006 16:15:44 +0200 (CEST) Message-ID: <444F8090.2050908@motorola.com> Date: Wed, 26 Apr 2006 16:15:44 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: COMBES Jean-Michel RD-MAPS-ISS Subject: Re: [Mip6] How to store DNS records about HAs, (draft-ietf-mip6-bootstrapping-split-02.txt)? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: -2.3 (--) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org COMBES Jean-Michel RD-MAPS-ISS wrote: > Hi, > >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@motorola.com] Sent: Tuesday, April 25, >> 2006 9:38 PM To: mip6@ietf.org Subject: [Mip6] How to store DNS >> records about HAs,(draft-ietf-mip6-bootstrapping-split-02.txt)? >> >> I have a question about deploying a home network supporting the >> bootstrapping solution described in >> draft-ietf-mip6-bootstrapping-split-02.txt. If it's been already >> discussed please ignore it: how to store DNS records that would >> work for this bootstrapping? > > For me: store the HA anycast address in the DNS (+ DNSSEC) and after > use draft-dupont-ikev2-haassign-01.txt to get the right HA I guess it's a good idea. The MN can be configured with the right fqdn, and the fqdn wouldn't need to contain the subnet1 name. The IP address being anycast it designates the entire subnet. Instead of configuring ha1.subnet1.example.com and ha2.subnet1.example.com, the MN1 could be pre-configured only with ha1.example.com and the DNS returns the anycast address corresponding to that subnet and MN chooses an appropriate HA on the home link. Not using IKE as in the above draft means that MN1 should be pre-configured with ha1.subnet1.example.com and ha2.subnet1.example.com, and then somehow decide which HA is best upon DNS Response. This pre-configuration could be considered not minimal (includes "subnet" names) and the one without "subnet" names as more minimal. Remark above I'm not talking about SRV, but the pure fqdn method in draft-split. With SRV, the draft-split assumes that the operator will somehow find a way to put the right HA in the DNS database, but it doesn't say how. While it mentions that MN would dynamically update its home DNS (with DHCP) it doesn't say anything about how HAs would update the home DNS about their own addresses. Clarification is needed. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 26 10:59:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYlTw-0008Up-Bp; Wed, 26 Apr 2006 10:59:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYlTv-0008Uk-5N for mip6@ietf.org; Wed, 26 Apr 2006 10:59:07 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYlTu-0000eP-Ot for mip6@ietf.org; Wed, 26 Apr 2006 10:59:07 -0400 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Apr 2006 16:59:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] How to store DNS records about HAs, (draft-ietf-mip6-bootstrapping-split-02.txt)? Date: Wed, 26 Apr 2006 16:58:42 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] How to store DNS records about HAs, (draft-ietf-mip6-bootstrapping-split-02.txt)? Thread-Index: AcZpO+8NlvIzv+N6SNm9Wk0QWsjbiAABYTbA From: "COMBES Jean-Michel RD-MAPS-ISS" To: "Alexandru Petrescu" X-OriginalArrivalTime: 26 Apr 2006 14:59:05.0360 (UTC) FILETIME=[F65B3100:01C66941] X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com]=20 > Sent: Wednesday, April 26, 2006 4:16 PM > To: COMBES Jean-Michel RD-MAPS-ISS > Cc: mip6@ietf.org > Subject: Re: [Mip6] How to store DNS records about=20 > HAs,(draft-ietf-mip6-bootstrapping-split-02.txt)? >=20 > COMBES Jean-Michel RD-MAPS-ISS wrote: > > Hi, > >=20 > >> -----Original Message----- From: Alexandru Petrescu=20 > >> [mailto:alexandru.petrescu@motorola.com] Sent: Tuesday, April 25, > >> 2006 9:38 PM To: mip6@ietf.org Subject: [Mip6] How to store DNS=20 > >> records about HAs,(draft-ietf-mip6-bootstrapping-split-02.txt)? > >>=20 > >> I have a question about deploying a home network supporting the=20 > >> bootstrapping solution described in=20 > >> draft-ietf-mip6-bootstrapping-split-02.txt. If it's been already=20 > >> discussed please ignore it: how to store DNS records that=20 > would work=20 > >> for this bootstrapping? > >=20 > > For me: store the HA anycast address in the DNS (+ DNSSEC)=20 > and after=20 > > use draft-dupont-ikev2-haassign-01.txt to get the right HA >=20 > I guess it's a good idea. The MN can be configured with the=20 > right fqdn, and the fqdn wouldn't need to contain the subnet1=20 > name. The IP address being anycast it designates the entire=20 > subnet. Instead of configuring ha1.subnet1.example.com and=20 > ha2.subnet1.example.com, the MN1 could be pre-configured only=20 > with ha1.example.com and the DNS returns the anycast address=20 > corresponding to that subnet and MN chooses an appropriate HA=20 > on the home link. s/MN chooses/HA chooses :) >=20 > Not using IKE as in the above draft means that MN1 should be=20 > pre-configured with ha1.subnet1.example.com and=20 > ha2.subnet1.example.com, and then somehow decide which HA is=20 > best upon DNS Response. This pre-configuration could be=20 > considered not minimal (includes "subnet" > names) and the one without "subnet" names as more minimal. >=20 > Remark above I'm not talking about SRV, but the pure fqdn=20 > method in draft-split. >=20 > With SRV, the draft-split assumes that the operator will=20 > somehow find a way to put the right HA in the DNS database,=20 > but it doesn't say how. > While it mentions that MN would dynamically update its home DNS (with > DHCP) it doesn't say anything about how HAs would update the=20 > home DNS about their own addresses. Clarification is needed. >=20 > Alex >=20 >=20 Best regards. JMC. France Telecom - R&D Division - MAPS/NSS =20 Jean-Michel COMBES, Internet/Intranet Security E-Mail: jeanmichel.combes@francetelecom.com Phone: +33 (0)1 45 29 45 94 Fax: +33 (0)1 45 29 65 19 Mobile: +33 (0)6 07 29 30 16=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 26 11:12:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYlgK-0007vD-Ql; Wed, 26 Apr 2006 11:11:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYTr6-0006hZ-R9 for mip6@ietf.org; Tue, 25 Apr 2006 16:09:52 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYTr5-0004cj-Gk for mip6@ietf.org; Tue, 25 Apr 2006 16:09:52 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k3PK9mw16578; Tue, 25 Apr 2006 16:09:48 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] HA reliability issue Date: Tue, 25 Apr 2006 15:09:04 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60B5F621D@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] HA reliability issue Thread-Index: AcZonx/qgWKAMhZkS7qsRa2THBJGDgAAt9BQ From: "Mohamed Khalil" To: "Brian Haley" , "Faizan, Jahanzeb" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-Mailman-Approved-At: Wed, 26 Apr 2006 11:11:54 -0400 Cc: mip6@ietf.org, Richard Frisby X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Brian, We have stopped working in this issue with the WG because the decision at that time is that the HA Reliability & Scalability should be solved by HW, as far as, I remember. The work is done in this area is converted into academic work with several publications in different journals.=20 -----Original Message----- From: Brian Haley [mailto:brian.haley@hp.com]=20 Sent: Tuesday, April 25, 2006 1:55 PM To: Faizan, Jahanzeb Cc: mip6@ietf.org; Richard Frisby Subject: Re: [Mip6] HA reliability issue Faizan, Jahanzeb wrote: > HA reliability is already a "solved" problem. Look at the references=20 > below. I am not sure though what the design team is trying to do.....reinventing the wheel or something else? > =20 >=20 > [1] J. Faizan, H. El-Rewini, and M. Khalil, "Problem Statement: Home Agent Reliability," IETF Draft, draft-jfaizan-mipv6-ha-reliability-01.txt (work in progress), November 2003. >=20 > =20 >=20 > [2] J. Faizan, H. El-Rewini, and M. Khalil, "Virtual Home Agent Reliability Protocol (VHARP)," IETF Draft, draft-jfaizan-mipv6-vhar-02.txt (work in progress), April 2004. These drafts all expired in 2004, and have references to other expired=20 drafts. I also noticed that the CUR message isn't implementable since=20 it doesn't precisely define the "data" portion of the message, there=20 might be more. Are there any updates planned? -Brian _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 26 11:12:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYlgK-0007uu-Ho; Wed, 26 Apr 2006 11:11:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYT73-00039N-VD for mip6@ietf.org; Tue, 25 Apr 2006 15:22:17 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) byFrom mip6-bounces@ietf.org Wed Apr 26 11:12:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYlgK-0007vD-Ql; Wed, 26 Apr 2006 11:11:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYTr6-0006hZ-R9 for mip6@ietf.org; Tue, 25 Apr 2006 16:09:52 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYTr5-0004cj-Gk for mip6@ietf.org; Tue, 25 Apr 2006 16:09:52 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k3PK9mw16578; Tue, 25 Apr 2006 16:09:48 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] HA reliability issue Date: Tue, 25 Apr 2006 15:09:04 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60B5F621D@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] HA reliability issue Thread-Index: AcZonx/qgWKAMhZkS7qsRa2THBJGDgAAt9BQ From: "Mohamed Khalil" To: "Brian Haley" , "Faizan, Jahanzeb" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-Mailman-Approved-At: Wed, 26 Apr 2006 11:11:54 -0400 Cc: mip6@ietf.org, Richard Frisby X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Brian, We have stopped working in this issue with the WG because the decision at that time is that the HA Reliability & Scalability should be solved by HW, as far as, I remember. The work is done in this area is converted into academic work with several publications in different journals.=20 -----Original Message----- From: Brian Haley [mailto:brian.haley@hp.com]=20 Sent: Tuesday, April 25, 2006 1:55 PM To: Faizan, Jahanzeb Cc: mip6@ietf.org; Richard Frisby Subject: Re: [Mip6] HA reliability issue Faizan, Jahanzeb wrote: > HA reliability is already a "solved" problem. Look at the references=20 > below. I am not sure though what the design team is trying to do.....reinventing the wheel or something else? > =20 >=20 > [1] J. Faizan, H. El-Rewini, and M. Khalil, "Problem Statement: Home Agent Reliability," IETF Draft, draft-jfaizan-mipv6-ha-reliability-01.txt (work in progress), November 2003. >=20 > =20 >=20 > [2] J. Faizan, H. El-Rewini, and M. Khalil, "Virtual Home Agent Reliability Protocol (VHARP)," IETF Draft, draft-jfaizan-mipv6-vhar-02.txt (work in progress), April 2004. These drafts all expired in 2004, and have references to other expired=20 drafts. I also noticed that the CUR message isn't implementable since=20 it doesn't precisely define the "data" portion of the message, there=20 might be more. Are there any updates planned? -Brian _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 26 11:12:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYlgK-0007uu-Ho; Wed, 26 Apr 2006 11:11:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYT73-00039N-VD for mip6@ietf.org; Tue, 25 Apr 2006 15:22:17 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYT6p-0001mR-CY for mip6@ietf.org; Tue, 25 Apr 2006 15:22:17 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IYA008FHM4X2G@szxga03-in.huawei.com> for mip6@ietf.org; Wed, 26 Apr 2006 03:29:22 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IYA00FLYM4XWJ@szxga03-in.huawei.com> for mip6@ietf.org; Wed, 26 Apr 2006 03:29:21 +0800 (CST) Received: from [10.124.8.204] by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IYA00KP0MEUF2@szxml02-in.huawei.com>; Wed, 26 Apr 2006 03:35:20 +0800 (CST) Date: Tue, 25 Apr 2006 14:21:08 -0500 From: Behcet Sarikaya Subject: Re: [Mip6] HA reliability issue In-reply-to: <444E7090.50907@hp.com> To: Brian Haley Message-id: <444E76A4.3040706@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) References: <1D490807747A4840A8F4316CFB2A80FD27E50C@s31xs5.systems.smu.edu> <444E7090.50907@hp.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-Mailman-Approved-At: Wed, 26 Apr 2006 11:11:54 -0400 Cc: mip6@ietf.org, "Faizan, Jahanzeb" , Richard Frisby X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Brian Haley wrote: > Faizan, Jahanzeb wrote: > >> HA reliability is already a "solved" problem. Look at the references >> below. I am not sure though what the design team is trying to >> do.....reinventing the wheel or something else? >> >> >> [1] J. Faizan, H. El-Rewini, and M. Khalil, "Problem Statement: >> Home Agent Reliability," IETF Draft, >> draft-jfaizan-mipv6-ha-reliability-01.txt (work in progress), >> November 2003. >> >> >> >> [2] J. Faizan, H. El-Rewini, and M. Khalil, "Virtual Home Agent >> Reliability Protocol (VHARP)," IETF Draft, >> draft-jfaizan-mipv6-vhar-02.txt (work in progress), April 2004. > > > These drafts all expired in 2004, and have references to other expired > drafts. I also noticed that the CUR message isn't implementable since > it doesn't precisely define the "data" portion of the message, there > might be more. Are there any updates planned? > > -Brian > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > Please take this thread to the HA reliability DT mailing list. Thanks. Behcet _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYT6p-0001mR-CY for mip6@ietf.org; Tue, 25 Apr 2006 15:22:17 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IYA008FHM4X2G@szxga03-in.huawei.com> for mip6@ietf.org; Wed, 26 Apr 2006 03:29:22 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IYA00FLYM4XWJ@szxga03-in.huawei.com> for mip6@ietf.org; Wed, 26 Apr 2006 03:29:21 +0800 (CST) Received: from [10.124.8.204] by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IYA00KP0MEUF2@szxml02-in.huawei.com>; Wed, 26 Apr 2006 03:35:20 +0800 (CST) Date: Tue, 25 Apr 2006 14:21:08 -0500 From: Behcet Sarikaya Subject: Re: [Mip6] HA reliability issue In-reply-to: <444E7090.50907@hp.com> To: Brian Haley Message-id: <444E76A4.3040706@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) References: <1D490807747A4840A8F4316CFB2A80FD27E50C@s31xs5.systems.smu.edu> <444E7090.50907@hp.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-Mailman-Approved-At: Wed, 26 Apr 2006 11:11:54 -0400 Cc: mip6@ietf.org, "Faizan, Jahanzeb" , Richard Frisby X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Brian Haley wrote: > Faizan, Jahanzeb wrote: > >> HA reliability is already a "solved" problem. Look at the references >> below. I am not sure though what the design team is trying to >> do.....reinventing the wheel or something else? >> >> >> [1] J. Faizan, H. El-Rewini, and M. Khalil, "Problem Statement: >> Home Agent Reliability," IETF Draft, >> draft-jfaizan-mipv6-ha-reliability-01.txt (work in progress), >> November 2003. >> >> >> >> [2] J. Faizan, H. El-Rewini, and M. Khalil, "Virtual Home Agent >> Reliability Protocol (VHARP)," IETF Draft, >> draft-jfaizan-mipv6-vhar-02.txt (work in progress), April 2004. > > > These drafts all expired in 2004, and have references to other expired > drafts. I also noticed that the CUR message isn't implementable since > it doesn't precisely define the "data" portion of the message, there > might be more. Are there any updates planned? > > -Brian > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > Please take this thread to the HA reliability DT mailing list. Thanks. Behcet _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 26 11:45:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYmDE-0006q5-M2; Wed, 26 Apr 2006 11:45:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYmDD-0006q0-0m for mip6@ietf.org; Wed, 26 Apr 2006 11:45:55 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYmDB-0003n3-Nm for mip6@ietf.org; Wed, 26 Apr 2006 11:45:54 -0400 Received: from [127.0.0.1] ([10.1.210.2]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Apr 2006 08:45:52 -0700 Message-ID: <444F95B8.9060407@azairenet.com> Date: Wed, 26 Apr 2006 08:46:00 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: mip6@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Apr 2006 15:45:52.0174 (UTC) FILETIME=[7F5904E0:01C66948] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Mip6] Re: WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hello folks, a reminder about the WG last call. we would really appreciate a few more opinions/comments. Vijay Basavaraj Patil wrote: > Hello, > > WG I-D: draft-ietf-mip6-ikev2-ipsec-06.txt (Mobile IPv6 Operation with > IKEv2 and the revised IPsec Architecture) has been revised based on > feedback received in the last few months. This document has already > completed a WG last call which was issued in September 05. > > This is a second WG last call for this I-D. Please review and provide > comments and feedback to the authors directly or via the MIP6 mailing > list. The last call will end on May 5th, 2006. > > A diff about the changes made from version 05 to version 06 are at: > http://www.dvijay.com/ietf/internet-drafts/mip6/diff-05to06.html > > -Chairs > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 26 11:58:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYmPR-0006sR-Vz; Wed, 26 Apr 2006 11:58:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYmPQ-0006sM-NR for mip6@ietf.org; Wed, 26 Apr 2006 11:58:32 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYmPQ-0004LA-Bd for mip6@ietf.org; Wed, 26 Apr 2006 11:58:32 -0400 Message-ID: <00b601c6694a$fd24edb0$026115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "COMBES Jean-Michel RD-MAPS-ISS" , "Alexandru Petrescu" References: Subject: Re: [Mip6] Re: Should we assume SeND in foreign/visited networks? (was:Substitute "high risk" for "mitigated risk" in SecurityConsiderations of draft-ietf-mip6-bootstrapping-split-02.txt) Date: Wed, 26 Apr 2006 09:03:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org >... and, AFAIK, IPR are only regarding CGA part of SeND. > >Correct? Yes. BTW, after two years of trying, I have finally received approval to release DoCoMo's OpenSource SEND, for both Linux and BSD. I'll announce it on the IPv6 and SEND mailing lists when the Web site is set up. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 26 11:58:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYmPc-0006td-9Y; Wed, 26 Apr 2006 11:58:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYmPb-0006tX-KS for mip6@ietf.org; Wed, 26 Apr 2006 11:58:43 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYmPa-0004LJ-74 for mip6@ietf.org; Wed, 26 Apr 2006 11:58:43 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3QFwYWv022263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 26 Apr 2006 08:58:35 -0700 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3QFwXk4021482; Wed, 26 Apr 2006 08:58:34 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Apr 2006 08:58:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt Date: Wed, 26 Apr 2006 08:58:32 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF00247DC98@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt Thread-Index: AcZo/LOrCteh6ActSuWyR+fr/41XHQATUqMA From: "Soliman, Hesham" To: X-OriginalArrivalTime: 26 Apr 2006 15:58:33.0139 (UTC) FILETIME=[44EB1030:01C6694A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Gopal Dommety , mip6@ietf.org, jari.arkko@ericsson.com, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > > =3D> so your proposal is some kind of "transport all"=20 > mode. I am not > > in favor of it because it adds a HAO to every packets.=20 > If we consider > > the HAO as a degenerate tunnel, it is a spurious=20 > double tunneling. > =20 > =3D> Well, if someone is bothered by the additional bits, >=20 > =3D> this is not my concern (this is already a tunnel so to avoid MTU > madness the internal packet will be limited to 1280, the extra header > doesn't really matter). I don't like the transport all mode for > architectural reasons. =3D> Ok. can you please elaborate? I know you never liked it but I don't know what the architectural reasons are. I think it's a more "correct" use of IPsec to not use tunnel mode between two end nodes. IMO tunnel mode only needs to be used when an intermediate node is terminating/initiating IPsec.=20 Hesham >=20 > Regards > =20 > Francis.Dupont@point6.net >=20 > PS: my concern is specific to MIPv6/NEMO, look at my comment about > draft-ietf-v6ops-ipsec-tunnels-02.txt for the other cases. >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 26 12:00:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYmRC-0007ee-Rx; Wed, 26 Apr 2006 12:00:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYmR2-0007MW-37 for mip6@ietf.org; Wed, 26 Apr 2006 12:00:13 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYmR1-0004NZ-M4 for mip6@ietf.org; Wed, 26 Apr 2006 12:00:12 -0400 Message-ID: <00d501c6694b$38b72c30$026115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "COMBES Jean-Michel RD-MAPS-ISS" , "Alexandru Petrescu" , References: Subject: Re: [Mip6] How to store DNS records about HAs, (draft-ietf-mip6-bootstrapping-split-02.txt)? Date: Wed, 26 Apr 2006 09:05:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org I think this would require a new SRV record type. jak ----- Original Message ----- From: "COMBES Jean-Michel RD-MAPS-ISS" To: "Alexandru Petrescu" ; Sent: Wednesday, April 26, 2006 6:52 AM Subject: RE: [Mip6] How to store DNS records about HAs,(draft-ietf-mip6-bootstrapping-split-02.txt)? Hi, > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] > Sent: Tuesday, April 25, 2006 9:38 PM > To: mip6@ietf.org > Subject: [Mip6] How to store DNS records about > HAs,(draft-ietf-mip6-bootstrapping-split-02.txt)? > > I have a question about deploying a home network supporting > the bootstrapping solution described in > draft-ietf-mip6-bootstrapping-split-02.txt. If it's been > already discussed please ignore it: how to store DNS records > that would work for this bootstrapping? For me: store the HA anycast address in the DNS (+ DNSSEC) and after use draft-dupont-ikev2-haassign-01.txt to get the right HA The advantages of such a solution: + Only one address to store in the DNS + HA assignment + Security > > Suppose I'm owner of domain example.com that has a bunch of > subnets and I'd like all the hosts to be able to move, i.e. > run MIP6. Subnet1 is served by ha1 and ha2 and subnet2 by > other ha1 and ha2. Should I store in DNS: > > ha1.subnet1.example.com, ha2.subnet1.example.com... > ha1.subnet2.example.com, ha2.subnet2.example.com ? > > Because I guess it is not sufficient to store all HAs > directly under example.com, because DNS wouldn't know to > return which HAs to which MN. > And also because I think there are many deployments that > don't do a sub-domain per IP subnet. > > Second, would this recommendation apply when the SRV method > is used too? > > If the above recommendations is right, it could be put in > various ways in the draft. The simplest way would be to go > where example.com is first mentioned and say: "(it is assumed > that example.com is not subnetted for MNs, all MNs served by > example.com are under a unique subnet)". The longer > recommendation would try to describe an example deployment. > > Alex > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > Best regards. JMC. France Telecom - R&D Division - MAPS/NSS Jean-Michel COMBES, Internet/Intranet Security E-Mail: jeanmichel.combes@francetelecom.com Phone: +33 (0)1 45 29 45 94 Fax: +33 (0)1 45 29 65 19 Mobile: +33 (0)6 07 29 30 16 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 26 12:49:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYnCS-0005AL-7J; Wed, 26 Apr 2006 12:49:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYnCR-0005AG-61 for mip6@ietf.org; Wed, 26 Apr 2006 12:49:11 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYnCQ-0007Ej-T8 for mip6@ietf.org; Wed, 26 Apr 2006 12:49:11 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3QH5qUa013993; Wed, 26 Apr 2006 10:05:55 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k3QH63Qw025812; Wed, 26 Apr 2006 12:06:04 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id D62FE865980; Wed, 26 Apr 2006 18:49:03 +0200 (CEST) Message-ID: <444FA47F.5050104@motorola.com> Date: Wed, 26 Apr 2006 18:49:03 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: James Kempf Subject: Re: [Mip6] How to store DNS records about HAs, (draft-ietf-mip6-bootstrapping-split-02.txt)? References: <00d501c6694b$38b72c30$026115ac@dcml.docomolabsusa.com> In-Reply-To: <00d501c6694b$38b72c30$026115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: mip6@ietf.org, COMBES Jean-Michel RD-MAPS-ISS X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org James Kempf wrote: > I think this would require a new SRV record type. Something that should be agreed by dnsop and registered to IANA? Or something that could be specified in this WG only? Alex > > jak > > ----- Original Message ----- From: "COMBES Jean-Michel RD-MAPS-ISS" > > To: "Alexandru Petrescu" ; > Sent: Wednesday, April 26, 2006 6:52 AM > Subject: RE: [Mip6] How to store DNS records about > HAs,(draft-ietf-mip6-bootstrapping-split-02.txt)? > > > Hi, > >> -----Original Message----- >> From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] >> Sent: Tuesday, April 25, 2006 9:38 PM >> To: mip6@ietf.org >> Subject: [Mip6] How to store DNS records about >> HAs,(draft-ietf-mip6-bootstrapping-split-02.txt)? >> >> I have a question about deploying a home network supporting >> the bootstrapping solution described in >> draft-ietf-mip6-bootstrapping-split-02.txt. If it's been >> already discussed please ignore it: how to store DNS records >> that would work for this bootstrapping? > > For me: store the HA anycast address in the DNS (+ DNSSEC) and after use > draft-dupont-ikev2-haassign-01.txt to get the right HA > > The advantages of such a solution: > + Only one address to store in the DNS > + HA assignment > + Security > >> >> Suppose I'm owner of domain example.com that has a bunch of >> subnets and I'd like all the hosts to be able to move, i.e. >> run MIP6. Subnet1 is served by ha1 and ha2 and subnet2 by >> other ha1 and ha2. Should I store in DNS: >> >> ha1.subnet1.example.com, ha2.subnet1.example.com... >> ha1.subnet2.example.com, ha2.subnet2.example.com ? >> >> Because I guess it is not sufficient to store all HAs >> directly under example.com, because DNS wouldn't know to >> return which HAs to which MN. >> And also because I think there are many deployments that >> don't do a sub-domain per IP subnet. >> >> Second, would this recommendation apply when the SRV method >> is used too? >> >> If the above recommendations is right, it could be put in >> various ways in the draft. The simplest way would be to go >> where example.com is first mentioned and say: "(it is assumed >> that example.com is not subnetted for MNs, all MNs served by >> example.com are under a unique subnet)". The longer >> recommendation would try to describe an example deployment. >> >> Alex >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >> > > Best regards. > > JMC. > > France Telecom - R&D Division - MAPS/NSS > Jean-Michel COMBES, Internet/Intranet Security > E-Mail: jeanmichel.combes@francetelecom.com > Phone: +33 (0)1 45 29 45 94 > Fax: +33 (0)1 45 29 65 19 > Mobile: +33 (0)6 07 29 30 16 > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 26 13:52:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYoBB-0003HQ-W2; Wed, 26 Apr 2006 13:51:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYoBB-0003H8-1Z for mip6@ietf.org; Wed, 26 Apr 2006 13:51:57 -0400 Received: from atlrel7.hp.com ([156.153.255.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYoB8-0001iZ-GY for mip6@ietf.org; Wed, 26 Apr 2006 13:51:57 -0400 Received: from taynzmail03.nz-tay.cpqcorp.net (relay.wipro.tcpn.com [16.47.4.103]) by atlrel7.hp.com (Postfix) with ESMTP id DBC2A354BF; Wed, 26 Apr 2006 13:51:53 -0400 (EDT) Received: from kitche.zk3.dec.com (kitche3.zk3.dec.com [16.140.160.165]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id 97FF88014; Wed, 26 Apr 2006 13:51:53 -0400 (EDT) Received: from [16.116.96.215] by kitche.zk3.dec.com (8.11.1/1.1.27.5/27Oct00-1235PM) id k3QHpnE0001656857; Wed, 26 Apr 2006 13:51:50 -0400 (EDT) Message-ID: <444FB335.1010703@hp.com> Date: Wed, 26 Apr 2006 13:51:49 -0400 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051010) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mohamed Khalil Subject: Re: [Mip6] HA reliability issue References: <62B9B0847CC47543B6B3B5E26BD268E60B5F621D@zrc2hxm2.corp.nortel.com> In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60B5F621D@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: mip6@ietf.org, "Faizan, Jahanzeb" , Richard Frisby X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Mohamed Khalil wrote: > Hi Brian, > > We have stopped working in this issue with the WG because the decision > at that time is that the HA Reliability & Scalability should be solved > by HW, as far as, I remember. The work is done in this area is converted > into academic work with several publications in different journals. Hi Mohamed, I don't think the WG concluded that a hardware solution was the only one necessary, just that some might choose to solve this problem with only hardware - that was my comment back in 2004. All of the people on the DT (including myself) are on the mip6 list, hopefully this will prompt us to have more discussions :) -Brian > -----Original Message----- > From: Brian Haley [mailto:brian.haley@hp.com] > Sent: Tuesday, April 25, 2006 1:55 PM > To: Faizan, Jahanzeb > Cc: mip6@ietf.org; Richard Frisby > Subject: Re: [Mip6] HA reliability issue > > > Faizan, Jahanzeb wrote: > >>HA reliability is already a "solved" problem. Look at the references >>below. I am not sure though what the design team is trying to > > do.....reinventing the wheel or something else? > >> >> >>[1] J. Faizan, H. El-Rewini, and M. Khalil, "Problem Statement: > > Home Agent Reliability," IETF Draft, > draft-jfaizan-mipv6-ha-reliability-01.txt (work in progress), November > 2003. > >> >> >>[2] J. Faizan, H. El-Rewini, and M. Khalil, "Virtual Home Agent > > Reliability Protocol (VHARP)," IETF Draft, > draft-jfaizan-mipv6-vhar-02.txt (work in progress), April 2004. > > These drafts all expired in 2004, and have references to other expired > drafts. I also noticed that the CUR message isn't implementable since > it doesn't precisely define the "data" portion of the message, there > might be more. Are there any updates planned? > > -Brian _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Apr 27 10:48:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ7n7-0007zV-ER; Thu, 27 Apr 2006 10:48:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ7n5-0007yv-IT for mip6@ietf.org; Thu, 27 Apr 2006 10:48:23 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ7n5-0000zM-Gv for mip6@ietf.org; Thu, 27 Apr 2006 10:48:23 -0400 Received: from smtp3.clb.oleane.net ([213.56.31.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FZ7jV-0005Fg-AJ for mip6@ietf.org; Thu, 27 Apr 2006 10:44:44 -0400 Received: from Pavillonquatre ([194.3.133.88]) by smtp3.clb.oleane.net with ESMTP id k3REiVKg028957 for ; Thu, 27 Apr 2006 16:44:40 +0200 Message-Id: <200604271444.k3REiVKg028957@smtp3.clb.oleane.net> From: "Chantal Ladouce" To: Date: Thu, 27 Apr 2006 16:43:31 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZqCPPK8NzlLrt2S3KfnGXjYactbg== X-Spam-Score: 0.1 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Subject: [Mip6] TVoDSL International Conference 2007 - Paris - France X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1962367004==" Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============1962367004== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BD_01C66A19.B79611F0" This is a multi-part message in MIME format. ------=_NextPart_000_00BD_01C66A19.B79611F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The fourth edition of the TVoDSL International Conference and the Triple Play Showcase will stand in Paris next January 23 to 26, 2007. With the opening of a second exhibition floor and the launch of the Mobile TV World Congress, TVoDSL will confirm his rank of very first worldwide rendez-vous in the IPTV realm. A call for proposals has been launched for the TVoDSL conference. All details at: http://www.upperside.fr/tvodsl2007/tvodsl2007intro.htm ------=_NextPart_000_00BD_01C66A19.B79611F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The fourth edition of the TVoDSL International = Conference and the Triple Play Showcase will stand in Paris next January 23 to 26, = 2007.

With the opening of a second exhibition floor = and the launch of the Mobile TV World Congress, TVoDSL will = confirm his rank of very first worldwide rendez-vous in the = IPTV realm.

 

A call for = proposals has been launched for the TVoDSL conference.

=

 

All details = at:

=

http://www.upperside.fr/tvodsl2007/tvodsl2007intro.htm

=

 

------=_NextPart_000_00BD_01C66A19.B79611F0-- --===============1962367004== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1962367004==-- From mip6-bounces@ietf.org Thu Apr 27 14:12:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZAyV-0000mj-AA; Thu, 27 Apr 2006 14:12:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZAyU-0000mM-K0 for mip6@ietf.org; Thu, 27 Apr 2006 14:12:22 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZAhQ-0005RC-8I for mip6@ietf.org; Thu, 27 Apr 2006 13:54:44 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FZASf-0006zt-WF for mip6@ietf.org; Thu, 27 Apr 2006 13:39:30 -0400 Received: from az33exr01.mot.com ([10.64.251.231]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3RHu0BF029733; Thu, 27 Apr 2006 10:56:00 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id k3RI1XmS017401; Thu, 27 Apr 2006 13:01:34 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 096B0865980; Thu, 27 Apr 2006 19:39:09 +0200 (CEST) Message-ID: <445101BC.5040304@motorola.com> Date: Thu, 27 Apr 2006 19:39:08 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Henrik Levkowetz Subject: Re: Again on port number for DS-MIPv6 (was: [Mip6] MN's address as seen by HA is not its CoA but NAT's address (when NAT)) References: <442967C6.5070504@levkowetz.com> In-Reply-To: <442967C6.5070504@levkowetz.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: -2.4 (--) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: "Zhang, Qiang \[NTK\]" , "Soliman, Hesham" , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi, let me bring back this issue about UDP port number with NAT, in DS-MIPv6 draft-ietf-mip6-nemo-v4traversal-01.txt The draft can't be implemented, because the Gateway/HA doesn't know what to put in the dst port number of UDP packets sent back to MN, through NAT. Previously it was said that the Gateway would need to respond back to the NAT with the right dst port number, but that would not be a problem because UDP would copy the incoming src port number and put it into the dst port number towards NAT. Basically it's not enough to just say that "UDP responses go back to the originating port" for several reasons. For (1) strictly speaking, there's no such thing as "UDP response". The UDP header only has src, dst ports and checksum, there is no id there to be able to match responses. Only a protocol carried by UDP, such as DHCP or MIP has "responses", identified by "transaction id" or "identification" respectively, present in the UDP payload. In DS-MIPv6 we try to carry IPv6 in UDP and IPv6 itself doesn't have a "IPv6 response" either, still because no special identifier in the IPv6 packet. Henrik Levkowetz wrote: > [...] regarding the Port number, Alex, but this is no different from > any other UDP responses, which go back to the originating port. To re-iterate, it's not "UDP responses" that go back to originating port but "[protocols carried by UDP] responses". Our carried protocol here is IPv6, and there's no "IPv6 response". (2) The UDP encapsulating interfaces (I'm aware of) don't usually respond to UDP packets. What they do is encapsulate (or de-capsulate) and forward to another interface, according to the routing table. The UDP code (not interface) just forwards the datagram to the proper socket number, based only on port number. To exemplify the problem: DS-MIPv6 section 4.1 "NAT detection and traversal" suggests that the BAck is sent to MN in response of a BU. It is the mip6 code (modified to do DS-MIPv6) that will send the BAck, and put it on the UDP interface. It is not the UDP code in the kernel that replies to this message, it's the mip6 code. (3) Even if the kernel UDP code sent a reply back, it does not have means to store the src port of an incoming BU encapsulated in UDP and eventually put same dst port in the UDP packet encapsulating the reply. While TCP does save data with respect to incoming packets and send back data accordingly, simple UDP doesn't. And this is not all. If we simply add text in the document saying that the dst port number of UDP packets sent to NAT MUST be the same as the src port number in the UDP packet received from NAT - it's not enough, because the spec should provide the implementer a means to relate the two packets. What could this identifier be? And such that it can't be spoofed? (the IPv4 src address can't be used because there's only one NAT for many mobiles behind it, the UDP src port is changed by NAT for same ongoing flow). How should we deal with the port numbers in UDP packets carrying IPv6 when NAT? Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Apr 27 14:24:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZBAT-00040m-1W; Thu, 27 Apr 2006 14:24:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZBAR-00040h-96 for mip6@ietf.org; Thu, 27 Apr 2006 14:24:43 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZBAO-0007sT-Q0 for mip6@ietf.org; Thu, 27 Apr 2006 14:24:43 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3RIOY0X009572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 27 Apr 2006 11:24:35 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3RIOWIC019557; Thu, 27 Apr 2006 11:24:33 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Apr 2006 11:24:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Again on port number for DS-MIPv6 (was: [Mip6] MN's address as seen by HA is not its CoA but NAT's address (when NAT)) Date: Thu, 27 Apr 2006 11:24:32 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF0024F21D1@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Again on port number for DS-MIPv6 (was: [Mip6] MN's address as seen by HA is not its CoA but NAT's address (when NAT)) Thread-Index: AcZqIZmia26SgIjsRoqaDb/HsNqhDQABe7Aw From: "Soliman, Hesham" To: "Alexandru Petrescu" , "Henrik Levkowetz" X-OriginalArrivalTime: 27 Apr 2006 18:24:33.0345 (UTC) FILETIME=[D4D22B10:01C66A27] X-Spam-Score: 1.7 (+) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: "Zhang, Qiang \[NTK\]" , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Alex,=20 I don't understand the problem you seem to see with this. The packet is=20 received with the src and dst ports in it, the receiving implementation would simply send outgoing packets to the src port in the received packet. What is the problem? In this context you can thing of IPv6 as an application running over UDP.=20 Hesham=20 > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com]=20 > Sent: Thursday, April 27, 2006 1:39 PM > To: Henrik Levkowetz > Cc: Zhang, Qiang [NTK]; mip6@ietf.org; Soliman, Hesham > Subject: Re: Again on port number for DS-MIPv6 (was: [Mip6]=20 > MN's address as seen by HA is not its CoA but NAT's address=20 > (when NAT)) >=20 > Hi, let me bring back this issue about UDP port number with NAT, in > DS-MIPv6 draft-ietf-mip6-nemo-v4traversal-01.txt >=20 > The draft can't be implemented, because the Gateway/HA=20 > doesn't know what > to put in the dst port number of UDP packets sent back to=20 > MN, through NAT. >=20 > Previously it was said that the Gateway would need to respond back to > the NAT with the right dst port number, but that would not=20 > be a problem > because UDP would copy the incoming src port number and put=20 > it into the > dst port number towards NAT. >=20 > Basically it's not enough to just say that "UDP responses go=20 > back to the > originating port" for several reasons. For (1) strictly speaking, > there's no such thing as "UDP response". The UDP header=20 > only has src, > dst ports and checksum, there is no id there to be able to match > responses. Only a protocol carried by UDP, such as DHCP or MIP has > "responses", identified by "transaction id" or "identification"=20 > respectively, present in the UDP payload. In DS-MIPv6 we=20 > try to carry=20 > IPv6 in UDP and IPv6 itself doesn't have a "IPv6 response"=20 > either, still=20 > because no special identifier in the IPv6 packet. >=20 > Henrik Levkowetz wrote: > > [...] regarding the Port number, Alex, but this is no=20 > different from=20 > > any other UDP responses, which go back to the originating port. >=20 > To re-iterate, it's not "UDP responses" that go back to=20 > originating port > but "[protocols carried by UDP] responses". Our carried=20 > protocol here > is IPv6, and there's no "IPv6 response". >=20 > (2) The UDP encapsulating interfaces (I'm aware of) don't usually > respond to UDP packets. What they do is encapsulate (or=20 > de-capsulate) > and forward to another interface, according to the routing > table. The UDP code (not interface) just forwards the=20 > datagram to the > proper socket number, based only on port number. >=20 > To exemplify the problem: DS-MIPv6 section 4.1 "NAT detection and > traversal" suggests that the BAck is sent to MN in response=20 > of a BU. It > is the mip6 code (modified to do DS-MIPv6) that will send=20 > the BAck, and > put it on the UDP interface. It is not the UDP code in the=20 > kernel that > replies to this message, it's the mip6 code. >=20 > (3) Even if the kernel UDP code sent a reply back, it does not have=20 > means to store the src port of an incoming BU encapsulated=20 > in UDP and=20 > eventually put same dst port in the UDP packet encapsulating=20 > the reply.=20 > While TCP does save data with respect to incoming packets and send=20 > back data accordingly, simple UDP doesn't. >=20 > And this is not all. If we simply add text in the document > saying that the dst port number of UDP packets sent to NAT=20 > MUST be the > same as the src port number in the UDP packet received from=20 > NAT - it's > not enough, because the spec should provide the implementer=20 > a means to > relate the two packets. What could this identifier be? And such > that it can't be spoofed? (the IPv4 src address can't be=20 > used because > there's only one NAT for many mobiles behind it, the UDP src port is > changed by NAT for same ongoing flow). >=20 > How should we deal with the port numbers in UDP packets carrying IPv6 > when NAT? >=20 > Alex >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Apr 27 14:43:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZBS9-0005TX-O2; Thu, 27 Apr 2006 14:43:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZBS8-0005TP-3f for mip6@ietf.org; Thu, 27 Apr 2006 14:43:00 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZBS6-0000OC-PS for mip6@ietf.org; Thu, 27 Apr 2006 14:43:00 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3RIxkSw013413; Thu, 27 Apr 2006 11:59:46 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k3RJ0QlQ007190; Thu, 27 Apr 2006 14:00:26 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 7882C865980; Thu, 27 Apr 2006 20:42:56 +0200 (CEST) Message-ID: <445110B0.1060502@motorola.com> Date: Thu, 27 Apr 2006 20:42:56 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: Again on port number for DS-MIPv6 (was: [Mip6] MN's address as seen by HA is not its CoA but NAT's address (when NAT)) References: <1487A357FD2ED544B8AD29E528FF9DF0024F21D1@NAEX06.na.qualcomm.com> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF0024F21D1@NAEX06.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 1.7 (+) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: "Zhang, Qiang \[NTK\]" , Henrik Levkowetz , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Soliman, Hesham wrote: > Alex, > > I don't understand the problem you seem to see with this. The packet > is received with the src and dst ports in it, the receiving > implementation would simply send outgoing packets to the src port in > the received packet. What is the problem? Hesham, the question is about implementing it. At UDP level there's no information available to "send outgoing packets to the src port in the received packet" simply because UDP doesn't know what packet needs a response. MIP6 does, and in in the case of BU/BAck only. IPv6 doesn't. TCPv6 doess. App carried in UDPv6 doess too. But these apps don't know about the below UDP naturally. E.g. an IPv6 app on GW needing to write to MN behind NAT has no idea about which UDP dst port number to use, and can't find it on GW. Do you agree? The negative consequence is the following: MN behind NAT sends BU in UDP to GW, mip6 on GW gets it, GW _may_ know how to reply the BAck UDP back to MN - and thus the "UDP tunnel" is open. But after this, if an UDPv6 app wants to write to MN it should write to some UDPv4 dst port number - which one? If it uses the port number previously used by BAck it's not necessarily the good one, because NAT may have removed it. Do you agree? Alex > In this context you can thing of IPv6 as an application running over > UDP. Assume > > Hesham > >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@motorola.com] Sent: Thursday, April 27, >> 2006 1:39 PM To: Henrik Levkowetz Cc: Zhang, Qiang [NTK]; >> mip6@ietf.org; Soliman, Hesham Subject: Re: Again on port number >> for DS-MIPv6 (was: [Mip6] MN's address as seen by HA is not its CoA >> but NAT's address (when NAT)) >> >> Hi, let me bring back this issue about UDP port number with NAT, in >> DS-MIPv6 draft-ietf-mip6-nemo-v4traversal-01.txt >> >> The draft can't be implemented, because the Gateway/HA doesn't know >> what to put in the dst port number of UDP packets sent back to MN, >> through NAT. >> >> Previously it was said that the Gateway would need to respond back >> to the NAT with the right dst port number, but that would not be a >> problem because UDP would copy the incoming src port number and put >> it into the dst port number towards NAT. >> >> Basically it's not enough to just say that "UDP responses go back >> to the originating port" for several reasons. For (1) strictly >> speaking, there's no such thing as "UDP response". The UDP header >> only has src, dst ports and checksum, there is no id there to be >> able to match responses. Only a protocol carried by UDP, such as >> DHCP or MIP has "responses", identified by "transaction id" or >> "identification" respectively, present in the UDP payload. In >> DS-MIPv6 we try to carry IPv6 in UDP and IPv6 itself doesn't have a >> "IPv6 response" either, still because no special identifier in the >> IPv6 packet. >> >> Henrik Levkowetz wrote: >>> [...] regarding the Port number, Alex, but this is no >> different from >>> any other UDP responses, which go back to the originating port. >> >> To re-iterate, it's not "UDP responses" that go back to originating >> port but "[protocols carried by UDP] responses". Our carried >> protocol here is IPv6, and there's no "IPv6 response". >> >> (2) The UDP encapsulating interfaces (I'm aware of) don't usually >> respond to UDP packets. What they do is encapsulate (or >> de-capsulate) and forward to another interface, according to the >> routing table. The UDP code (not interface) just forwards the >> datagram to the proper socket number, based only on port number. >> >> To exemplify the problem: DS-MIPv6 section 4.1 "NAT detection and >> traversal" suggests that the BAck is sent to MN in response of a >> BU. It is the mip6 code (modified to do DS-MIPv6) that will send >> the BAck, and put it on the UDP interface. It is not the UDP code >> in the kernel that replies to this message, it's the mip6 code. >> >> (3) Even if the kernel UDP code sent a reply back, it does not have >> means to store the src port of an incoming BU encapsulated in UDP >> and eventually put same dst port in the UDP packet encapsulating >> the reply. While TCP does save data with respect to incoming >> packets and send back data accordingly, simple UDP doesn't. >> >> And this is not all. If we simply add text in the document saying >> that the dst port number of UDP packets sent to NAT MUST be the >> same as the src port number in the UDP packet received from NAT - >> it's not enough, because the spec should provide the implementer a >> means to relate the two packets. What could this identifier be? >> And such that it can't be spoofed? (the IPv4 src address can't be >> used because there's only one NAT for many mobiles behind it, the >> UDP src port is changed by NAT for same ongoing flow). >> >> How should we deal with the port numbers in UDP packets carrying >> IPv6 when NAT? >> >> Alex >> _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Apr 27 17:11:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZDlL-0007sv-Ll; Thu, 27 Apr 2006 17:10:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZDlK-0007sq-0u for mip6@ietf.org; Thu, 27 Apr 2006 17:10:58 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZDlJ-00030Y-Lg for mip6@ietf.org; Thu, 27 Apr 2006 17:10:58 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3RLRk7a012908; Thu, 27 Apr 2006 14:27:46 -0700 (MST) Received: from [10.169.4.47] (mvp-10-169-4-47.corp.mot.com [10.169.4.47]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id k3RLOw6P028723; Thu, 27 Apr 2006 16:24:59 -0500 (CDT) Message-ID: <4451335C.3020601@motorola.com> Date: Thu, 27 Apr 2006 23:10:52 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: Again on port number for DS-MIPv6 (was: [Mip6] MN's address as seen by HA is not its CoA but NAT's address (when NAT)) References: <1487A357FD2ED544B8AD29E528FF9DF0024F21D1@NAEX06.na.qualcomm.com> <445110B0.1060502@motorola.com> In-Reply-To: <445110B0.1060502@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 1.7 (+) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: "Zhang, Qiang \[NTK\]" , Henrik Levkowetz , "Soliman, Hesham" , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hesham, should I take the lack of reply as an acknowledgement that there _is_ an issue about port numbers for NAT traversal? Alex Alexandru Petrescu wrote: > Soliman, Hesham wrote: >> Alex, >> >> I don't understand the problem you seem to see with this. The >> packet is received with the src and dst ports in it, the receiving >> implementation would simply send outgoing packets to the src port >> in the received packet. What is the problem? > > Hesham, the question is about implementing it. At UDP level there's > no information available to "send outgoing packets to the src port > in the received packet" simply because UDP doesn't know what packet > needs a response. MIP6 does, and in in the case of BU/BAck only. > IPv6 doesn't. TCPv6 doess. App carried in UDPv6 doess too. But > these apps don't know about the below UDP naturally. > > E.g. an IPv6 app on GW needing to write to MN behind NAT has no idea > about which UDP dst port number to use, and can't find it on GW. Do > you agree? > > The negative consequence is the following: MN behind NAT sends BU in > UDP to GW, mip6 on GW gets it, GW _may_ know how to reply the BAck > UDP back to MN - and thus the "UDP tunnel" is open. But after this, > if an UDPv6 app wants to write to MN it should write to some UDPv4 > dst port number - which one? If it uses the port number previously > used by BAck it's not necessarily the good one, because NAT may have > removed it. Do you agree? > > Alex > > > >> In this context you can thing of IPv6 as an application running >> over UDP. > > Assume >> >> Hesham >> >>> -----Original Message----- From: Alexandru Petrescu >>> [mailto:alexandru.petrescu@motorola.com] Sent: Thursday, April >>> 27, 2006 1:39 PM To: Henrik Levkowetz Cc: Zhang, Qiang [NTK]; >>> mip6@ietf.org; Soliman, Hesham Subject: Re: Again on port number >>> for DS-MIPv6 (was: [Mip6] MN's address as seen by HA is not its >>> CoA but NAT's address (when NAT)) >>> >>> Hi, let me bring back this issue about UDP port number with NAT, >>> in DS-MIPv6 draft-ietf-mip6-nemo-v4traversal-01.txt >>> >>> The draft can't be implemented, because the Gateway/HA doesn't >>> know what to put in the dst port number of UDP packets sent back >>> to MN, through NAT. >>> >>> Previously it was said that the Gateway would need to respond >>> back to the NAT with the right dst port number, but that would >>> not be a problem because UDP would copy the incoming src port >>> number and put it into the dst port number towards NAT. >>> >>> Basically it's not enough to just say that "UDP responses go back >>> to the originating port" for several reasons. For (1) strictly >>> speaking, there's no such thing as "UDP response". The UDP >>> header only has src, dst ports and checksum, there is no id there >>> to be able to match responses. Only a protocol carried by UDP, >>> such as DHCP or MIP has "responses", identified by "transaction >>> id" or "identification" respectively, present in the UDP >>> payload. In DS-MIPv6 we try to carry IPv6 in UDP and IPv6 itself >>> doesn't have a "IPv6 response" either, still because no special >>> identifier in the IPv6 packet. >>> >>> Henrik Levkowetz wrote: >>>> [...] regarding the Port number, Alex, but this is no >>> different from >>>> any other UDP responses, which go back to the originating port. >>>> >>>> >>>> >>> >>> To re-iterate, it's not "UDP responses" that go back to >>> originating port but "[protocols carried by UDP] responses". Our >>> carried protocol here is IPv6, and there's no "IPv6 response". >>> >>> (2) The UDP encapsulating interfaces (I'm aware of) don't usually >>> respond to UDP packets. What they do is encapsulate (or >>> de-capsulate) and forward to another interface, according to the >>> routing table. The UDP code (not interface) just forwards the >>> datagram to the proper socket number, based only on port number. >>> >>> To exemplify the problem: DS-MIPv6 section 4.1 "NAT detection and >>> traversal" suggests that the BAck is sent to MN in response of a >>> BU. It is the mip6 code (modified to do DS-MIPv6) that will >>> send the BAck, and put it on the UDP interface. It is not the >>> UDP code in the kernel that replies to this message, it's the >>> mip6 code. >>> >>> (3) Even if the kernel UDP code sent a reply back, it does not >>> have means to store the src port of an incoming BU encapsulated >>> in UDP and eventually put same dst port in the UDP packet >>> encapsulating the reply. While TCP does save data with respect to >>> incoming packets and send back data accordingly, simple UDP >>> doesn't. >>> >>> And this is not all. If we simply add text in the document >>> saying that the dst port number of UDP packets sent to NAT MUST >>> be the same as the src port number in the UDP packet received >>> from NAT - it's not enough, because the spec should provide the >>> implementer a means to relate the two packets. What could this >>> identifier be? And such that it can't be spoofed? (the IPv4 src >>> address can't be used because there's only one NAT for many >>> mobiles behind it, the UDP src port is changed by NAT for same >>> ongoing flow). >>> >>> How should we deal with the port numbers in UDP packets carrying >>> IPv6 when NAT? >>> >>> Alex >>> > > > _______________________________________________ Mip6 mailing list > Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Apr 27 17:18:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZDsq-0002qd-WD; Thu, 27 Apr 2006 17:18:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZDsp-0002qW-MC for mip6@ietf.org; Thu, 27 Apr 2006 17:18:43 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZDso-0003Qz-Qh for mip6@ietf.org; Thu, 27 Apr 2006 17:18:43 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3RLIdsC030205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 27 Apr 2006 14:18:39 -0700 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3RLIGeb020187; Thu, 27 Apr 2006 14:18:38 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Apr 2006 14:18:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Again on port number for DS-MIPv6 (was: [Mip6] MN's address as seen by HA is not its CoA but NAT's address (when NAT)) Date: Thu, 27 Apr 2006 14:18:31 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF0024F2419@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Again on port number for DS-MIPv6 (was: [Mip6] MN's address as seen by HA is not its CoA but NAT's address (when NAT)) Thread-Index: AcZqP6pGhBPSbiQsRhu+C7EAy9fa6QAABR8g From: "Soliman, Hesham" To: "Alexandru Petrescu" X-OriginalArrivalTime: 27 Apr 2006 21:18:33.0451 (UTC) FILETIME=[239BEBB0:01C66A40] X-Spam-Score: 1.7 (+) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: "Zhang, Qiang \[NTK\]" , Henrik Levkowetz , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > Hesham, should I take the lack of reply as an=20 > acknowledgement that there > _is_ an issue about port numbers for NAT traversal? =3D> No you should take it as indication of me being busy.=20 The port numbers can be stored in the MIP6 implementation after a BU is received and reused for normal traffic. You can store them in the relevant BCE. So I don't see a problem here. Hesham =20 >=20 > Alex >=20 > Alexandru Petrescu wrote: > > Soliman, Hesham wrote: > >> Alex, > >>=20 > >> I don't understand the problem you seem to see with this. The=20 > >> packet is received with the src and dst ports in it, the=20 > receiving=20 > >> implementation would simply send outgoing packets to the src port=20 > >> in the received packet. What is the problem? > >=20 > > Hesham, the question is about implementing it. At UDP=20 > level there's > > no information available to "send outgoing packets to the src port > > in the received packet" simply because UDP doesn't know=20 > what packet=20 > > needs a response. MIP6 does, and in in the case of BU/BAck only.=20 > > IPv6 doesn't. TCPv6 doess. App carried in UDPv6 doess too. But=20 > > these apps don't know about the below UDP naturally. > >=20 > > E.g. an IPv6 app on GW needing to write to MN behind NAT=20 > has no idea > > about which UDP dst port number to use, and can't find it=20 > on GW. Do > > you agree? > >=20 > > The negative consequence is the following: MN behind NAT=20 > sends BU in > > UDP to GW, mip6 on GW gets it, GW _may_ know how to reply=20 > the BAck=20 > > UDP back to MN - and thus the "UDP tunnel" is open. But=20 > after this, > > if an UDPv6 app wants to write to MN it should write to=20 > some UDPv4=20 > > dst port number - which one? If it uses the port number=20 > previously=20 > > used by BAck it's not necessarily the good one, because=20 > NAT may have > > removed it. Do you agree? > >=20 > > Alex > >=20 > >=20 > >=20 > >> In this context you can thing of IPv6 as an application running=20 > >> over UDP. > >=20 > > Assume > >>=20 > >> Hesham > >>=20 > >>> -----Original Message----- From: Alexandru Petrescu=20 > >>> [mailto:alexandru.petrescu@motorola.com] Sent: Thursday, April=20 > >>> 27, 2006 1:39 PM To: Henrik Levkowetz Cc: Zhang, Qiang [NTK];=20 > >>> mip6@ietf.org; Soliman, Hesham Subject: Re: Again on port number=20 > >>> for DS-MIPv6 (was: [Mip6] MN's address as seen by HA is not its=20 > >>> CoA but NAT's address (when NAT)) > >>>=20 > >>> Hi, let me bring back this issue about UDP port number with NAT, > >>> in DS-MIPv6 draft-ietf-mip6-nemo-v4traversal-01.txt > >>>=20 > >>> The draft can't be implemented, because the Gateway/HA doesn't=20 > >>> know what to put in the dst port number of UDP packets sent back > >>> to MN, through NAT. > >>>=20 > >>> Previously it was said that the Gateway would need to respond=20 > >>> back to the NAT with the right dst port number, but that would=20 > >>> not be a problem because UDP would copy the incoming src port=20 > >>> number and put it into the dst port number towards NAT. > >>>=20 > >>> Basically it's not enough to just say that "UDP responses go back > >>> to the originating port" for several reasons. For (1) strictly=20 > >>> speaking, there's no such thing as "UDP response". The UDP=20 > >>> header only has src, dst ports and checksum, there is no id there > >>> to be able to match responses. Only a protocol carried by UDP, > >>> such as DHCP or MIP has "responses", identified by "transaction > >>> id" or "identification" respectively, present in the UDP > >>> payload. In DS-MIPv6 we try to carry IPv6 in UDP and IPv6 itself > >>> doesn't have a "IPv6 response" either, still because no special=20 > >>> identifier in the IPv6 packet. > >>>=20 > >>> Henrik Levkowetz wrote: > >>>> [...] regarding the Port number, Alex, but this is no > >>> different from > >>>> any other UDP responses, which go back to the originating port. > >>>>=20 > >>>>=20 > >>>>=20 > >>>=20 > >>> To re-iterate, it's not "UDP responses" that go back to=20 > >>> originating port but "[protocols carried by UDP] responses". Our > >>> carried protocol here is IPv6, and there's no "IPv6 response". > >>>=20 > >>> (2) The UDP encapsulating interfaces (I'm aware of) don't usually > >>> respond to UDP packets. What they do is encapsulate (or=20 > >>> de-capsulate) and forward to another interface, according to the=20 > >>> routing table. The UDP code (not interface) just forwards the=20 > >>> datagram to the proper socket number, based only on port number. > >>>=20 > >>> To exemplify the problem: DS-MIPv6 section 4.1 "NAT detection and > >>> traversal" suggests that the BAck is sent to MN in response of a > >>> BU. It is the mip6 code (modified to do DS-MIPv6) that will=20 > >>> send the BAck, and put it on the UDP interface. It is not the=20 > >>> UDP code in the kernel that replies to this message, it's the=20 > >>> mip6 code. > >>>=20 > >>> (3) Even if the kernel UDP code sent a reply back, it does not=20 > >>> have means to store the src port of an incoming BU encapsulated=20 > >>> in UDP and eventually put same dst port in the UDP packet=20 > >>> encapsulating the reply. While TCP does save data with respect to > >>> incoming packets and send back data accordingly, simple UDP=20 > >>> doesn't. > >>>=20 > >>> And this is not all. If we simply add text in the document=20 > >>> saying that the dst port number of UDP packets sent to NAT MUST=20 > >>> be the same as the src port number in the UDP packet received=20 > >>> from NAT - it's not enough, because the spec should provide the=20 > >>> implementer a means to relate the two packets. What could this=20 > >>> identifier be? And such that it can't be spoofed? (the IPv4 src > >>> address can't be used because there's only one NAT for many=20 > >>> mobiles behind it, the UDP src port is changed by NAT for same=20 > >>> ongoing flow). > >>>=20 > >>> How should we deal with the port numbers in UDP packets carrying=20 > >>> IPv6 when NAT? > >>>=20 > >>> Alex > >>>=20 > >=20 > >=20 > > _______________________________________________ Mip6 mailing list=20 > > Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Apr 27 17:48:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZELc-0007gc-Ln; Thu, 27 Apr 2006 17:48:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZELb-0007gX-R3 for mip6@ietf.org; Thu, 27 Apr 2006 17:48:27 -0400 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZELa-00052R-Hw for mip6@ietf.org; Thu, 27 Apr 2006 17:48:27 -0400 Received: from az33exr04.mot.com ([10.64.251.234]) by motgate7.mot.com (8.12.11/Motgate7) with ESMTP id k3RMKCh7008328; Thu, 27 Apr 2006 15:20:12 -0700 (MST) Received: from [10.169.4.47] (mvp-10-169-4-47.corp.mot.com [10.169.4.47]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id k3RM0AF0013325; Thu, 27 Apr 2006 17:00:11 -0500 (CDT) Message-ID: <44513C22.9090706@motorola.com> Date: Thu, 27 Apr 2006 23:48:18 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: Again on port number for DS-MIPv6 (was: [Mip6] MN's address as seen by HA is not its CoA but NAT's address (when NAT)) References: <1487A357FD2ED544B8AD29E528FF9DF0024F2419@NAEX06.na.qualcomm.com> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF0024F2419@NAEX06.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 1.7 (+) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: "Zhang, Qiang \[NTK\]" , Henrik Levkowetz , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Soliman, Hesham wrote: >> Hesham, should I take the lack of reply as an acknowledgement that >> there _is_ an issue about port numbers for NAT traversal? > > => No you should take it as indication of me being busy. Sorry, I didn't mean to push. Take your time. It's common when some people have time others don't :-) > The port numbers can be stored in the MIP6 implementation after a BU > is received and reused for normal traffic. You can store them in the > relevant BCE. I thought along the same lines. Except that (1) the NAT src port number is visible in clear in UDP and thus spoofable. I guess it should not only present but protected too. And (2) the port number may change while BU/BAck is not happening, and depending on its periodicity it may be bad for apps. I.e. if the BU/BAck happens every 5 minutes then the worse an application can expect is a break for 5 minutes. Last meeting there was discussion on the mike about what to use for heartbeat keepalive. Echo request/Reply and figures like 100seconds were mentioned. That is still a lot for a streaming app, not to mention VoIP. Ping could be sent from MN to GW. But at the same time there are IPv6 RAs sent on the UDP "tunnel" interface. So Echo Reply might not be needed actually, because the RAs represent the keepalive from GW to MN. So maybe there should be something else than Echo Request for heartbeat. Anyways, take your time. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 28 10:59:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZURX-00053s-Fs; Fri, 28 Apr 2006 10:59:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZURW-00053n-LP for mip6@ietf.org; Fri, 28 Apr 2006 10:59:38 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZURW-0006pt-56 for mip6@ietf.org; Fri, 28 Apr 2006 10:59:38 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 5FE6C9001D for ; Fri, 28 Apr 2006 10:59:37 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17976-05 for ; Fri, 28 Apr 2006 10:59:34 -0400 (EDT) Received: from ames.starentnetworks.com (ames.starentnetworks.com [12.33.235.15]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Fri, 28 Apr 2006 10:59:34 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] How to store DNS records about HAs, (draft-ietf-mip6-bootstrapping-split-02.txt)? Date: Fri, 28 Apr 2006 10:57:41 -0400 Message-ID: <8A16DAD84432534FBFC19FD92B50512F05B97A13@ames.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] How to store DNS records about HAs, (draft-ietf-mip6-bootstrapping-split-02.txt)? Thread-Index: AcZoojwHS50H4uR0RruxlRREyGImzQAlXP1QAGbcPzA= From: "Chowdhury, Kuntal" To: "COMBES Jean-Michel RD-MAPS-ISS" , "Alexandru Petrescu" , X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hello, What is proposed here (although looks simple) will only allow the MN to have a "fixed" home link. Operators who use Mobile IP today assign a home agent (i.e. home link) that is geographically close to the point of attachment of the MN or even a home agent in the visited network. Therefore, the concept based on "always the same home link" may not work in real deployment. -Kuntal > -----Original Message----- > From: COMBES Jean-Michel RD-MAPS-ISS > [mailto:jeanmichel.combes@francetelecom.com] > Sent: Wednesday, April 26, 2006 8:53 AM > To: Alexandru Petrescu; mip6@ietf.org > Subject: RE: [Mip6] How to store DNS records about HAs,(draft-ietf-mip6- > bootstrapping-split-02.txt)? >=20 > Hi, >=20 > > -----Original Message----- > > From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] > > Sent: Tuesday, April 25, 2006 9:38 PM > > To: mip6@ietf.org > > Subject: [Mip6] How to store DNS records about > > HAs,(draft-ietf-mip6-bootstrapping-split-02.txt)? > > > > I have a question about deploying a home network supporting > > the bootstrapping solution described in > > draft-ietf-mip6-bootstrapping-split-02.txt. If it's been > > already discussed please ignore it: how to store DNS records > > that would work for this bootstrapping? >=20 > For me: store the HA anycast address in the DNS (+ DNSSEC) and after use > draft-dupont-ikev2-haassign-01.txt to get the right HA >=20 > The advantages of such a solution: > + Only one address to store in the DNS > + HA assignment > + Security >=20 > > > > Suppose I'm owner of domain example.com that has a bunch of > > subnets and I'd like all the hosts to be able to move, i.e. > > run MIP6. Subnet1 is served by ha1 and ha2 and subnet2 by > > other ha1 and ha2. Should I store in DNS: > > > > ha1.subnet1.example.com, ha2.subnet1.example.com... > > ha1.subnet2.example.com, ha2.subnet2.example.com ? > > > > Because I guess it is not sufficient to store all HAs > > directly under example.com, because DNS wouldn't know to > > return which HAs to which MN. > > And also because I think there are many deployments that > > don't do a sub-domain per IP subnet. > > > > Second, would this recommendation apply when the SRV method > > is used too? > > > > If the above recommendations is right, it could be put in > > various ways in the draft. The simplest way would be to go > > where example.com is first mentioned and say: "(it is assumed > > that example.com is not subnetted for MNs, all MNs served by > > example.com are under a unique subnet)". The longer > > recommendation would try to describe an example deployment. > > > > Alex > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > >=20 > Best regards. >=20 > JMC. >=20 > France Telecom - R&D Division - MAPS/NSS > Jean-Michel COMBES, Internet/Intranet Security > E-Mail: jeanmichel.combes@francetelecom.com > Phone: +33 (0)1 45 29 45 94 > Fax: +33 (0)1 45 29 65 19 > Mobile: +33 (0)6 07 29 30 16 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 28 11:09:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZUaf-00046g-IX; Fri, 28 Apr 2006 11:09:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZUae-00046T-Cw for mip6@ietf.org; Fri, 28 Apr 2006 11:09:04 -0400 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZUab-0007Uv-4r for mip6@ietf.org; Fri, 28 Apr 2006 11:09:04 -0400 Received: from az33exr01.mot.com ([10.64.251.231]) by motgate7.mot.com (8.12.11/Motgate7) with ESMTP id k3SFenXJ018839; Fri, 28 Apr 2006 08:40:49 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id k3SFVOvM009967; Fri, 28 Apr 2006 10:31:24 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 7DDEC865980; Fri, 28 Apr 2006 17:08:57 +0200 (CEST) Message-ID: <44523009.5010009@motorola.com> Date: Fri, 28 Apr 2006 17:08:57 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Chowdhury, Kuntal" Subject: Re: [Mip6] How to store DNS records about HAs, (draft-ietf-mip6-bootstrapping-split-02.txt)? References: <8A16DAD84432534FBFC19FD92B50512F05B97A13@ames.starentnetworks.com> In-Reply-To: <8A16DAD84432534FBFC19FD92B50512F05B97A13@ames.starentnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: mip6@ietf.org, COMBES Jean-Michel RD-MAPS-ISS X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Chowdhury, Kuntal wrote: > Hello, > > What is proposed here (although looks simple) will only allow the MN > to have a "fixed" home link. Operators who use Mobile IP today assign > a home agent (i.e. home link) that is geographically close to the > point of attachment of the MN or even a home agent in the visited > network. Therefore, the concept based on "always the same home link" > may not work in real deployment. If operator has 3 locations where HAs are present, it could pre-configure on each phone 3 anycast HA fqdns or 3 home links prefixes. Would this work? If operator considers storing 3 fqdns in each phone as not minimal, what protocol would operator use to store each location's HA address in the DNS? And how would MN know to query the DNS for a specific location HA when all it has is just one fqdn? Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 28 11:13:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZUeX-00073i-8e; Fri, 28 Apr 2006 11:13:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZUeW-00073d-Ii for mip6@ietf.org; Fri, 28 Apr 2006 11:13:04 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZUeV-0007l1-7H for mip6@ietf.org; Fri, 28 Apr 2006 11:13:04 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id k3SFZI8U018972; Fri, 28 Apr 2006 08:35:19 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id k3SFOn2o024861; Fri, 28 Apr 2006 10:24:49 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id A14D2865980; Fri, 28 Apr 2006 17:12:58 +0200 (CEST) Message-ID: <445230FA.7000303@motorola.com> Date: Fri, 28 Apr 2006 17:12:58 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Chowdhury, Kuntal" Subject: Re: Changing home links (was: [Mip6] How to store DNS records about HAs,(draft-ietf-mip6-bootstrapping-split-02.txt)?) References: <8A16DAD84432534FBFC19FD92B50512F05B97A13@ames.starentnetworks.com> In-Reply-To: <8A16DAD84432534FBFC19FD92B50512F05B97A13@ames.starentnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: mip6@ietf.org, COMBES Jean-Michel RD-MAPS-ISS X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Chowdhury, Kuntal wrote: > Therefore, the concept based on "always the same home link" may not > work in real deployment. Right, but changing the home link involves loss of permanent home address, session continuity and reachability. I.e. if I change my home link then I won't obtain same home address so all communications at the previous home address are lost, no? Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 28 11:43:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZV7f-0004P2-LP; Fri, 28 Apr 2006 11:43:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZV7e-0004Ox-SG for mip6@ietf.org; Fri, 28 Apr 2006 11:43:10 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZV7d-0000jx-Hx for mip6@ietf.org; Fri, 28 Apr 2006 11:43:10 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 2F35390003 for ; Fri, 28 Apr 2006 11:43:09 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18770-02 for ; Fri, 28 Apr 2006 11:43:07 -0400 (EDT) Received: from ames.starentnetworks.com (ames.starentnetworks.com [12.33.235.15]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Fri, 28 Apr 2006 11:43:07 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] How to store DNS records about HAs, (draft-ietf-mip6-bootstrapping-split-02.txt)? Date: Fri, 28 Apr 2006 11:41:13 -0400 Message-ID: <8A16DAD84432534FBFC19FD92B50512F05B97A15@ames.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] How to store DNS records about HAs, (draft-ietf-mip6-bootstrapping-split-02.txt)? Thread-Index: AcZq1XAkPaA1uJj/SDCsRkRdzkAr4AAARDew From: "Chowdhury, Kuntal" To: "Alexandru Petrescu" X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: mip6@ietf.org, COMBES Jean-Michel RD-MAPS-ISS X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Alex, Please see inline... > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] > Sent: Friday, April 28, 2006 10:09 AM > To: Chowdhury, Kuntal > Cc: COMBES Jean-Michel RD-MAPS-ISS; mip6@ietf.org > Subject: Re: [Mip6] How to store DNS records about HAs,(draft-ietf-mip6- > bootstrapping-split-02.txt)? >=20 > Chowdhury, Kuntal wrote: > > Hello, > > > > What is proposed here (although looks simple) will only allow the MN > > to have a "fixed" home link. Operators who use Mobile IP today assign > > a home agent (i.e. home link) that is geographically close to the > > point of attachment of the MN or even a home agent in the visited > > network. Therefore, the concept based on "always the same home link" > > may not work in real deployment. >=20 > If operator has 3 locations where HAs are present, it could > pre-configure on each phone 3 anycast HA fqdns or 3 home links prefixes. > Would this work? >=20 [KC>] No, operator's network config changes due to number of reasons. Any fixed config in the MNs especially network layout won't work. > If operator considers storing 3 fqdns in each phone as not minimal, what > protocol would operator use to store each location's HA address in the > DNS? And how would MN know to query the DNS for a specific location HA > when all it has is just one fqdn? >=20 [KC>] Normally, allocation of the most optimum home agent based on the MN's point of attachment is done in the network. I think your question is a valid one, i.e. how does the operator do that using DNS. May be some clarification is required on this (if not there already). > Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 28 11:46:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZVAT-0005lt-HJ; Fri, 28 Apr 2006 11:46:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZVAR-0005jH-VT for mip6@ietf.org; Fri, 28 Apr 2006 11:46:03 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZVAQ-0000qp-Kr for mip6@ietf.org; Fri, 28 Apr 2006 11:46:03 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 5388F90003 for ; Fri, 28 Apr 2006 11:46:02 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18805-09 for ; Fri, 28 Apr 2006 11:46:00 -0400 (EDT) Received: from ames.starentnetworks.com (ames.starentnetworks.com [12.33.235.15]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Fri, 28 Apr 2006 11:46:00 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Changing home links (was: [Mip6] How to store DNS records about HAs, (draft-ietf-mip6-bootstrapping-split-02.txt)?) Date: Fri, 28 Apr 2006 11:44:08 -0400 Message-ID: <8A16DAD84432534FBFC19FD92B50512F04AE50A1@ames.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Changing home links (was: [Mip6] How to store DNS records about HAs, (draft-ietf-mip6-bootstrapping-split-02.txt)?) Thread-Index: AcZq1mK6JIhaZv3xSgiHd9tqM3rNDgABCjzg From: "Chowdhury, Kuntal" To: "Alexandru Petrescu" X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: mip6@ietf.org, COMBES Jean-Michel RD-MAPS-ISS X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org We are talking about bootstrapping. At the time of bootstrapping, the MN does not have a mobility binding. Unless the MN has a static HoA, it will get a dynamic HoA, Home link etc. -Kuntal > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] > Sent: Friday, April 28, 2006 10:13 AM > To: Chowdhury, Kuntal > Cc: COMBES Jean-Michel RD-MAPS-ISS; mip6@ietf.org > Subject: Re: Changing home links (was: [Mip6] How to store DNS records > about HAs,(draft-ietf-mip6-bootstrapping-split-02.txt)?) >=20 > Chowdhury, Kuntal wrote: > > Therefore, the concept based on "always the same home link" may not > > work in real deployment. >=20 > Right, but changing the home link involves loss of permanent home > address, session continuity and reachability. >=20 > I.e. if I change my home link then I won't obtain same home address so > all communications at the previous home address are lost, no? >=20 > Alex >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 28 12:15:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZVch-0004Dr-Th; Fri, 28 Apr 2006 12:15:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZVcg-0004Dm-MZ for mip6@ietf.org; Fri, 28 Apr 2006 12:15:14 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZVcf-0002mC-ET for mip6@ietf.org; Fri, 28 Apr 2006 12:15:14 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3SGW2j7014985; Fri, 28 Apr 2006 09:32:02 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id k3SGTDfK010925; Fri, 28 Apr 2006 11:29:14 -0500 (CDT) Message-ID: <44523F8C.8000802@motorola.com> Date: Fri, 28 Apr 2006 18:15:08 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Chowdhury, Kuntal" Subject: Re: [Mip6] How to store DNS records about HAs, (draft-ietf-mip6-bootstrapping-split-02.txt)? References: <8A16DAD84432534FBFC19FD92B50512F05B97A15@ames.starentnetworks.com> In-Reply-To: <8A16DAD84432534FBFC19FD92B50512F05B97A15@ames.starentnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: mip6@ietf.org, COMBES Jean-Michel RD-MAPS-ISS X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Chowdhury, Kuntal wrote: > Hi Alex, > > Please see inline... > >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@motorola.com] Sent: Friday, April 28, >> 2006 10:09 AM To: Chowdhury, Kuntal Cc: COMBES Jean-Michel >> RD-MAPS-ISS; mip6@ietf.org Subject: Re: [Mip6] How to store DNS >> records about > HAs,(draft-ietf-mip6- >> bootstrapping-split-02.txt)? >> >> Chowdhury, Kuntal wrote: >>> Hello, >>> >>> What is proposed here (although looks simple) will only allow the >>> MN to have a "fixed" home link. Operators who use Mobile IP >>> today >>> > assign >>> a home agent (i.e. home link) that is geographically close to the >>> point of attachment of the MN or even a home agent in the >>> visited network. Therefore, the concept based on "always the same >>> home link" may not work in real deployment. >> If operator has 3 locations where HAs are present, it could >> pre-configure on each phone 3 anycast HA fqdns or 3 home links > prefixes. >> Would this work? >> > [KC>] No, operator's network config changes due to number of reasons. > Any fixed config in the MNs especially network layout won't work. What do you suggest to pre-configure on the mobile (about network layout, not security) that would make bootstrapping work? DHCP's OPTION_CLIENTID? The MAC address? >> If operator considers storing 3 fqdns in each phone as not minimal, >> what protocol would operator use to store each location's HA >> address in the DNS? And how would MN know to query the DNS for a >> specific location HA when all it has is just one fqdn? >> > [KC>] Normally, allocation of the most optimum home agent based on > the MN's point of attachment is done in the network. How? > I think your question is a valid one, i.e. how does the operator do > that using DNS. May be some clarification is required on this (if not > there already). It's not there in draft-split. It just says that operator updates the HA SRV entry in DNS based on some load balancing criteria (not on location or geographically-based). It's not said how to update based on location. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 28 12:21:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZViE-0007B0-7S; Fri, 28 Apr 2006 12:20:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZViD-0007An-7Q for mip6@ietf.org; Fri, 28 Apr 2006 12:20:57 -0400 Received: from yui.nc.u-tokyo.ac.jp ([130.69.251.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZViC-0003SU-Le for mip6@ietf.org; Fri, 28 Apr 2006 12:20:57 -0400 Received: from [172.20.0.27] (p2185-ipad49hodogaya.kanagawa.ocn.ne.jp [60.39.97.185]) (authenticated bits=0) by yui.nc.u-tokyo.ac.jp (8.12.10/8.12.3/Debian-6.4) with ESMTP id k3SGK1Up007192; Sat, 29 Apr 2006 01:20:49 +0900 In-Reply-To: <44513C22.9090706@motorola.com> References: <1487A357FD2ED544B8AD29E528FF9DF0024F2419@NAEX06.na.qualcomm.com> <44513C22.9090706@motorola.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ryuji Wakikawa Subject: Re: Again on port number for DS-MIPv6 (was: [Mip6] MN's address as seen by HA is not its CoA but NAT's address (when NAT)) Date: Sat, 29 Apr 2006 00:59:34 +0900 To: Alexandru Petrescu X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 1.7 (+) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: "Zhang, Qiang \[NTK\]" , Henrik Levkowetz , "Soliman, Hesham" , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Alex Your implementation is on the assumption that the MIP6 is implemented in the kernel. Why may port number change?? I also don't know why RA is tunneled between MN and GW... ryuji On 2006/04/28, at 6:48, Alexandru Petrescu wrote: > Soliman, Hesham wrote: >>> Hesham, should I take the lack of reply as an acknowledgement >>> that there _is_ an issue about port numbers for NAT traversal? >> => No you should take it as indication of me being busy. > > Sorry, I didn't mean to push. Take your time. It's common when some > people have time others don't :-) > >> The port numbers can be stored in the MIP6 implementation after a BU >> is received and reused for normal traffic. You can store them in the >> relevant BCE. > > I thought along the same lines. > > Except that (1) the NAT src port number is visible in clear in UDP and > thus spoofable. I guess it should not only present but protected too. > > And (2) the port number may change while BU/BAck is not happening, and > depending on its periodicity it may be bad for apps. I.e. if the > BU/BAck happens every 5 minutes then the worse an application can > expect > is a break for 5 minutes. > > Last meeting there was discussion on the mike about what to use > for heartbeat keepalive. Echo request/Reply and figures like > 100seconds > were mentioned. That is still a lot for a streaming app, not to > mention > VoIP. > > Ping could be sent from MN to GW. But at the same time there are IPv6 > RAs sent on the UDP "tunnel" interface. So Echo Reply might not be > needed actually, because the RAs represent the keepalive from GW to > MN. > So maybe there should be something else than Echo Request for > heartbeat. > > Anyways, take your time. > > Alex > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 28 12:29:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZVqd-0003UA-5u; Fri, 28 Apr 2006 12:29:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZVqb-0003U5-So for mip6@ietf.org; Fri, 28 Apr 2006 12:29:37 -0400 Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZVqa-00047f-GH for mip6@ietf.org; Fri, 28 Apr 2006 12:29:37 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id k3SGp31C016853 for ; Fri, 28 Apr 2006 09:51:03 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id k3SGkOoP008181 for ; Fri, 28 Apr 2006 11:46:24 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 9A52C865980 for ; Fri, 28 Apr 2006 18:29:34 +0200 (CEST) Message-ID: <445242EE.9050008@motorola.com> Date: Fri, 28 Apr 2006 18:29:34 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: mip6@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [Mip6] Questions on draft-ietf-mip6-bootstrapping-integrated-dhc-00.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Dear authors of draft-ietf-mip6-bootstrapping-integrated-dhc-00.txt, I have some questions and comments on this draft. Shouldn't the DHCP options defined in this draft be proposed to the DHC WG and not to the MIP6 WG? > [fallback case] In the fallback case, the mobile node is not able to > acquire the home agent information via DHCPv6. The mobile node > performs DNS queries to discover the home agent address as defined in > [BOOT-SPLIT]. To perform DNS based home agent discovery, the mobile > node needs to know the DNS server address. How the mobile node > knows the DNS server address is outside the scope of this document. What are the conditions in which the fallback case occurs? Is it because DHCP does not respond? Or just that the DHCP responds with an error when queried about HA? If the latter then the DNS address could be still obtained from DHCP. Otherwise, the DNS address can be pre-configured (in /etc/resolv.conf) or from a LCP (link-control protocol). I don't understand why it's left outside the scope of this document. > (2) The mobile node sends a DHCPv6 Information Request message > [RFC3315] to the All_DHCP_Relay_Agents_and_Servers multicast address. > In this message the mobile node (DHCP client) SHALL include the > Option Code for Home Network Identifier Option [HAOPT] in the > OPTION_ORO, Home Network Identifier Option with id-type set to 1 and > the Home Network Identifier field set to the network realm of the > home MSP [HAOPT]. Currently a network realm part of NAI designates several subnets (HAOPT uses NAI). So if in a network domain (realm) there are several subnets, there should be several home agents there. How does DHCP and AAAH know which HA to return to MN when the identifier is only a generic network realm? Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 28 12:38:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZVz2-0000fD-IS; Fri, 28 Apr 2006 12:38:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZVz1-0000f2-Uh for mip6@ietf.org; Fri, 28 Apr 2006 12:38:19 -0400 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZVz0-0004bx-JJ for mip6@ietf.org; Fri, 28 Apr 2006 12:38:19 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id k3SGo6iq028150; Fri, 28 Apr 2006 09:50:06 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id k3SH0Z95010876; Fri, 28 Apr 2006 12:00:36 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 526BB865980; Fri, 28 Apr 2006 18:38:08 +0200 (CEST) Message-ID: <445244F0.4010905@motorola.com> Date: Fri, 28 Apr 2006 18:38:08 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Ryuji Wakikawa Subject: Re: Again on port number for DS-MIPv6 (was: [Mip6] MN's address as seen by HA is not its CoA but NAT's address (when NAT)) References: <1487A357FD2ED544B8AD29E528FF9DF0024F2419@NAEX06.na.qualcomm.com> <44513C22.9090706@motorola.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 1.7 (+) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: "Zhang, Qiang \[NTK\]" , Henrik Levkowetz , "Soliman, Hesham" , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Ryuji Wakikawa wrote: > Hi Alex > > Your implementation is on the assumption that the MIP6 is implemented > in the kernel. Yes but that doesn't matter. Being in the kernel does not exclude the fact that it's the mip6 code that responds to BU, not UDP code. Also, think that any IPv6 application on GW may try to contact the MN while MN is behind a NAT. How does the ds-mipv6 code (either kernel or userspace) know to encapsulate to what UDP port number? > Why may port number change?? Because it does so. Certain NATs deployed widely for a large number of wireless subscribers do so. Whenever MN opens a UDP "connection" through NAT to GW the state created there only lasts for some time, for a timelength which is little predictable. And, since the draft doesn't offer a NAT state maintenance procedure I assume the port number changes. Is this wrong? > I also don't know why RA is tunneled between MN and GW... For MN to be able to simply auto-configure a IPv6 CoA when behind NAT. How do you propose MN to auto-configure an IPv6 CoA when behind NAT? Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 28 12:40:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZW0c-0001qs-RN; Fri, 28 Apr 2006 12:39:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZW0N-0001SO-NZ for mip6@ietf.org; Fri, 28 Apr 2006 12:39:43 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZW0M-0004i1-Ga for mip6@ietf.org; Fri, 28 Apr 2006 12:39:43 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3SGuW82020863; Fri, 28 Apr 2006 09:56:32 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k3SGvBu6012555; Fri, 28 Apr 2006 11:57:11 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 0B831865980; Fri, 28 Apr 2006 18:39:40 +0200 (CEST) Message-ID: <4452454B.2020106@motorola.com> Date: Fri, 28 Apr 2006 18:39:39 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Chowdhury, Kuntal" Subject: Re: Changing home links (was: [Mip6] How to store DNS records about HAs,(draft-ietf-mip6-bootstrapping-split-02.txt)?) References: <8A16DAD84432534FBFC19FD92B50512F04AE50A1@ames.starentnetworks.com> In-Reply-To: <8A16DAD84432534FBFC19FD92B50512F04AE50A1@ames.starentnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: mip6@ietf.org, COMBES Jean-Michel RD-MAPS-ISS X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Chowdhury, Kuntal wrote: > We are talking about bootstrapping. At the time of bootstrapping, the MN > does not have a mobility binding. Unless the MN has a static HoA, it > will get a dynamic HoA, Home link etc. What's a "static HoA"? Is it one that is pre-configured on MN? Would operators accept a pre-configured HoA on MN? Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 28 12:56:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZWH0-0001wF-HZ; Fri, 28 Apr 2006 12:56:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZWGy-0001mt-Dx for mip6@ietf.org; Fri, 28 Apr 2006 12:56:52 -0400 Received: from email1.etri.re.kr ([129.254.16.131] helo=email1.etri.info) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZWGx-0005dJ-NF for mip6@ietf.org; Fri, 28 Apr 2006 12:56:52 -0400 Received: from FLY ([129.254.1.8]) by email1.etri.info with Microsoft SMTPSVC(6.0.3790.1830); Sat, 29 Apr 2006 01:59:37 +0900 Message-ID: <002301c66ae4$bd750b50$b28feada@FLY> From: "Junghoon Jee" To: "Alexandru Petrescu" , References: <445242EE.9050008@motorola.com> Subject: Re: [Mip6] Questions ondraft-ietf-mip6-bootstrapping-integrated-dhc-00.txt Date: Sat, 29 Apr 2006 01:56:48 +0900 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-OriginalArrivalTime: 28 Apr 2006 16:59:37.0853 (UTC) FILETIME=[22158AD0:01C66AE5] X-Spam-Score: 0.2 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2004502699==" Errors-To: mip6-bounces@ietf.org --===============2004502699== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGkgQWxleCwNCkxldCBtZSB0cnkgdG8gcmVwbHkgdG8geW91ciBxdWVzdGlvbnMuDQoNCi0tLS0t IE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiQWxleGFuZHJ1IFBldHJlc2N1IiA8YWxl eGFuZHJ1LnBldHJlc2N1QG1vdG9yb2xhLmNvbT4NClRvOiA8bWlwNkBpZXRmLm9yZz4NClNlbnQ6 IFNhdHVyZGF5LCBBcHJpbCAyOSwgMjAwNiAxOjI5IEFNDQpTdWJqZWN0OiBbTWlwNl0gUXVlc3Rp b25zIG9uZHJhZnQtaWV0Zi1taXA2LWJvb3RzdHJhcHBpbmctaW50ZWdyYXRlZC1kaGMtMDAudHh0 DQoNCg0KPiANCj4gRGVhciBhdXRob3JzIG9mIGRyYWZ0LWlldGYtbWlwNi1ib290c3RyYXBwaW5n LWludGVncmF0ZWQtZGhjLTAwLnR4dCwgSQ0KPiBoYXZlIHNvbWUgcXVlc3Rpb25zIGFuZCBjb21t ZW50cyBvbiB0aGlzIGRyYWZ0Lg0KPiANCj4gU2hvdWxkbid0IHRoZSBESENQIG9wdGlvbnMgZGVm aW5lZCBpbiB0aGlzIGRyYWZ0IGJlIHByb3Bvc2VkIHRvIHRoZSBESEMNCj4gV0cgYW5kIG5vdCB0 byB0aGUgTUlQNiBXRz8NCg0KVGhlcmUncyBhbHJlYWR5IGEgZHJhZnQgZm9yIHRoYXQgcHVycG9z ZToNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWphbmctZGhjLWhh b3B0LTAyLnR4dA0KDQo+PiBbZmFsbGJhY2sgY2FzZV0gSW4gdGhlIGZhbGxiYWNrIGNhc2UsIHRo ZSBtb2JpbGUgbm9kZSBpcyBub3QgYWJsZSB0bw0KPj4gIGFjcXVpcmUgdGhlIGhvbWUgYWdlbnQg aW5mb3JtYXRpb24gdmlhIERIQ1B2Ni4gIFRoZSBtb2JpbGUgbm9kZSANCj4+IHBlcmZvcm1zIERO UyBxdWVyaWVzIHRvIGRpc2NvdmVyIHRoZSBob21lIGFnZW50IGFkZHJlc3MgYXMgZGVmaW5lZCBp bg0KPj4gIFtCT09ULVNQTElUXS4gIFRvIHBlcmZvcm0gRE5TIGJhc2VkIGhvbWUgYWdlbnQgZGlz Y292ZXJ5LCB0aGUgbW9iaWxlDQo+PiAgbm9kZSBuZWVkcyB0byBrbm93IHRoZSBETlMgc2VydmVy IGFkZHJlc3MuICBIb3cgdGhlIG1vYmlsZSBub2RlIA0KPj4ga25vd3MgdGhlIEROUyBzZXJ2ZXIg YWRkcmVzcyBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50Lg0KPiANCj4gV2hh dCBhcmUgdGhlIGNvbmRpdGlvbnMgaW4gd2hpY2ggdGhlIGZhbGxiYWNrIGNhc2Ugb2NjdXJzPyAg SXMgaXQNCj4gYmVjYXVzZSBESENQIGRvZXMgbm90IHJlc3BvbmQ/ICBPciBqdXN0IHRoYXQgdGhl IERIQ1AgcmVzcG9uZHMgd2l0aCBhbg0KPiBlcnJvciB3aGVuIHF1ZXJpZWQgYWJvdXQgSEE/DQoN CklmIEkgdW5kZXJzdG9vZCB5b3VyIHF1ZXN0aW9uIGNvcnJlY3RseSwNCnRoZSBmYWxsYmFjayBj YXNlIGhlcmUgbWVhbnMgd2hlcmUgdGhlIGludGVncmF0ZWQgc2NlbmFyaW8gZG9lcyBub3QgYXBw bHksDQptb3JlIHNwZWNpZmljYWxseSBBU0EgIT0gTVNBLg0KDQo+IElmIHRoZSBsYXR0ZXIgdGhl biB0aGUgRE5TIGFkZHJlc3MgY291bGQgYmUgc3RpbGwgb2J0YWluZWQgZnJvbSBESENQLg0KPiBP dGhlcndpc2UsIHRoZSBETlMgYWRkcmVzcyBjYW4gYmUgcHJlLWNvbmZpZ3VyZWQgKGluIC9ldGMv cmVzb2x2LmNvbmYpDQo+IG9yIGZyb20gYSBMQ1AgKGxpbmstY29udHJvbCBwcm90b2NvbCkuICBJ IGRvbid0IHVuZGVyc3RhbmQgd2h5IGl0J3MgbGVmdA0KPiBvdXRzaWRlIHRoZSBzY29wZSBvZiB0 aGlzIGRvY3VtZW50Lg0KPiANCj4+ICgyKSBUaGUgbW9iaWxlIG5vZGUgc2VuZHMgYSBESENQdjYg SW5mb3JtYXRpb24gUmVxdWVzdCBtZXNzYWdlIA0KPj4gW1JGQzMzMTVdIHRvIHRoZSBBbGxfREhD UF9SZWxheV9BZ2VudHNfYW5kX1NlcnZlcnMgbXVsdGljYXN0IGFkZHJlc3MuDQo+PiAgSW4gdGhp cyBtZXNzYWdlIHRoZSBtb2JpbGUgbm9kZSAoREhDUCBjbGllbnQpIFNIQUxMIGluY2x1ZGUgdGhl IA0KPj4gT3B0aW9uIENvZGUgZm9yIEhvbWUgTmV0d29yayBJZGVudGlmaWVyIE9wdGlvbiBbSEFP UFRdIGluIHRoZSANCj4+IE9QVElPTl9PUk8sIEhvbWUgTmV0d29yayBJZGVudGlmaWVyIE9wdGlv biB3aXRoIGlkLXR5cGUgc2V0IHRvIDEgYW5kIA0KPj4gdGhlIEhvbWUgTmV0d29yayBJZGVudGlm aWVyIGZpZWxkIHNldCB0byB0aGUgbmV0d29yayByZWFsbSBvZiB0aGUgDQo+PiBob21lIE1TUCBb SEFPUFRdLg0KPiANCj4gQ3VycmVudGx5IGEgbmV0d29yayByZWFsbSBwYXJ0IG9mIE5BSSBkZXNp Z25hdGVzIHNldmVyYWwgc3VibmV0cyAoSEFPUFQgDQo+IHVzZXMgTkFJKS4gIFNvIGlmIGluIGEg bmV0d29yayBkb21haW4gKHJlYWxtKSB0aGVyZSBhcmUgc2V2ZXJhbCBzdWJuZXRzLCANCj4gdGhl cmUgc2hvdWxkIGJlIHNldmVyYWwgaG9tZSBhZ2VudHMgdGhlcmUuICBIb3cgZG9lcyBESENQIGFu ZCBBQUFIIGtub3cgDQo+IHdoaWNoIEhBIHRvIHJldHVybiB0byBNTiB3aGVuIHRoZSBpZGVudGlm aWVyIGlzIG9ubHkgYSBnZW5lcmljIG5ldHdvcmsgDQo+IHJlYWxtPw0KDQpOb3Qgc28gc3VyZSBp ZiBJIHVuZGVyc3Rvb2QgeW91ciBxdWVzdGlvbiBoZXJlOg0KQW55d2F5LCBNU1AvQUFBSCBhc3Np Z25zIGEgSEEgaW4gdGhlIGludGVncmF0ZWQgc2NlbmFyaW8uDQoNCg0KVGhhbmtzLA0KLUp1bmdo b29uDQoNCj4gDQo+IEFsZXgNCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBNaXA2IG1haWxpbmcgbGlzdA0KPiBNaXA2QGlldGYub3Jn DQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pcDY= --===============2004502699== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============2004502699==-- From mip6-bounces@ietf.org Fri Apr 28 13:03:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZWNU-00038q-TI; Fri, 28 Apr 2006 13:03:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZWNT-00038l-Ej for mip6@ietf.org; Fri, 28 Apr 2006 13:03:35 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZWNT-0005pJ-5G for mip6@ietf.org; Fri, 28 Apr 2006 13:03:35 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3SHKDNG026020; Fri, 28 Apr 2006 10:20:13 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k3SHKq9K024077; Fri, 28 Apr 2006 12:20:52 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id EA7C3865980; Fri, 28 Apr 2006 19:03:20 +0200 (CEST) Message-ID: <44524AD8.2020702@motorola.com> Date: Fri, 28 Apr 2006 19:03:20 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Junghoon Jee Subject: Re: [Mip6] Questions ondraft-ietf-mip6-bootstrapping-integrated-dhc-00.txt References: <445242EE.9050008@motorola.com> <002301c66ae4$bd750b50$b28feada@FLY> In-Reply-To: <002301c66ae4$bd750b50$b28feada@FLY> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Junghoon Jee wrote: > Hi Alex, Let me try to reply to your questions. > > ----- Original Message ----- From: "Alexandru Petrescu" > To: Sent: Saturday, > April 29, 2006 1:29 AM Subject: [Mip6] Questions > ondraft-ietf-mip6-bootstrapping-integrated-dhc-00.txt > > >> Dear authors of >> draft-ietf-mip6-bootstrapping-integrated-dhc-00.txt, I have some >> questions and comments on this draft. >> >> Shouldn't the DHCP options defined in this draft be proposed to the >> DHC WG and not to the MIP6 WG? > > There's already a draft for that purpose: > http://www.ietf.org/internet-drafts/draft-jang-dhc-haopt-02.txt > >>> [fallback case] In the fallback case, the mobile node is not able >>> to acquire the home agent information via DHCPv6. The mobile >>> node performs DNS queries to discover the home agent address as >>> defined in [BOOT-SPLIT]. To perform DNS based home agent >>> discovery, the mobile node needs to know the DNS server address. >>> How the mobile node knows the DNS server address is outside the >>> scope of this document. >> What are the conditions in which the fallback case occurs? Is it >> because DHCP does not respond? Or just that the DHCP responds with >> an error when queried about HA? > > If I understood your question correctly, the fallback case here means > where the integrated scenario does not apply, Nowhere in the draft-integrated does it say that the fallback case happens that the integrated scenario does not apply. > more specifically ASA != MSA. How does the MN know that ASA!=MSA? >> If the latter then the DNS address could be still obtained from >> DHCP. Otherwise, the DNS address can be pre-configured (in >> /etc/resolv.conf) or from a LCP (link-control protocol). I don't >> understand why it's left outside the scope of this document. >> >>> (2) The mobile node sends a DHCPv6 Information Request message >>> [RFC3315] to the All_DHCP_Relay_Agents_and_Servers multicast >>> address. In this message the mobile node (DHCP client) SHALL >>> include the Option Code for Home Network Identifier Option >>> [HAOPT] in the OPTION_ORO, Home Network Identifier Option with >>> id-type set to 1 and the Home Network Identifier field set to the >>> network realm of the home MSP [HAOPT]. >> Currently a network realm part of NAI designates several subnets >> (HAOPT uses NAI). So if in a network domain (realm) there are >> several subnets, there should be several home agents there. How >> does DHCP and AAAH know which HA to return to MN when the >> identifier is only a generic network realm? > > Not so sure if I understood your question here: Anyway, MSP/AAAH > assigns a HA in the integrated scenario. Yes, it does. But for draft-integrated MN is querying DHCP using as key the realm of NAI (i.e. example.com). I think this assumption is correct, no? If yes, how does the responder (DHCP, AAA) know that in example.com there are several subnets and that each has a different prefix and a different set of HAs on each link? Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 28 13:14:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZWXw-0007td-Jq; Fri, 28 Apr 2006 13:14:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZWXv-0007tV-N1 for mip6@ietf.org; Fri, 28 Apr 2006 13:14:23 -0400 Received: from av10-1-sn2.hy.skanova.net ([81.228.8.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZWXu-0006Te-Di for mip6@ietf.org; Fri, 28 Apr 2006 13:14:23 -0400 Received: by av10-1-sn2.hy.skanova.net (Postfix, from userid 502) id 7FD5B37FCE; Fri, 28 Apr 2006 19:14:21 +0200 (CEST) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av10-1-sn2.hy.skanova.net (Postfix) with ESMTP id 5855D37E86; Fri, 28 Apr 2006 19:14:21 +0200 (CEST) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id DB47537E44; Fri, 28 Apr 2006 19:14:19 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.61) (envelope-from ) id 1FZWXo-0006G6-JF; Fri, 28 Apr 2006 19:14:19 +0200 Message-ID: <44524D69.6080709@levkowetz.com> Date: Fri, 28 Apr 2006 19:14:17 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.2 (Macintosh/20060308) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: Again on port number for DS-MIPv6 (was: [Mip6] MN's address as seen by HA is not its CoA but NAT's address (when NAT)) References: <1487A357FD2ED544B8AD29E528FF9DF0024F2419@NAEX06.na.qualcomm.com> <44513C22.9090706@motorola.com> <445244F0.4010905@motorola.com> In-Reply-To: <445244F0.4010905@motorola.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 1.7 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: "Zhang, Qiang \[NTK\]" , Ryuji Wakikawa , "Soliman, Hesham" , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Alexandru, on 2006-04-28 18:38 Alexandru Petrescu said the following: ... > Whenever MN opens a UDP "connection" through NAT to GW the state created > there only lasts for some time, for a timelength which is little > predictable. And, since the draft doesn't offer a NAT state maintenance > procedure I assume the port number changes. Is this wrong? Yes, that is wrong. The draft specifies a NAT state keepalive mechanism. If that wasn't the case, things wouldn't work. In that you're quite right. But with the keepalive mechanism, this does work, in the same manner as the tested and verified mechanism of RFC 3519. Henrik _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 28 13:18:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZWc1-0003Er-Tj; Fri, 28 Apr 2006 13:18:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZWc0-0003Em-2H for mip6@ietf.org; Fri, 28 Apr 2006 13:18:36 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZWby-0006Xk-Pq for mip6@ietf.org; Fri, 28 Apr 2006 13:18:36 -0400 Received: from [10.1.201.8] ([10.1.201.8]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Apr 2006 10:18:33 -0700 Message-ID: <44524E69.6000806@azairenet.com> Date: Fri, 28 Apr 2006 10:18:33 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Alexandru Petrescu Subject: DHCP options (was Re: [Mip6] Questions on draft-ietf-mip6-bootstrapping-integrated-dhc-00.txt) References: <445242EE.9050008@motorola.com> In-Reply-To: <445242EE.9050008@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Apr 2006 17:18:33.0240 (UTC) FILETIME=[C6D3D980:01C66AE7] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Alexandru Petrescu wrote: > Shouldn't the DHCP options defined in this draft be proposed to the DHC > WG and not to the MIP6 WG? nope. I checked with Ralph. DHCP options can be specified in any WG as long as they are reviewed by the DHC WG. this is similar to MIP6 WG introducing new IKEv2 config payload attributes instead of going to the IPsec WG, the SIP WG introducing new DHCP options instead of going to the DHC WG or the MIPSHOP WG introducing new mobility options instead of going to the MIP6 WG. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 28 13:19:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZWcf-0003Z4-CE; Fri, 28 Apr 2006 13:19:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZWcd-0003Yy-SA for mip6@ietf.org; Fri, 28 Apr 2006 13:19:15 -0400 Received: from email1.etri.re.kr ([129.254.16.131] helo=email1.etri.info) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZWcd-0006YQ-E3 for mip6@ietf.org; Fri, 28 Apr 2006 13:19:15 -0400 Received: from FLY ([129.254.1.8]) by email1.etri.info with Microsoft SMTPSVC(6.0.3790.1830); Sat, 29 Apr 2006 02:22:02 +0900 Message-ID: <003601c66ae7$df1a24e0$b28feada@FLY> From: "Junghoon Jee" To: "Alexandru Petrescu" References: <445242EE.9050008@motorola.com> <002301c66ae4$bd750b50$b28feada@FLY> <44524AD8.2020702@motorola.com> Subject: Re: [Mip6] Questions ondraft-ietf-mip6-bootstrapping-integrated-dhc-00.txt Date: Sat, 29 Apr 2006 02:19:13 +0900 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-OriginalArrivalTime: 28 Apr 2006 17:22:02.0803 (UTC) FILETIME=[43BCA030:01C66AE8] X-Spam-Score: 0.2 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0167554604==" Errors-To: mip6-bounces@ietf.org --===============0167554604== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 PiBOb3doZXJlIGluIHRoZSBkcmFmdC1pbnRlZ3JhdGVkIGRvZXMgaXQgc2F5IHRoYXQgdGhlIGZh bGxiYWNrIGNhc2UNCj4gaGFwcGVucyB0aGF0IHRoZSBpbnRlZ3JhdGVkIHNjZW5hcmlvIGRvZXMg bm90IGFwcGx5Lg0KDQpJZiBteSB1bmRlcnN0YW5kaW5nIGlzIGNvcnJlY3QgdGhlbiB3ZSBtYXkg ZXhwbGljaXRseSBzYXkgYWJvdXQgdGhpcyBpbiB0aGlzIEktRCwNCmlmIHlvdSByZWFsbHkgd2Fu dC4NCg0KPj4gbW9yZSBzcGVjaWZpY2FsbHkgQVNBICE9IE1TQS4NCj4gDQo+IEhvdyBkb2VzIHRo ZSBNTiBrbm93IHRoYXQgQVNBIT1NU0E/DQoNCk1OIGNhbm5vdCBhbmQgbmVlZHMgbm90IGtub3cg YWJvdXQgdGhlIHdob2xlIGRldGFpbHMgYWJvdXQgdGhlIHZhcnlpbmcgbmV0d29yayBpbmZyYXN0 cnVjdHVyZSBzaXR1YXRpb25zLg0KDQo+Pj4gSWYgdGhlIGxhdHRlciB0aGVuIHRoZSBETlMgYWRk cmVzcyBjb3VsZCBiZSBzdGlsbCBvYnRhaW5lZCBmcm9tIA0KPj4+IERIQ1AuIE90aGVyd2lzZSwg dGhlIEROUyBhZGRyZXNzIGNhbiBiZSBwcmUtY29uZmlndXJlZCAoaW4gDQo+Pj4gL2V0Yy9yZXNv bHYuY29uZikgb3IgZnJvbSBhIExDUCAobGluay1jb250cm9sIHByb3RvY29sKS4gIEkgZG9uJ3Qg DQo+Pj4gdW5kZXJzdGFuZCB3aHkgaXQncyBsZWZ0IG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMg ZG9jdW1lbnQuDQo+Pj4gDQo+Pj4+ICgyKSBUaGUgbW9iaWxlIG5vZGUgc2VuZHMgYSBESENQdjYg SW5mb3JtYXRpb24gUmVxdWVzdCBtZXNzYWdlIA0KPj4+PiBbUkZDMzMxNV0gdG8gdGhlIEFsbF9E SENQX1JlbGF5X0FnZW50c19hbmRfU2VydmVycyBtdWx0aWNhc3QgDQo+Pj4+IGFkZHJlc3MuIElu IHRoaXMgbWVzc2FnZSB0aGUgbW9iaWxlIG5vZGUgKERIQ1AgY2xpZW50KSBTSEFMTCANCj4+Pj4g aW5jbHVkZSB0aGUgT3B0aW9uIENvZGUgZm9yIEhvbWUgTmV0d29yayBJZGVudGlmaWVyIE9wdGlv biANCj4+Pj4gW0hBT1BUXSBpbiB0aGUgT1BUSU9OX09STywgSG9tZSBOZXR3b3JrIElkZW50aWZp ZXIgT3B0aW9uIHdpdGggDQo+Pj4+IGlkLXR5cGUgc2V0IHRvIDEgYW5kIHRoZSBIb21lIE5ldHdv cmsgSWRlbnRpZmllciBmaWVsZCBzZXQgdG8gdGhlDQo+Pj4+ICBuZXR3b3JrIHJlYWxtIG9mIHRo ZSBob21lIE1TUCBbSEFPUFRdLg0KPj4+IEN1cnJlbnRseSBhIG5ldHdvcmsgcmVhbG0gcGFydCBv ZiBOQUkgZGVzaWduYXRlcyBzZXZlcmFsIHN1Ym5ldHMgDQo+Pj4gKEhBT1BUIHVzZXMgTkFJKS4g IFNvIGlmIGluIGEgbmV0d29yayBkb21haW4gKHJlYWxtKSB0aGVyZSBhcmUgDQo+Pj4gc2V2ZXJh bCBzdWJuZXRzLCB0aGVyZSBzaG91bGQgYmUgc2V2ZXJhbCBob21lIGFnZW50cyB0aGVyZS4gIEhv dyANCj4+PiBkb2VzIERIQ1AgYW5kIEFBQUgga25vdyB3aGljaCBIQSB0byByZXR1cm4gdG8gTU4g d2hlbiB0aGUgDQo+Pj4gaWRlbnRpZmllciBpcyBvbmx5IGEgZ2VuZXJpYyBuZXR3b3JrIHJlYWxt Pw0KPj4gDQo+PiBOb3Qgc28gc3VyZSBpZiBJIHVuZGVyc3Rvb2QgeW91ciBxdWVzdGlvbiBoZXJl OiBBbnl3YXksIE1TUC9BQUFIIA0KPj4gYXNzaWducyBhIEhBIGluIHRoZSBpbnRlZ3JhdGVkIHNj ZW5hcmlvLg0KPiANCj4gWWVzLCBpdCBkb2VzLiAgQnV0IGZvciBkcmFmdC1pbnRlZ3JhdGVkIE1O IGlzIHF1ZXJ5aW5nIERIQ1AgdXNpbmcgYXMga2V5IA0KPiB0aGUgcmVhbG0gb2YgTkFJIChpLmUu IGV4YW1wbGUuY29tKS4gIEkgdGhpbmsgdGhpcyBhc3N1bXB0aW9uIGlzIA0KPiBjb3JyZWN0LCBu bz8NCj4gDQo+IElmIHllcywgaG93IGRvZXMgdGhlIHJlc3BvbmRlciAoREhDUCwgQUFBKSBrbm93 IHRoYXQgaW4gZXhhbXBsZS5jb20NCj4gdGhlcmUgYXJlIHNldmVyYWwgc3VibmV0cyBhbmQgdGhh dCBlYWNoIGhhcyBhIGRpZmZlcmVudCBwcmVmaXggYW5kIGENCj4gZGlmZmVyZW50IHNldCBvZiBI QXMgb24gZWFjaCBsaW5rPw0KDQpJbiB0aGUgaW50ZWdyYXRlZCBzY2VuYXJpbyB0aGF0IGlzIGRl c2NyaWJlIGluIHRoaXMgSS1ELCBNU1AvQUFBSCBhc3NpZ25zL3ByZXBhcmVzIGEgSEEgaW4gaGlz IHBhcnQuDQpUaGlzIEhBIG1heSBub3QgYmUgYWN0dWFsbHkgdXNlZCBieSBhIE1OIGluIGNhc2Ug d2hlcmUgQVNQL0FBQXYgY2FuIGFzc2lnbiBhIEhBIGFuZCBNTiB3aXNoIHRvIHVzZSB0aGF0IEhB DQpieSBzZXR0aW5nIHRoZSBpZC10eXBlIGZpZWxkIHRvIHplcm8uDQpOb3Qgc3RpbGwgc3VyZSB3 ZSBhcmUgaW4gdGhlIHNhbWUgdW5kZXJzdGFuaW5nIGFuZCBjb250ZXh0IGhlcmUuDQoNCi1KdW5n aG9vbg0KDQoNCj4gDQo+IEFsZXg= --===============0167554604== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0167554604==-- From mip6-bounces@ietf.org Fri Apr 28 13:22:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZWfK-0005JF-6a; Fri, 28 Apr 2006 13:22:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZWfI-0005J4-Rx for mip6@ietf.org; Fri, 28 Apr 2006 13:22:00 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZWfH-0006bt-Im for mip6@ietf.org; Fri, 28 Apr 2006 13:22:00 -0400 Received: from [10.1.201.8] ([10.1.201.8]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Apr 2006 10:21:58 -0700 Message-ID: <44524F37.9020607@azairenet.com> Date: Fri, 28 Apr 2006 10:21:59 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [Mip6] Questions on draft-ietf-mip6-bootstrapping-integrated-dhc-00.txt References: <445242EE.9050008@motorola.com> In-Reply-To: <445242EE.9050008@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Apr 2006 17:21:58.0550 (UTC) FILETIME=[4133AB60:01C66AE8] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Alexandru Petrescu wrote: > Dear authors of draft-ietf-mip6-bootstrapping-integrated-dhc-00.txt, I > have some questions and comments on this draft. > > Shouldn't the DHCP options defined in this draft be proposed to the DHC > WG and not to the MIP6 WG? > >> [fallback case] In the fallback case, the mobile node is not able to >> acquire the home agent information via DHCPv6. The mobile node >> performs DNS queries to discover the home agent address as defined in >> [BOOT-SPLIT]. To perform DNS based home agent discovery, the mobile >> node needs to know the DNS server address. How the mobile node knows >> the DNS server address is outside the scope of this document. > > What are the conditions in which the fallback case occurs? Is it > because DHCP does not respond? Or just that the DHCP responds with an > error when queried about HA? the DHCP server in the visited link might just not have the information about the HA for a particular mobile node. > If the latter then the DNS address could be still obtained from DHCP. > Otherwise, the DNS address can be pre-configured (in /etc/resolv.conf) > or from a LCP (link-control protocol). I don't understand why it's left > outside the scope of this document. I think its left out of scope because DNS information is obtained through many mechanisms. for e.g. DNS information could be delivered as part of PPP setup, GTP setup and running IKEv2 with a PDG. getting it through DHCP will also work ofcourse. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 28 13:22:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZWfp-0005Ng-UZ; Fri, 28 Apr 2006 13:22:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZWfp-0005Na-1a for mip6@ietf.org; Fri, 28 Apr 2006 13:22:33 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZWfo-0006cT-Mv for mip6@ietf.org; Fri, 28 Apr 2006 13:22:33 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3SHMU9q000826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 28 Apr 2006 10:22:31 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3SHMSts018933; Fri, 28 Apr 2006 10:22:29 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Apr 2006 10:22:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Again on port number for DS-MIPv6 (was: [Mip6] MN's address as seen by HA is not its CoA but NAT's address (when NAT)) Date: Fri, 28 Apr 2006 10:22:25 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF002555CC6@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Again on port number for DS-MIPv6 (was: [Mip6] MN's address as seen by HA is not its CoA but NAT's address (when NAT)) Thread-Index: AcZqRWpoyREn9nhhTniD8dfBKYMDcgAoecQQ From: "Soliman, Hesham" To: "Alexandru Petrescu" X-OriginalArrivalTime: 28 Apr 2006 17:22:29.0656 (UTC) FILETIME=[53BE1180:01C66AE8] X-Spam-Score: 1.7 (+) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: "Zhang, Qiang \[NTK\]" , Henrik Levkowetz , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > > The port numbers can be stored in the MIP6 implementation=20 > after a BU > > is received and reused for normal traffic. You can store=20 > them in the > > relevant BCE. >=20 > I thought along the same lines. >=20 > Except that (1) the NAT src port number is visible in clear=20 > in UDP and > thus spoofable. I guess it should not only present but=20 > protected too. =3D> I disagree. This is not different from any other UDP connection.=20 I don't see why we should treat it differently. Of course the IPv6 packet can be protected with IPsec.=20 >=20 > And (2) the port number may change while BU/BAck is not=20 > happening, and > depending on its periodicity it may be bad for apps. I.e. if the > BU/BAck happens every 5 minutes then the worse an=20 > application can expect > is a break for 5 minutes. =3D> My response to this comment and your response to Ryuji is that you should read the NAT traversal and keepalive section in the draft.=20 The default value for keepalives is 110s I think. This is used when the NAT binding is not refreshed with normal traffic. >=20 > Last meeting there was discussion on the mike about what to use > for heartbeat keepalive. Echo request/Reply and figures=20 > like 100seconds > were mentioned. That is still a lot for a streaming app,=20 > not to mention > VoIP. =3D> If you have an app running then you don't need to send keepalives = at all. Please read this part in the draft. >=20 > Ping could be sent from MN to GW. But at the same time=20 > there are IPv6 > RAs sent on the UDP "tunnel" interface. So Echo Reply might not be > needed actually, because the RAs represent the keepalive=20 > from GW to MN. =3D> huh? I didn't understand this at all, then I saw your explanation = to Ryuji: "For MN to be able to simply auto-configure a IPv6 CoA when behind NAT. How do you propose MN to auto-configure an IPv6 CoA when behind NAT?" =3D> You don't do stateless autoconfig. I've assumed that the GW you = refer to is the HA.=20 But now I'm confused, what's this GW you refer to? Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 28 13:23:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZWgm-0005v4-GS; Fri, 28 Apr 2006 13:23:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZWgl-0005uz-U4 for mip6@ietf.org; Fri, 28 Apr 2006 13:23:31 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZWgk-0006eP-Le for mip6@ietf.org; Fri, 28 Apr 2006 13:23:31 -0400 Received: from [10.1.201.8] ([10.1.201.8]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Apr 2006 10:23:29 -0700 Message-ID: <44524F92.9040005@azairenet.com> Date: Fri, 28 Apr 2006 10:23:30 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: Changing home links (was: [Mip6] How to store DNS records about HAs,(draft-ietf-mip6-bootstrapping-split-02.txt)?) References: <8A16DAD84432534FBFC19FD92B50512F04AE50A1@ames.starentnetworks.com> <4452454B.2020106@motorola.com> In-Reply-To: <4452454B.2020106@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Apr 2006 17:23:29.0830 (UTC) FILETIME=[779BE460:01C66AE8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: mip6@ietf.org, COMBES Jean-Michel RD-MAPS-ISS X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Alexandru Petrescu wrote: > Chowdhury, Kuntal wrote: >> We are talking about bootstrapping. At the time of bootstrapping, the MN >> does not have a mobility binding. Unless the MN has a static HoA, it >> will get a dynamic HoA, Home link etc. > > What's a "static HoA"? Is it one that is pre-configured on MN? Would > operators accept a pre-configured HoA on MN? there are deployments where the "static HoA" is stored in the AAA and delivered to the MN during access authentication. I think Kuntal is referring to those. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 28 13:42:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZWzV-00065O-Pp; Fri, 28 Apr 2006 13:42:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZWzU-00065J-69 for mip6@ietf.org; Fri, 28 Apr 2006 13:42:52 -0400 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZWzT-0007WX-TF for mip6@ietf.org; Fri, 28 Apr 2006 13:42:52 -0400 Received: from az33exr03.mot.com ([10.64.251.233]) by motgate7.mot.com (8.12.11/Motgate7) with ESMTP id k3SIEdTG007282; Fri, 28 Apr 2006 11:14:39 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id k3SHxZRt024833; Fri, 28 Apr 2006 12:59:36 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id F39D8865980; Fri, 28 Apr 2006 19:42:45 +0200 (CEST) Message-ID: <44525415.3050103@motorola.com> Date: Fri, 28 Apr 2006 19:42:45 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Henrik Levkowetz Subject: Re: Again on port number for DS-MIPv6 (was: [Mip6] MN's address as seen by HA is not its CoA but NAT's address (when NAT)) References: <1487A357FD2ED544B8AD29E528FF9DF0024F2419@NAEX06.na.qualcomm.com> <44513C22.9090706@motorola.com> <445244F0.4010905@motorola.com> <44524D69.6080709@levkowetz.com> In-Reply-To: <44524D69.6080709@levkowetz.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 1.7 (+) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: "Zhang, Qiang \[NTK\]" , Ryuji Wakikawa , "Soliman, Hesham" , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Henrik Levkowetz wrote: > Hi Alexandru, > > on 2006-04-28 18:38 Alexandru Petrescu said the following: ... > >> Whenever MN opens a UDP "connection" through NAT to GW the state >> created there only lasts for some time, for a timelength which is >> little predictable. And, since the draft doesn't offer a NAT state >> maintenance procedure I assume the port number changes. Is this >> wrong? > > Yes, that is wrong. Partially. > The draft specifies a NAT state keepalive mechanism. The NAT state keepalive mechanism specified by draft is basically the following: > However, if the mobile node is not active, it will need to > periodically send a message to the home agent in order to refresh the > NAT binding. This can be done using the binding update message. For one, when this BU/BAck happens and the NAT UDP src port number has changed, the BAck will indeed go back. But if after this BU/BAck happening, GW/HA wants to send a BRR (to refresh the binding and the NAT state)? How does the code sending BRR know which was the port number used by the code who sent BAck? BRR is triggered by a timer while BAck by reception of a BU. It's not same code flow. Second, if we need MN to simply auto-configure an IPv6 CoA while behind NAT then there should be RAs over the UDP "tunnel". If there are such RAs, then the RA itself could contribute to maintain NAT state, so it will be redundant with the BAck message. Also here, if we want MN to quickly handover between behind NAT and something else then these RAs should happen quickly (every 1s or so). If we wait for the BU/BAck to happen in order for the NAT to open (every 10s at best) then handover is slowed. Third, BU/BAck is mainly meant to update HoA-CoA bindings. Or, neither changes while MN is behind NAT, even if MN changes its v4 address due to v4 mobility. Do you think this is enough to motivate a different mechanism for NAT state maintenance than just BU/BAck? Do you disagree with any of the above items? (store NAT src port number on GW, BAck not needed for keepalive, RA should happen on "tunnel", BU/BAck is not the right tool for maintenance)? > But with the keepalive mechanism, this does work, The keepalive mechanism mentioned in the draft (BU/BAck) has not been tested here. > in the same manner as the tested and verified mechanism of RFC 3519. That document talks about MIP4. It does make sense to take advantage of RegReq/RegRep to maintain NAT state, because the IPv4 address does change every now and then. But with DS-MIPv6 the IPv6 CoA doesn't change at all while behind NAT. Would you agree? Also I'm wondering whether in that document the NAT src port number is stored in the registration table so that other code than RegReq/RegRep can take advantage of it? Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 28 14:20:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZXZk-0000hF-5o; Fri, 28 Apr 2006 14:20:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZXZj-0000hA-9A for mip6@ietf.org; Fri, 28 Apr 2006 14:20:19 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZXZi-0002NY-24 for mip6@ietf.org; Fri, 28 Apr 2006 14:20:19 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3SIaQUn012813; Fri, 28 Apr 2006 11:36:26 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id k3SIYKoC023876; Fri, 28 Apr 2006 13:34:21 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 373AA865980; Fri, 28 Apr 2006 20:19:34 +0200 (CEST) Message-ID: <44525CB5.9030002@motorola.com> Date: Fri, 28 Apr 2006 20:19:33 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: DHCP options (was Re: [Mip6] Questions on draft-ietf-mip6-bootstrapping-integrated-dhc-00.txt) References: <445242EE.9050008@motorola.com> <44524E69.6000806@azairenet.com> In-Reply-To: <44524E69.6000806@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Vijay Devarapalli wrote: > Alexandru Petrescu wrote: > >> Shouldn't the DHCP options defined in this draft be proposed to the >> DHC WG and not to the MIP6 WG? > > nope. I checked with Ralph. DHCP options can be specified in any WG > as long as they are reviewed by the DHC WG. So they should be reviewed by the DHC WG right? It's still uncommon to see a document titled "MIPv6 bootsrapping" in the MIP6 WG only with DHCP messages modified, no MIP6 messaging, no MIP6 data structure, no keyword "binding" present, no CoA and only one occurence of "home address" (the one to be boot-strapped). Maybe the title should be "DHCPv6-based MIPv6 bootstrapping for integrated scenario"? Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 28 14:23:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZXco-0003f9-8d; Fri, 28 Apr 2006 14:23:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZXcn-0003f4-Kz for mip6@ietf.org; Fri, 28 Apr 2006 14:23:29 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZXcm-0002Wf-CT for mip6@ietf.org; Fri, 28 Apr 2006 14:23:29 -0400 Received: from [10.1.201.8] ([10.1.201.8]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Apr 2006 11:23:26 -0700 Message-ID: <44525D9D.4060208@azairenet.com> Date: Fri, 28 Apr 2006 11:23:25 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: DHCP options (was Re: [Mip6] Questions on draft-ietf-mip6-bootstrapping-integrated-dhc-00.txt) References: <445242EE.9050008@motorola.com> <44524E69.6000806@azairenet.com> <44525CB5.9030002@motorola.com> In-Reply-To: <44525CB5.9030002@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Apr 2006 18:23:26.0815 (UTC) FILETIME=[D7943EF0:01C66AF0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Alexandru Petrescu wrote: > Vijay Devarapalli wrote: >> Alexandru Petrescu wrote: >> >>> Shouldn't the DHCP options defined in this draft be proposed to the >>> DHC WG and not to the MIP6 WG? >> >> nope. I checked with Ralph. DHCP options can be specified in any WG >> as long as they are reviewed by the DHC WG. > > So they should be reviewed by the DHC WG right? yes. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 28 14:24:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZXdn-0003qM-Od; Fri, 28 Apr 2006 14:24:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZXdm-0003qH-EI for mip6@ietf.org; Fri, 28 Apr 2006 14:24:30 -0400 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZXdi-0002cW-4o for mip6@ietf.org; Fri, 28 Apr 2006 14:24:30 -0400 Received: from az33exr03.mot.com ([10.64.251.233]) by motgate7.mot.com (8.12.11/Motgate7) with ESMTP id k3SIu950018745; Fri, 28 Apr 2006 11:56:11 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id k3SIf6q0018664; Fri, 28 Apr 2006 13:41:07 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 71619865980; Fri, 28 Apr 2006 20:24:16 +0200 (CEST) Message-ID: <44525DD0.3070303@motorola.com> Date: Fri, 28 Apr 2006 20:24:16 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Junghoon Jee Subject: Re: [Mip6] Questions ondraft-ietf-mip6-bootstrapping-integrated-dhc-00.txt References: <445242EE.9050008@motorola.com> <002301c66ae4$bd750b50$b28feada@FLY> <44524AD8.2020702@motorola.com> <003601c66ae7$df1a24e0$b28feada@FLY> In-Reply-To: <003601c66ae7$df1a24e0$b28feada@FLY> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Junghoon Jee wrote: >> Nowhere in the draft-integrated does it say that the fallback case >> happens that the integrated scenario does not apply. > > If my understanding is correct then we may explicitly say about this > in this I-D, if you really want. > >>> more specifically ASA != MSA. >> How does the MN know that ASA!=MSA? > > MN cannot and needs not know about the whole details about the > varying network infrastructure situations. Right, MN doesn't need to know the details about the network infrastructure. >>>> If the latter then the DNS address could be still obtained from >>>> DHCP. Otherwise, the DNS address can be pre-configured (in >>>> /etc/resolv.conf) or from a LCP (link-control protocol). I >>>> don't understand why it's left outside the scope of this >>>> document. >>>> >>>>> (2) The mobile node sends a DHCPv6 Information Request >>>>> message [RFC3315] to the All_DHCP_Relay_Agents_and_Servers >>>>> multicast address. In this message the mobile node (DHCP >>>>> client) SHALL include the Option Code for Home Network >>>>> Identifier Option [HAOPT] in the OPTION_ORO, Home Network >>>>> Identifier Option with id-type set to 1 and the Home Network >>>>> Identifier field set to the network realm of the home MSP >>>>> [HAOPT]. >>>> Currently a network realm part of NAI designates several >>>> subnets (HAOPT uses NAI). So if in a network domain (realm) >>>> there are several subnets, there should be several home agents >>>> there. How does DHCP and AAAH know which HA to return to MN >>>> when the identifier is only a generic network realm? >>> Not so sure if I understood your question here: Anyway, MSP/AAAH >>> assigns a HA in the integrated scenario. >> Yes, it does. But for draft-integrated MN is querying DHCP using >> as key the realm of NAI (i.e. example.com). I think this >> assumption is correct, no? >> >> If yes, how does the responder (DHCP, AAA) know that in example.com >> there are several subnets and that each has a different prefix and >> a different set of HAs on each link? > > In the integrated scenario that is describe in this I-D, MSP/AAAH > assigns/prepares a HA in his part. This HA may not be actually used > by a MN in case where ASP/AAAv can assign a HA and MN wish to use > that HA by setting the id-type field to zero. Not still sure we are > in the same understaning and context here. Ok, let's put it this way: what is the key (or the id) that the MN uses to query the DHCP or any other entity in the network in order to obtain its Home Agent Address and Home Address. What is the pre-configured information on MN in the integrated scenario? I thought that is the NAI converted into the realm name (example.com). Is it so? Or maybe MN isn't pre-configured with anything in order for bootstrapping to work in integrated scenario? Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 28 14:27:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZXgC-0005pD-4i; Fri, 28 Apr 2006 14:27:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZXgA-0005p8-MV for mip6@ietf.org; Fri, 28 Apr 2006 14:26:58 -0400 Received: from email1.etri.re.kr ([129.254.16.131] helo=email1.etri.info) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZXg9-0002qh-9X for mip6@ietf.org; Fri, 28 Apr 2006 14:26:58 -0400 Received: from FLY ([129.254.1.8]) by email1.etri.info with Microsoft SMTPSVC(6.0.3790.1830); Sat, 29 Apr 2006 03:29:44 +0900 Message-ID: <007001c66af1$53eab0b0$b28feada@FLY> From: "Junghoon Jee" To: "Alexandru Petrescu" References: <445242EE.9050008@motorola.com> <002301c66ae4$bd750b50$b28feada@FLY> <44524AD8.2020702@motorola.com> <003601c66ae7$df1a24e0$b28feada@FLY> <44525DD0.3070303@motorola.com> Subject: Re: [Mip6] Questions ondraft-ietf-mip6-bootstrapping-integrated-dhc-00.txt Date: Sat, 29 Apr 2006 03:26:54 +0900 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-OriginalArrivalTime: 28 Apr 2006 18:29:44.0323 (UTC) FILETIME=[B8976530:01C66AF1] X-Spam-Score: 0.2 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2050574066==" Errors-To: mip6-bounces@ietf.org --===============2050574066== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 PiBPaywgbGV0J3MgcHV0IGl0IHRoaXMgd2F5OiB3aGF0IGlzIHRoZSBrZXkgKG9yIHRoZSBpZCkg dGhhdCB0aGUgTU4gdXNlcw0KPiB0byBxdWVyeSB0aGUgREhDUCBvciBhbnkgb3RoZXIgZW50aXR5 IGluIHRoZSBuZXR3b3JrIGluIG9yZGVyIHRvIG9idGFpbg0KPiBpdHMgSG9tZSBBZ2VudCBBZGRy ZXNzIGFuZCBIb21lIEFkZHJlc3MuICBXaGF0IGlzIHRoZSBwcmUtY29uZmlndXJlZA0KPiBpbmZv cm1hdGlvbiBvbiBNTiBpbiB0aGUgaW50ZWdyYXRlZCBzY2VuYXJpbz8gIEkgdGhvdWdodCB0aGF0 IGlzIHRoZSBOQUkNCj4gY29udmVydGVkIGludG8gdGhlIHJlYWxtIG5hbWUgKGV4YW1wbGUuY29t KS4gIElzIGl0IHNvPw0KDQpZZXMuDQoNCi1KdW5naG9vbg0K --===============2050574066== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============2050574066==-- From mip6-bounces@ietf.org Fri Apr 28 14:27:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZXgp-0005tX-Nc; Fri, 28 Apr 2006 14:27:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZXgo-0005tP-MT for mip6@ietf.org; Fri, 28 Apr 2006 14:27:38 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZXgn-0002zE-FM for mip6@ietf.org; Fri, 28 Apr 2006 14:27:38 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3SIi4iH014441; Fri, 28 Apr 2006 11:44:04 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id k3SIfGrQ021504; Fri, 28 Apr 2006 13:41:16 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 84716865980; Fri, 28 Apr 2006 20:27:11 +0200 (CEST) Message-ID: <44525E7F.5050509@motorola.com> Date: Fri, 28 Apr 2006 20:27:11 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip6] Questions on draft-ietf-mip6-bootstrapping-integrated-dhc-00.txt References: <445242EE.9050008@motorola.com> <44524F37.9020607@azairenet.com> In-Reply-To: <44524F37.9020607@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Vijay Devarapalli wrote: >> What are the conditions in which the fallback case occurs? Is it >> because DHCP does not respond? Or just that the DHCP responds with >> an error when queried about HA? > > the DHCP server in the visited link might just not have the > information about the HA for a particular mobile node. Right. >> If the latter then the DNS address could be still obtained from >> DHCP. Otherwise, the DNS address can be pre-configured (in >> /etc/resolv.conf) or from a LCP (link-control protocol). I don't >> understand why it's left outside the scope of this document. > > I think its left out of scope because DNS information is obtained > through many mechanisms. for e.g. DNS information could be delivered > as part of PPP setup That is LCP. > GTP setup and running IKEv2 with a PDG. getting it through DHCP will > also work ofcourse. Just list them. It's not out of scope. Just list them. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 28 14:44:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZXwy-0005wr-Mn; Fri, 28 Apr 2006 14:44:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZXwx-0005wm-Gg for mip6@ietf.org; Fri, 28 Apr 2006 14:44:19 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZXwv-0003nw-5d for mip6@ietf.org; Fri, 28 Apr 2006 14:44:19 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3SJ18Bx018197; Fri, 28 Apr 2006 12:01:08 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k3SJ1kd4008594; Fri, 28 Apr 2006 14:01:47 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 8A9D1865980; Fri, 28 Apr 2006 20:44:15 +0200 (CEST) Message-ID: <4452627F.1000504@motorola.com> Date: Fri, 28 Apr 2006 20:44:15 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: Again on port number for DS-MIPv6 (was: [Mip6] MN's address as seen by HA is not its CoA but NAT's address (when NAT)) References: <1487A357FD2ED544B8AD29E528FF9DF002555CC6@NAEX06.na.qualcomm.com> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF002555CC6@NAEX06.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 1.7 (+) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: "Zhang, Qiang \[NTK\]" , Henrik Levkowetz , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Soliman, Hesham wrote: > >>> The port numbers can be stored in the MIP6 implementation >> after a BU >>> is received and reused for normal traffic. You can store >> them in the >>> relevant BCE. >> >> I thought along the same lines. >> >> Except that (1) the NAT src port number is visible in clear in UDP >> and thus spoofable. I guess it should not only present but >> protected too. > > => I disagree. This is not different from any other UDP connection. I > don't see why we should treat it differently. Of course the IPv6 > packet can be protected with IPsec. (1) in case HA is different than GW, and attacker spoofs that port number, then the link between HA and GW can be DoS'ed. (2) in case HA and GW are the same, and depending of the NAT keepalive mechanism, it is easy for attacker to fake a source port number as coming from NAT to GW and make it think the NAT state is up. >> And (2) the port number may change while BU/BAck is not happening, >> and depending on its periodicity it may be bad for apps. I.e. if >> the BU/BAck happens every 5 minutes then the worse an application >> can expect is a break for 5 minutes. > > => My response to this comment and your response to Ryuji is that you > should read the NAT traversal and keepalive section in the draft. > The default value for keepalives is 110s I think. This is used when > the NAT binding is not refreshed with normal traffic. I've read it. If the BU/BAck happens every 110s and the NAT changed src port right at the beginnning of this 110s period, then the IPv6 app on GW streaming to MN will suffer a 110s delay until next BU/BAck. Would you agree? Know that UDP traffic through NAT originating from MN - even every millisecond, does not guarantee NAT keeps that src port stable. Traffic from GW through NAT doesn't either. >> Last meeting there was discussion on the mike about what to use for >> heartbeat keepalive. Echo request/Reply and figures like >> 100seconds were mentioned. That is still a lot for a streaming >> app, not to mention VoIP. > > => If you have an app running then you don't need to send keepalives > at all. That's plain wrong. Again, even if there is traffic, the NAT src port may change with a periodicity that is not detectable. So, again, if BU/BAck happens every 110s and app from GW streams to MN through NAT then it is very probable that the app will suffer 110s interruptions. > Please read this part in the draft. I did. Please allow me to return the recommendation: please play more with deployed NATs before writing text about them. >> Ping could be sent from MN to GW. But at the same time there are >> IPv6 RAs sent on the UDP "tunnel" interface. So Echo Reply might >> not be needed actually, because the RAs represent the keepalive >> from GW to MN. > > => huh? I didn't understand this at all, then I saw your explanation > to Ryuji: > > "For MN to be able to simply auto-configure a IPv6 CoA when behind > NAT. How do you propose MN to auto-configure an IPv6 CoA when behind > NAT?" > > => You don't do stateless autoconfig. Why not? Stateless auto-config is a quick and widely implemented way of auto-configuring an address. How else would MN auto-configure an IPv6 address when MN behind NAT? > I've assumed that the GW you refer to is the HA. But now I'm > confused, what's this GW you refer to? Simply put because it is good to have the GW supporting NAT traversal and IPv6/IPv4 conversion separated from the HA doing MIP6. Even if HA were co-located with the GW, one surely doesn't want the NAT UDP "tunnel" to be a home link for all MNs managed by that HA. That HA may have some Ethernet links, and it could serve normal MNs on that links too. I hope we both assume UDP "tunnel" is a virtual tunnel interface, do we? Why would one co-locate the NAT/GW/IPv4-IPv6 conversions with the MIP6 HA? Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 28 14:45:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZXy1-0006W5-AB; Fri, 28 Apr 2006 14:45:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZXy0-0006W0-Cr for mip6@ietf.org; Fri, 28 Apr 2006 14:45:24 -0400 Received: from [129.188.136.9] (helo=ftpbox.mot.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZXxz-0003pE-6F for mip6@ietf.org; Fri, 28 Apr 2006 14:45:24 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by ftpbox.mot.com (8.12.11/Motgate7) with ESMTP id k3SIp5Vo019587; Fri, 28 Apr 2006 13:51:06 -0500 (CDT) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id k3SIvBnL012642; Fri, 28 Apr 2006 13:57:12 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 0C8DA865980; Fri, 28 Apr 2006 20:45:20 +0200 (CEST) Message-ID: <445262BF.5050206@motorola.com> Date: Fri, 28 Apr 2006 20:45:19 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Soliman, Hesham" References: <1487A357FD2ED544B8AD29E528FF9DF002555CC6@NAEX06.na.qualcomm.com> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF002555CC6@NAEX06.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: "Zhang, Qiang \[NTK\]" , Henrik Levkowetz , mip6@ietf.org Subject: [Mip6] Re: UDP "connection"? (was: Again on port number for DS-MIPv6) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Soliman, Hesham wrote: > >>> The port numbers can be stored in the MIP6 implementation >> after a BU >>> is received and reused for normal traffic. You can store >> them in the >>> relevant BCE. >> >> I thought along the same lines. >> >> Except that (1) the NAT src port number is visible in clear in UDP >> and thus spoofable. I guess it should not only present but >> protected too. > > => I disagree. This is not different from any other UDP connection. Hesham, wasn't a UDP socket "connectionless"? What's this UDP connection term? Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 28 14:45:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZXyF-0006Zz-LZ; Fri, 28 Apr 2006 14:45:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZXyD-0006Zu-Ry for mip6@ietf.org; Fri, 28 Apr 2006 14:45:37 -0400 Received: from av10-1-sn2.hy.skanova.net ([81.228.8.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZXyD-0003pV-D3 for mip6@ietf.org; Fri, 28 Apr 2006 14:45:37 -0400 Received: by av10-1-sn2.hy.skanova.net (Postfix, from userid 502) id D36D23806E; Fri, 28 Apr 2006 20:45:36 +0200 (CEST) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av10-1-sn2.hy.skanova.net (Postfix) with ESMTP id A2E8A38004; Fri, 28 Apr 2006 20:45:36 +0200 (CEST) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id 7CC8537E42; Fri, 28 Apr 2006 20:45:35 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.61) (envelope-from ) id 1FZXy4-0007Fr-CM; Fri, 28 Apr 2006 20:45:34 +0200 Message-ID: <445262C7.6050603@levkowetz.com> Date: Fri, 28 Apr 2006 20:45:27 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.2 (Macintosh/20060308) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: Again on port number for DS-MIPv6 (was: [Mip6] MN's address as seen by HA is not its CoA but NAT's address (when NAT)) References: <1487A357FD2ED544B8AD29E528FF9DF0024F2419@NAEX06.na.qualcomm.com> <44513C22.9090706@motorola.com> <445244F0.4010905@motorola.com> <44524D69.6080709@levkowetz.com> <44525415.3050103@motorola.com> In-Reply-To: <44525415.3050103@motorola.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 1.7 (+) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: "Zhang, Qiang \[NTK\]" , Ryuji Wakikawa , "Soliman, Hesham" , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Alexandru, on 2006-04-28 19:42 Alexandru Petrescu said the following: > Henrik Levkowetz wrote: >> Hi Alexandru, >> >> on 2006-04-28 18:38 Alexandru Petrescu said the following: ... >> >>> Whenever MN opens a UDP "connection" through NAT to GW the state >>> created there only lasts for some time, for a timelength which is >>> little predictable. And, since the draft doesn't offer a NAT state >>> maintenance procedure I assume the port number changes. Is this >>> wrong? >> >> Yes, that is wrong. > > Partially. Completely. >> The draft specifies a NAT state keepalive mechanism. > > The NAT state keepalive mechanism specified by draft is basically the > following: > >> However, if the mobile node is not active, it will need to >> periodically send a message to the home agent in order to refresh the >> NAT binding. This can be done using the binding update message. > > For one, when this BU/BAck happens and the NAT UDP src port number has > changed, The whole point of the keepalive is to make sure that the port number doesn't change, and *it will not change* if you use the keepalive appropriately. > the BAck will indeed go back. But if after this BU/BAck > happening, GW/HA wants to send a BRR (to refresh the binding and the NAT > state)? How does the code sending BRR know which was the port number > used by the code who sent BAck? BRR is triggered by a timer while BAck > by reception of a BU. It's not same code flow. Nonsense. All UDP applications basically work the same way: send the response back to the originators source port. I've implemented this for MIPv4 NAT traversal. Can you say the same? Unless you've actually coded this I'd suggest that you're whistling in the dark here. > Second, if we need MN to simply auto-configure an IPv6 CoA while behind > NAT then there should be RAs over the UDP "tunnel". This has absolutely nothing to do with keepalives or NATs. The only guess at a relevant answer I have is that it seems like you haven't read the draft at all. Please do so. > Third, BU/BAck is mainly meant to update HoA-CoA bindings. Or, neither > changes while MN is behind NAT, even if MN changes its v4 address due to > v4 mobility. Please read the draft. If you can say that there's no BU needed if the IPv4 CoA changes, I can't see how you can have read the draft. > Do you think this is enough to motivate a different mechanism for NAT > state maintenance than just BU/BAck? Do you disagree with any of the > above items? (store NAT src port number on GW, BAck not needed for > keepalive, RA should happen on "tunnel", BU/BAck is not the right tool > for maintenance)? I think you need to read the draft. >> But with the keepalive mechanism, this does work, > > The keepalive mechanism mentioned in the draft (BU/BAck) has not been > tested here. ?? I'm sorry that you haven't tested it. Maybe you should. >> in the same manner as the tested and verified mechanism of RFC 3519. > > That document talks about MIP4. It does make sense to take advantage of > RegReq/RegRep to maintain NAT state, because the IPv4 address does > change every now and then. But with DS-MIPv6 the IPv6 CoA doesn't > change at all while behind NAT. Would you agree? I think you've mixed this up wonderfully, and would prefer that you read the draft before we discuss this any further. > Also I'm wondering whether in that document the NAT src port number is > stored in the registration table so that other code than RegReq/RegRep > can take advantage of it? Well, maybe the best way to find out is to read the document? Henrik _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 28 14:48:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZY0S-0007xT-8r; Fri, 28 Apr 2006 14:47:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZY0Q-0007sk-T4 for mip6@ietf.org; Fri, 28 Apr 2006 14:47:54 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZY0O-0003s0-KJ for mip6@ietf.org; Fri, 28 Apr 2006 14:47:54 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3SJ4fRq018986; Fri, 28 Apr 2006 12:04:41 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k3SJ4qlr008119; Fri, 28 Apr 2006 14:04:52 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 900C2865980; Fri, 28 Apr 2006 20:47:48 +0200 (CEST) Message-ID: <44526354.9060305@motorola.com> Date: Fri, 28 Apr 2006 20:47:48 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Vijay Devarapalli References: <8A16DAD84432534FBFC19FD92B50512F04AE50A1@ames.starentnetworks.com> <4452454B.2020106@motorola.com> <44524F92.9040005@azairenet.com> In-Reply-To: <44524F92.9040005@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: mip6@ietf.org, COMBES Jean-Michel RD-MAPS-ISS Subject: [Mip6] Re: what key does integrated scenario to bootstrap MIP6 configuration? (was: Changing home links) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Vijay Devarapalli wrote: > Alexandru Petrescu wrote: >> Chowdhury, Kuntal wrote: >>> We are talking about bootstrapping. At the time of bootstrapping, >>> the MN does not have a mobility binding. Unless the MN has a >>> static HoA, it will get a dynamic HoA, Home link etc. >> >> What's a "static HoA"? Is it one that is pre-configured on MN? >> Would operators accept a pre-configured HoA on MN? > > there are deployments where the "static HoA" is stored in the AAA and > delivered to the MN during access authentication. I'm afraid it's not a static IPv6 HoA, but IPv4. Please correct me if I'm wrong. Even if it were in AAA, this brings back the question again: what does the integrated scenario use as a key to find out its HoA, HA address, etc? The NAI? Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 28 14:49:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZY2I-0000Bm-VC; Fri, 28 Apr 2006 14:49:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZY2H-0000Bh-ET for mip6@ietf.org; Fri, 28 Apr 2006 14:49:49 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZY2H-0003ta-6K for mip6@ietf.org; Fri, 28 Apr 2006 14:49:49 -0400 Received: from [10.1.201.8] ([10.1.201.8]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Apr 2006 11:49:48 -0700 Message-ID: <445263C8.90108@azairenet.com> Date: Fri, 28 Apr 2006 11:49:44 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Alexandru Petrescu References: <8A16DAD84432534FBFC19FD92B50512F04AE50A1@ames.starentnetworks.com> <4452454B.2020106@motorola.com> <44524F92.9040005@azairenet.com> <44526354.9060305@motorola.com> In-Reply-To: <44526354.9060305@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Apr 2006 18:49:48.0248 (UTC) FILETIME=[862FC580:01C66AF4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: mip6@ietf.org, COMBES Jean-Michel RD-MAPS-ISS Subject: [Mip6] Re: what key does integrated scenario to bootstrap MIP6 configuration? X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Alexandru Petrescu wrote: > Vijay Devarapalli wrote: >> Alexandru Petrescu wrote: >>> Chowdhury, Kuntal wrote: >>>> We are talking about bootstrapping. At the time of bootstrapping, >>>> the MN does not have a mobility binding. Unless the MN has a static >>>> HoA, it will get a dynamic HoA, Home link etc. >>> >>> What's a "static HoA"? Is it one that is pre-configured on MN? Would >>> operators accept a pre-configured HoA on MN? >> >> there are deployments where the "static HoA" is stored in the AAA and >> delivered to the MN during access authentication. > > I'm afraid it's not a static IPv6 HoA, but IPv4. Please correct me if > I'm wrong. IPv6 HoA too. > Even if it were in AAA, this brings back the question again: what does > the integrated scenario use as a key to find out its HoA, HA address, > etc? The NAI? the "identity" the mobile node presents during access authentication. NAI would ofcourse work. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 28 14:53:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZY6B-0001lm-1W; Fri, 28 Apr 2006 14:53:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZY6A-0001lh-EJ for mip6@ietf.org; Fri, 28 Apr 2006 14:53:50 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZY6A-0003wl-7W for mip6@ietf.org; Fri, 28 Apr 2006 14:53:50 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3SJAdih020329; Fri, 28 Apr 2006 12:10:39 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id k3SJ7p6Y001497; Fri, 28 Apr 2006 14:07:51 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id BA5DB865980; Fri, 28 Apr 2006 20:53:46 +0200 (CEST) Message-ID: <445264BA.8080708@motorola.com> Date: Fri, 28 Apr 2006 20:53:46 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Junghoon Jee Subject: Re: [Mip6] Questions ondraft-ietf-mip6-bootstrapping-integrated-dhc-00.txt References: <445242EE.9050008@motorola.com> <002301c66ae4$bd750b50$b28feada@FLY> <44524AD8.2020702@motorola.com> <003601c66ae7$df1a24e0$b28feada@FLY> <44525DD0.3070303@motorola.com> <007001c66af1$53eab0b0$b28feada@FLY> In-Reply-To: <007001c66af1$53eab0b0$b28feada@FLY> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Junghoon Jee wrote: >> Ok, let's put it this way: what is the key (or the id) that the MN >> uses to query the DHCP or any other entity in the network in order >> to obtain its Home Agent Address and Home Address. What is the >> pre-configured information on MN in the integrated scenario? I >> thought that is the NAI converted into the realm name >> (example.com). Is it so? > > Yes. Now, if the pre-configured information is NAI, and only NAI, how does the intervening infrastructure (DHCP, AAA, DNS) know how to convert example.com into the corresponding home subnet address, or home agent address? In example.com there may be very many subnets and each needs its different subnet address. Realm of NAI is especially designed so that it covers either a large network, or sometimes even a network that has no subnet at all, i.e. zero. Which of these two cases does the integrated scenario consider? Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 28 15:00:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZYCe-0002DR-Ow; Fri, 28 Apr 2006 15:00:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZYCe-0002DH-6k for mip6@ietf.org; Fri, 28 Apr 2006 15:00:32 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZYCd-0004du-Pk for mip6@ietf.org; Fri, 28 Apr 2006 15:00:32 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3SJ0Ual011292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 28 Apr 2006 12:00:30 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3SJ0SQB029892; Fri, 28 Apr 2006 12:00:29 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Apr 2006 12:00:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Again on port number for DS-MIPv6 (was: [Mip6] MN's address as seen by HA is not its CoA but NAT's address (when NAT)) Date: Fri, 28 Apr 2006 12:00:28 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF002555E59@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Again on port number for DS-MIPv6 (was: [Mip6] MN's address as seen by HA is not its CoA but NAT's address (when NAT)) Thread-Index: AcZq8+K7n0p7jZ4DQfqI/cnWkA+NHgAAUolA From: "Soliman, Hesham" To: "Alexandru Petrescu" X-OriginalArrivalTime: 28 Apr 2006 19:00:29.0532 (UTC) FILETIME=[046BF1C0:01C66AF6] X-Spam-Score: 1.7 (+) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: "Zhang, Qiang \[NTK\]" , Henrik Levkowetz , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > > =3D> I disagree. This is not different from any other UDP=20 > connection. I > > don't see why we should treat it differently. Of course the IPv6=20 > > packet can be protected with IPsec. >=20 > (1) in case HA is different than GW, and attacker spoofs that port > number, then the link between HA and GW can be DoS'ed. >=20 > (2) in case HA and GW are the same, and depending of the NAT=20 > keepalive > mechanism, it is easy for attacker to fake a source port number as > coming from NAT to GW and make it think the NAT state is up. =3D> What GW are you talking about????=20 > > =3D> My response to this comment and your response to Ryuji=20 > is that you > > should read the NAT traversal and keepalive section in the draft.=20 > > The default value for keepalives is 110s I think. This is=20 > used when=20 > > the NAT binding is not refreshed with normal traffic. >=20 > I've read it. If the BU/BAck happens every 110s and the NAT=20 > changed src > port right at the beginnning of this 110s period, then the=20 > IPv6 app on > GW streaming to MN will suffer a 110s delay until next=20 > BU/BAck. Would > you agree? =3D> No. There is no change in the port numbers if you maintain the NAT bindings. I don't know what NAT implementation you have in mind but it sounds like a broken one. > > =3D> If you have an app running then you don't need to send=20 > keepalives > > at all. >=20 > That's plain wrong. =20 =3D> No, it's right. Again, even if there is traffic, the=20 > NAT src port > may change with a periodicity that is not detectable. =20 =3D> That's nonesense. If a NAT changes its bindings despite ongoing traffic=20 then the implementation is broken. >=20 > Why not? Stateless auto-config is a quick and widely=20 > implemented way of > auto-configuring an address. How else would MN=20 > auto-configure an IPv6 > address when MN behind NAT? =3D> It doesn't! So may be you read the draft but I don't think you understood the scenarios. Stateless applies to the CoA, in this scenario the CoA is a v4 address. >=20 > > I've assumed that the GW you refer to is the HA. But now I'm=20 > > confused, what's this GW you refer to? >=20 > Simply put because it is good to have the GW supporting NAT traversal > and IPv6/IPv4 conversion separated from the HA doing MIP6. =3D> That's not in the draft today so I don't know where you got that from.=20 Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 28 15:40:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZYpC-0007sY-Uo; Fri, 28 Apr 2006 15:40:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZYpB-0007n0-Ve for mip6@ietf.org; Fri, 28 Apr 2006 15:40:21 -0400 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZYpA-0007CI-JM for mip6@ietf.org; Fri, 28 Apr 2006 15:40:21 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate.mot.com (Motorola/Motgate) with ESMTP id k3SJeHuv021508; Fri, 28 Apr 2006 12:40:17 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id k3SJrmes002489; Fri, 28 Apr 2006 14:53:48 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 26323865980; Fri, 28 Apr 2006 21:40:15 +0200 (CEST) Message-ID: <44526F9E.70709@motorola.com> Date: Fri, 28 Apr 2006 21:40:14 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Henrik Levkowetz References: <1487A357FD2ED544B8AD29E528FF9DF0024F2419@NAEX06.na.qualcomm.com> <44513C22.9090706@motorola.com> <445244F0.4010905@motorola.com> <44524D69.6080709@levkowetz.com> <44525415.3050103@motorola.com> <445262C7.6050603@levkowetz.com> In-Reply-To: <445262C7.6050603@levkowetz.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: "Zhang, Qiang \[NTK\]" , Ryuji Wakikawa , "Soliman, Hesham" , mip6@ietf.org Subject: [Mip6] Re: When behind NAT MN should have a real IPv6 CoA not mapped (was: Again on port number for DS-MIPv6) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Henrik Levkowetz wrote: > Hi Alexandru, > > on 2006-04-28 19:42 Alexandru Petrescu said the following: >> Henrik Levkowetz wrote: >>> Hi Alexandru, >>> >>> on 2006-04-28 18:38 Alexandru Petrescu said the following: ... >>> >>>> Whenever MN opens a UDP "connection" through NAT to GW the >>>> state created there only lasts for some time, for a timelength >>>> which is little predictable. And, since the draft doesn't >>>> offer a NAT state maintenance procedure I assume the port >>>> number changes. Is this wrong? >>> Yes, that is wrong. >> Partially. > > Completely. 28.5% false. >>> The draft specifies a NAT state keepalive mechanism. >> The NAT state keepalive mechanism specified by draft is basically >> the following: >> >>> However, if the mobile node is not active, it will need to >>> periodically send a message to the home agent in order to refresh >>> the NAT binding. This can be done using the binding update >>> message. >> For one, when this BU/BAck happens and the NAT UDP src port number >> has changed, > > The whole point of the keepalive is to make sure that the port number > doesn't change, and *it will not change* if you use the keepalive > appropriately. Indeed, _if_ used appropriately. The way specified doesn't qualify as such. >> the BAck will indeed go back. But if after this BU/BAck happening, >> GW/HA wants to send a BRR (to refresh the binding and the NAT >> state)? How does the code sending BRR know which was the port >> number used by the code who sent BAck? BRR is triggered by a timer >> while BAck by reception of a BU. It's not same code flow. > > Nonsense. All UDP applications basically work the same way: send the > response back to the originators source port. We have no UDP "application" here. The "application" is a MIP6 implementation which is not a payload type. There's no service number assigned to MIP6. Real UDP applications are not preceded by IPv6 headers, they are carried by UDP headers. > I've implemented this for MIPv4 NAT traversal. Great. On what deployed NATs have you tried it? > Can you say the same? I've implemented NAT traversal using the MIP4 NAT traversal, and for MIP6. The keepalive is every second RA and ping from both directions. There is UDP virtual interface and there are IPv6 RAs on that. The CoA is IPv6, the HoA is IPv6 too. No v4-mapped addresses. For a long time (really!) I've tried to understand the logic by which NAT changes its src addres and concluded that I can't conclude anything, just that it changes it whenever it pleases. Most certainly I've concluded that NAT keepalives every 110s will risk (at most) 110s app interrupts. I've also successfully tested 6to4 on MN behind some more gentle NATs. Can you say the same? > Unless you've actually coded this I'd suggest that you're whistling > in the dark here. Let me return this back, if you permit: unless you've actually tried it against some deployed NATs etc etc... >> Second, if we need MN to simply auto-configure an IPv6 CoA while >> behind NAT then there should be RAs over the UDP "tunnel". > > This has absolutely nothing to do with keepalives or NATs. The only > guess at a relevant answer I have is that it seems like you haven't > read the draft at all. Please do so. I did, several times, since earliest versions, discussed extensively on the list. If the draft doesn't specify that the address MN obtains while behind NAT is a IPv6 Care-of Address from the tunnel interface then that's its problem, not mine. >> Third, BU/BAck is mainly meant to update HoA-CoA bindings. Or, >> neither changes while MN is behind NAT, even if MN changes its v4 >> address due to v4 mobility. > > Please read the draft. If you can say that there's no BU needed if > the IPv4 CoA changes, I can't see how you can have read the draft. The fact that the draft mentions nothing at all about MN having a real IPv6 CoA when behind NAT is none of my faults. The fact that DS-MIPv6 requires MN to support IPv4 Home Addresses, but does not permit MN to have a real IPv6 CoA when behind NAT is none of my faults either. >> Do you think this is enough to motivate a different mechanism for >> NAT state maintenance than just BU/BAck? Do you disagree with any >> of the above items? (store NAT src port number on GW, BAck not >> needed for keepalive, RA should happen on "tunnel", BU/BAck is not >> the right tool for maintenance)? > > I think you need to read the draft. Ok I'll try again. >>> But with the keepalive mechanism, this does work, >> The keepalive mechanism mentioned in the draft (BU/BAck) has not >> been tested here. > > ?? I'm sorry that you haven't tested it. Maybe you should. I used ping and RAs, with parametrable timeouts, from both directions. Isn't that the same with NAT traversal? It's just traffic. I haven't used BU/BAck because the IPv6 address wouldn't change. >>> in the same manner as the tested and verified mechanism of RFC >>> 3519. >> That document talks about MIP4. It does make sense to take >> advantage of RegReq/RegRep to maintain NAT state, because the IPv4 >> address does change every now and then. But with DS-MIPv6 the >> IPv6 CoA doesn't change at all while behind NAT. Would you agree? > > I think you've mixed this up wonderfully, and would prefer that you > read the draft before we discuss this any further. Wonderful is our misunderstanding, indeed. So there seems to be a common understanding that with DS-MIPv6 MN will have no real IPv6 CoA when behind NAT... well I, oppose that. >> Also I'm wondering whether in that document the NAT src port number >> is stored in the registration table so that other code than >> RegReq/RegRep can take advantage of it? > > Well, maybe the best way to find out is to read the document? Will try again. Maybe I should start with the requirements: draft: > Since running Mobile IPv4 and Mobile IPv6 simultaneously is > problematic (as illustrated in [MIP-PB]), this scenario adds a > requirement on Mobile IPv6 to support IPv4 home addresses. Ok, but can MIPv6 MN (3775, 3776) still support an IPv6 Care-of Address for this Mobile Node when MN behind NAT, over the UDP "tunnel" interface? How does 3776 work when the IPv6 CoA is actually an IPv4 CoA, and behind NAT? Because when behind NAT the IPv4 address for two MNs is the same. How does HA know to whom to send traffic it intercepts for MN's HoA when the CoA is NAT's public address and there's no port number saved? And existing IPv6 bootstrapping work when CoA is IPv4 and not IPv6? Or is this something new to work upon? And finally, what do you guys have against MN having a real IPv6 CoA when behind NAT? What would that break? Wouldn't software reusability be good? 3775, 3776 and bootstrapping work work unmodified. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 28 15:53:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZZ2E-0007Af-3Z; Fri, 28 Apr 2006 15:53:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZZ2C-0007AV-V1 for mip6@ietf.org; Fri, 28 Apr 2006 15:53:48 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZZ2C-0007xY-M8 for mip6@ietf.org; Fri, 28 Apr 2006 15:53:48 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3SKAXcC003296; Fri, 28 Apr 2006 13:10:33 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id k3SK7jnp023258; Fri, 28 Apr 2006 15:07:46 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 9ADEE865980; Fri, 28 Apr 2006 21:53:40 +0200 (CEST) Message-ID: <445272C4.5090502@motorola.com> Date: Fri, 28 Apr 2006 21:53:40 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Soliman, Hesham" References: <1487A357FD2ED544B8AD29E528FF9DF002555E59@NAEX06.na.qualcomm.com> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF002555E59@NAEX06.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: "Zhang, Qiang \[NTK\]" , Henrik Levkowetz , mip6@ietf.org Subject: [Mip6] Re: NAT assumptions for DS-MIPv6 (was: Again on port number for DS-MIPv6) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Soliman, Hesham wrote: >> (1) in case HA is different than GW, and attacker spoofs that port >> number, then the link between HA and GW can be DoS'ed. >> >> (2) in case HA and GW are the same, and depending of the NAT >> keepalive mechanism, it is easy for attacker to fake a source port >> number as coming from NAT to GW and make it think the NAT state is >> up. > > => What GW are you talking about???? The one different than HA. HA would run only IPv6 and GW would run both v4 and v6. This would be very helpful. I don't see why not. Much infrastructure is IPv6 exclusively today. That was said many times, would you agree? >>> => My response to this comment and your response to Ryuji >> is that you >>> should read the NAT traversal and keepalive section in the draft. >>> The default value for keepalives is 110s I think. This is >> used when >>> the NAT binding is not refreshed with normal traffic. >> >> I've read it. If the BU/BAck happens every 110s and the NAT >> changed src port right at the beginnning of this 110s period, then >> the IPv6 app on GW streaming to MN will suffer a 110s delay until >> next BU/BAck. Would you agree? > > => No. There is no change in the port numbers if you maintain the NAT > bindings. Well, that's plain wrong again. There's no way to maintain NAT bindings, even with running traffic. Try it. Some NAT/firewalls are more gentle than others. Try some tough ones. The only possibility is to dynamically detect them. You never know the sauce a NAT is doing to ensure connectivity. > I don't know what NAT implementation you have in mind but it sounds > like a broken one. A "broken" NAT implementation??? As if there are "right NAT implementations"? C'mmon... What's a "right NAT implementation" that is not broken? Every fw admin configures his/her admin at his/her own will. >>> => If you have an app running then you don't need to send >> keepalives >>> at all. >> >> That's plain wrong. > > => No, it's right. No, it's wrong. Try it. Otherwise how can I prove it to you? >> Again, even if there is traffic, the NAT src port may change with a >> periodicity that is not detectable. >> > > => That's nonesense. If a NAT changes its bindings despite ongoing > traffic then the implementation is broken. Again, what's a "broken NAT" implementation? Is there a right one? I'm afraid we're not clear on what a NAT is. This may turn into having a DS-MIPv6 section specifying what assumptions we make on NAT. And/or whether DS-MIPv6 will have any software components implemented on NAT. >> Why not? Stateless auto-config is a quick and widely implemented >> way of auto-configuring an address. How else would MN >> auto-configure an IPv6 address when MN behind NAT? > > => It doesn't! So may be you read the draft but I don't think you > understood the scenarios. Stateless applies to the CoA, in this > scenario the CoA is a v4 address. Why not having an IPv6 CoA? Why not sending IPv6 RAs over the tunnel? I've tried, it works. >>> I've assumed that the GW you refer to is the HA. But now I'm >>> confused, what's this GW you refer to? >> >> Simply put because it is good to have the GW supporting NAT >> traversal and IPv6/IPv4 conversion separated from the HA doing >> MIP6. > > => That's not in the draft today so I don't know where you got that > from. Let's say I've silently invented it. Anything wrong with that? Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 28 15:54:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZZ2y-0007Vk-QN; Fri, 28 Apr 2006 15:54:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZZ2x-0007Vf-Jn for mip6@ietf.org; Fri, 28 Apr 2006 15:54:35 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZZ2w-00087j-88 for mip6@ietf.org; Fri, 28 Apr 2006 15:54:35 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3SJsW5w019348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 28 Apr 2006 12:54:33 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3SJsVMY017828; Fri, 28 Apr 2006 12:54:32 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Apr 2006 12:54:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 28 Apr 2006 12:54:31 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF002555F05@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: When behind NAT MN should have a real IPv6 CoA not mapped (was: Again on port number for DS-MIPv6) Thread-Index: AcZq/B9IqRh1nGZtRoq95/STOFOCLQAAOM9Q From: "Soliman, Hesham" To: "Alexandru Petrescu" , "Henrik Levkowetz" X-OriginalArrivalTime: 28 Apr 2006 19:54:31.0552 (UTC) FILETIME=[90D0F000:01C66AFD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: "Zhang, Qiang \[NTK\]" , Ryuji Wakikawa , mip6@ietf.org Subject: [Mip6] RE: When behind NAT MN should have a real IPv6 CoA not mapped (was: Again on port number for DS-MIPv6) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org I just want to make one point as clear as I can: > > And finally, what do you guys have against MN having a real IPv6 CoA > when behind NAT? What would that break? =20 =3D> The fact that it is behind a NAT should make it very clear that the visited network does not support IPv6. Therefore, getting an IPv6 CoA (which is,=20 by definition, provided by the visited network), is not possible. Therefore,=20 the draft doesn't talk about getting an IPv6 CoA when the MN is in an IPv4 network. Wouldn't software=20 > reusability > be good? 3775, 3776 and bootstrapping work work unmodified. =3D> What does bootstrapping and 3775/6 have to do with stateless autoconfig (defined in 2462)? Nothing... Hesham >=20 > Alex >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 28 16:27:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZZYd-0003OT-UY; Fri, 28 Apr 2006 16:27:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZZYc-0003OO-Hf for mip6@ietf.org; Fri, 28 Apr 2006 16:27:18 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZZYc-0001pe-9w for mip6@ietf.org; Fri, 28 Apr 2006 16:27:18 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3SKi7f7010672; Fri, 28 Apr 2006 13:44:07 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k3SKikN5015213; Fri, 28 Apr 2006 15:44:46 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 656E1865980; Fri, 28 Apr 2006 22:27:14 +0200 (CEST) Message-ID: <44527AA1.8000501@motorola.com> Date: Fri, 28 Apr 2006 22:27:13 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Soliman, Hesham" References: <1487A357FD2ED544B8AD29E528FF9DF002555F05@NAEX06.na.qualcomm.com> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF002555F05@NAEX06.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: "Zhang, Qiang \[NTK\]" , Ryuji Wakikawa , Henrik Levkowetz , mip6@ietf.org Subject: [Mip6] Re: When behind NAT MN should have a real IPv6 CoA not mapped (was: Again on port number for DS-MIPv6) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Soliman, Hesham wrote: > I just want to make one point as clear as I can: Sure! >> And finally, what do you guys have against MN having a real IPv6 >> CoA when behind NAT? What would that break? > > => The fact that it is behind a NAT should make it very clear that > the visited network does not support IPv6. Indeed, it doesn't. > Therefore, getting an IPv6 CoA (which is, by definition, provided by > the visited network) Definition sounds logical. But if while in the visited network the MN opens a tunnel interface, would this tunnel be able to have an IPv6 address? I guess yes. Do you mind me calling it a "CoA"? Can I call it a "NAT IPv6 CoA"? Otherwise, if the "visited network" is actually the tunnel link, can I still say that the IPv6 CoA of the MN when the tunnel link is up is a CoA? Otherwise, "visited network" isn't in 3753 "mobility related terminology", and neither in the Definitions of 3775, although used there extensively. But let's not blindly abide some definitions here. Technically speaking what wrong do you see with a NAT IPv6 CoA? What would it break? What software re-use would make it impossible? > Therefore, the draft doesn't talk about getting an IPv6 CoA when the > MN is in an IPv4 network. Oh, I see. Maybe it should, because otherwise the DS-MIPv6 draft should talk about decrementing some TTL when encapsulating. It currently doesn't. >> Wouldn't software reusability be good? 3775, 3776 and >> bootstrapping work work unmodified. > > => What does bootstrapping and 3775/6 have to do with stateless > autoconfig (defined in 2462)? Nothing... Well, from implementation again, if the first thing one does is to have stateless auto-config (i.e. have a real IPv6 CoA) running on the UDP tunnel, then bootstrapping would work unmodified, 3776 too. Otherwise I wonder how 3776 would work with IPv4 Care-of Addresses, especially when there is no real IPv6 Care-of Address, especially when the IPv4 CoA behind NAT, so an IPv4 address is common to two nodes. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 28 16:29:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZZaU-0003o0-Q5; Fri, 28 Apr 2006 16:29:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZZaT-0003nv-8y for mip6@ietf.org; Fri, 28 Apr 2006 16:29:13 -0400 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZZaR-0001uK-Tb for mip6@ietf.org; Fri, 28 Apr 2006 16:29:13 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.10.03) with ESMTP id k3SKT0ls020569; Fri, 28 Apr 2006 22:29:00 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [192.44.77.29]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.09.01) with ESMTP id k3SKSvpM020550; Fri, 28 Apr 2006 22:28:57 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id k3SKStus017550; Fri, 28 Apr 2006 22:28:56 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200604282028.k3SKStus017550@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Soliman, Hesham" Subject: Re: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt In-reply-to: Your message of Wed, 26 Apr 2006 08:58:32 PDT. <1487A357FD2ED544B8AD29E528FF9DF00247DC98@NAEX06.na.qualcomm.com> Date: Fri, 28 Apr 2006 22:28:55 +0200 X-Virus-Scanned: amavisd-new at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Gopal Dommety , mip6@ietf.org, jari.arkko@ericsson.com, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org In your previous mail you wrote: > I don't like the transport all mode for architectural reasons. => Ok. can you please elaborate? => I consider the HAO as a degenerated tunnel so you have double tunneling (one tunnel for IPsec, one for MIPv6) when obviously only one is needed. I know you never liked it but I don't know what the architectural reasons are. => double tunneling. I think it's a more "correct" use of IPsec to not use tunnel mode between two end nodes. => but is the right end the HA or the CN (:-)? IMO tunnel mode only needs to be used when an intermediate node is terminating/initiating IPsec. => this is the case here: the intermediate node is the HA. Regards Francis.Dupont@point6.net _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 28 16:59:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZa3b-0007B5-LT; Fri, 28 Apr 2006 16:59:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZa3a-0007B0-Gk for mip6@ietf.org; Fri, 28 Apr 2006 16:59:18 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZa3Z-0003a1-8O for mip6@ietf.org; Fri, 28 Apr 2006 16:59:18 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3SLG8Kf020361 for ; Fri, 28 Apr 2006 14:16:08 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id k3SLE3s1024721 for ; Fri, 28 Apr 2006 16:14:03 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id D062E865980 for ; Fri, 28 Apr 2006 22:59:15 +0200 (CEST) Message-ID: <44528223.5080806@motorola.com> Date: Fri, 28 Apr 2006 22:59:15 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: mip6@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [Mip6] Increment/Decrement TTL when traversing NAT (DS-MIPv6) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Should the draft specify that both MN and HA should increment and decrement TTL of the IPv4 header when de- and en-capsulating in UDP? RFC 3519 (MIP4 NAT traversal) only talks about decrementing the TTL, not incrementing. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 28 17:07:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZaBV-0001A7-Qc; Fri, 28 Apr 2006 17:07:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZaBU-00019x-O5 for mip6@ietf.org; Fri, 28 Apr 2006 17:07:28 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZaBT-0004Xb-Ch for mip6@ietf.org; Fri, 28 Apr 2006 17:07:28 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3SL7Gn7026673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 28 Apr 2006 14:07:16 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3SL7E7d007411; Fri, 28 Apr 2006 14:07:15 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Apr 2006 14:07:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt Date: Fri, 28 Apr 2006 14:07:09 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF002555FD6@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt Thread-Index: AcZrAnHCV9vfRWFIRX2dvsMpy4kwcgABMQYQ From: "Soliman, Hesham" To: X-OriginalArrivalTime: 28 Apr 2006 21:07:14.0550 (UTC) FILETIME=[B95D9960:01C66B07] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Gopal Dommety , mip6@ietf.org, jari.arkko@ericsson.com, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org >=20 > =3D> I consider the HAO as a degenerated tunnel so you have double > tunneling (one tunnel for IPsec, one for MIPv6) when obviously only > one is needed. =3D> Understood. I do think this is a matter of taste though not architecture. > I think > it's a more "correct" use of IPsec to not use tunnel mode > between two end nodes. >=20 > =3D> but is the right end the HA or the CN (:-)? =3D> It's always the HA as far as IPsec is concernced. In some cases the messages are processed by the HA (BU, MPD), in others the HA is treated like a security GW (HOTI, payload). So as far as IPsec is concerned the end node is always the HA. The fact that=20 the packet is then forwarded somewhere else is irrelevant to IPsec.=20 Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 28 17:28:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZaVZ-0005z3-Qh; Fri, 28 Apr 2006 17:28:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZaVX-0005xX-OD for mip6@ietf.org; Fri, 28 Apr 2006 17:28:11 -0400 Received: from [129.188.136.9] (helo=ftpbox.mot.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZaVW-000884-Gk for mip6@ietf.org; Fri, 28 Apr 2006 17:28:11 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by ftpbox.mot.com (8.12.11/Motgate7) with ESMTP id k3SLXsF4004737 for ; Fri, 28 Apr 2006 16:33:54 -0500 (CDT) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id k3SLe01r008609 for ; Fri, 28 Apr 2006 16:40:01 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 6CACD865980 for ; Fri, 28 Apr 2006 23:28:08 +0200 (CEST) Message-ID: <445288E8.5000309@motorola.com> Date: Fri, 28 Apr 2006 23:28:08 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: mip6@ietf.org References: <44528223.5080806@motorola.com> In-Reply-To: <44528223.5080806@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Mip6] Re: no, just decrement TTL, because it's a link (was: Increment/Decrement TTL when traversing NAT (DS-MIPv6)) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Alexandru Petrescu wrote: > Should the draft specify that both MN and HA should increment and > decrement TTL of the IPv4 header when de- and en-capsulating in UDP? > > RFC 3519 (MIP4 NAT traversal) only talks about decrementing the TTL, > not incrementing. Me again, sorry for following up my own question. Both MN and HA should only decrement the TTL. The other end should not increment it back. Because the whole meaning of TTL is to be decremented when traversing links, such that PMTU and other protocols can work. Thus, if the UDP tunnel is actually a link (RFC 3519 says TTL is decremented) then the HA attached to it, being a router, could send RAs on it, no? I mean nobody forbids it to do so, it's even recommended by some RFC. Besides, at least one widespread implementation (radvd) can do it, I've tried. So again, why not doing it? More in its favor: setting up a 6to4 on MN behind some gentle NAT (read one allowing IPv6-in-IPv4,) is a breeze on linux. Once connected to the IPv6 with 6to4 one can obviously run standard MIP6. When connected to 6to4 the MN gets a real IPv6 CoA, so run 3775/6 MIP6. Don't trust me: try it. So, why not having an IPv6 real address over the UDP tunnel too? Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 28 17:46:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZamz-0000zO-NJ; Fri, 28 Apr 2006 17:46:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZamy-0000xh-SQ for mip6@ietf.org; Fri, 28 Apr 2006 17:46:12 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZamx-0008TL-Jg for mip6@ietf.org; Fri, 28 Apr 2006 17:46:12 -0400 Received: from [10.1.201.8] ([10.1.201.8]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Apr 2006 14:46:08 -0700 Message-ID: <44528D1E.3000802@azairenet.com> Date: Fri, 28 Apr 2006 14:46:06 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt References: <1487A357FD2ED544B8AD29E528FF9DF002555FD6@NAEX06.na.qualcomm.com> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF002555FD6@NAEX06.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Apr 2006 21:46:08.0629 (UTC) FILETIME=[2895CA50:01C66B0D] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Francis.Dupont@point6.net, Gopal Dommety , Basavaraj Patil , jari.arkko@ericsson.com, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Soliman, Hesham wrote: > > => but is the right end the HA or the CN (:-)? > > => It's always the HA as far as IPsec is concernced. In some > cases the messages are processed by the HA (BU, MPD), in others > the HA is treated like a security GW (HOTI, payload). So as far as > IPsec is concerned the end node is always the HA. The fact that > the packet is then forwarded somewhere else is irrelevant to IPsec. hmm no... this doesnt fit in with the IPsec architecture. if after decapsulation, the inner packet needs to be sent out of the node to another node, it becomes a gateway automatically. the destination of the packets is now not the gateway. typically a tunnel mode SA is used to protect such packets. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 28 18:36:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZbYp-00031M-J9; Fri, 28 Apr 2006 18:35:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZbYo-00031H-3y for mip6@ietf.org; Fri, 28 Apr 2006 18:35:38 -0400 Received: from av9-1-sn2.hy.skanova.net ([81.228.8.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZbYm-00029a-Qr for mip6@ietf.org; Fri, 28 Apr 2006 18:35:38 -0400 Received: by av9-1-sn2.hy.skanova.net (Postfix, from userid 502) id EA3A037FB5; Sat, 29 Apr 2006 00:35:35 +0200 (CEST) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av9-1-sn2.hy.skanova.net (Postfix) with ESMTP id C0F9C37EA1; Sat, 29 Apr 2006 00:35:35 +0200 (CEST) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id 1CBC237E42; Sat, 29 Apr 2006 00:35:34 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.61) (envelope-from ) id 1FZbYf-0006GG-OW; Sat, 29 Apr 2006 00:35:34 +0200 Message-ID: <445298B1.1040803@levkowetz.com> Date: Sat, 29 Apr 2006 00:35:29 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.2 (Macintosh/20060308) MIME-Version: 1.0 To: Alexandru Petrescu References: <1487A357FD2ED544B8AD29E528FF9DF002555E59@NAEX06.na.qualcomm.com> <445272C4.5090502@motorola.com> In-Reply-To: <445272C4.5090502@motorola.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: "Zhang, Qiang \[NTK\]" , "Soliman, Hesham" , mip6@ietf.org Subject: [Mip6] Re: NAT assumptions for DS-MIPv6 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Alexandru, on 2006-04-28 21:53 Alexandru Petrescu said the following: > Well, that's plain wrong again. There's no way to maintain NAT > bindings, even with running traffic. Try it. No. You try it. We've tried extensively, and your statement doesn't match the reality we've observed. > Some NAT/firewalls are > more gentle than others. Try some tough ones. The only possibility is > to dynamically detect them. Thank you for the lecture. I've written RFC 3519, implemented it, tested the code, deployed it. That you're throwing out statements which is contrary to everything I've seen doesn't convince me that I should throw out all the experience I have. Sorry, but no go. The only way you're going to get some credibility here is to provide actual measurements of actual named products to back up your allegations. Henrik _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 28 18:48:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZblR-0004Bm-Aw; Fri, 28 Apr 2006 18:48:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZblP-00044n-TW for mip6@ietf.org; Fri, 28 Apr 2006 18:48:39 -0400 Received: from av9-2-sn3.vrr.skanova.net ([81.228.9.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZblP-0002S5-7A for mip6@ietf.org; Fri, 28 Apr 2006 18:48:39 -0400 Received: by av9-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 5997738193; Sat, 29 Apr 2006 00:48:38 +0200 (CEST) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av9-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 456A837FB5; Sat, 29 Apr 2006 00:48:38 +0200 (CEST) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 1F7B737E42; Sat, 29 Apr 2006 00:48:37 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.61) (envelope-from ) id 1FZblM-0006dk-SV; Sat, 29 Apr 2006 00:48:36 +0200 Message-ID: <44529BC4.3040609@levkowetz.com> Date: Sat, 29 Apr 2006 00:48:36 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.2 (Macintosh/20060308) MIME-Version: 1.0 To: Alexandru Petrescu References: <1487A357FD2ED544B8AD29E528FF9DF0024F2419@NAEX06.na.qualcomm.com> <44513C22.9090706@motorola.com> <445244F0.4010905@motorola.com> <44524D69.6080709@levkowetz.com> <44525415.3050103@motorola.com> <445262C7.6050603@levkowetz.com> <44526F9E.70709@motorola.com> In-Reply-To: <44526F9E.70709@motorola.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 Cc: "Zhang, Qiang \[NTK\]" , Ryuji Wakikawa , "Soliman, Hesham" , mip6@ietf.org Subject: [Mip6] Re: When behind NAT MN should have a real IPv6 CoA not mapped (was: Again on port number for DS-MIPv6) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org on 2006-04-28 21:40 Alexandru Petrescu said the following: > Henrik Levkowetz wrote: >> Hi Alexandru, >> >> on 2006-04-28 19:42 Alexandru Petrescu said the following: >>> Henrik Levkowetz wrote: >>>> Hi Alexandru, >>>> >>>> on 2006-04-28 18:38 Alexandru Petrescu said the following: ... >>>> >>>>> Whenever MN opens a UDP "connection" through NAT to GW the >>>>> state created there only lasts for some time, for a timelength >>>>> which is little predictable. And, since the draft doesn't >>>>> offer a NAT state maintenance procedure I assume the port >>>>> number changes. Is this wrong? >>>> Yes, that is wrong. >>> Partially. >> >> Completely. > > 28.5% false. Impressive figure. I see you've backed it up with documented calculations, too. >>>> The draft specifies a NAT state keepalive mechanism. >>> The NAT state keepalive mechanism specified by draft is basically >>> the following: >>> >>>> However, if the mobile node is not active, it will need to >>>> periodically send a message to the home agent in order to refresh >>>> the NAT binding. This can be done using the binding update >>>> message. >>> For one, when this BU/BAck happens and the NAT UDP src port number >>> has changed, >> >> The whole point of the keepalive is to make sure that the port number >> doesn't change, and *it will not change* if you use the keepalive >> appropriately. > > Indeed, _if_ used appropriately. The way specified doesn't qualify as such. I believe you're wrong here. Since 3519 is known to work, and this draft describes an equivalent mechanism, you'll have to be very specific about what doesn't work. You haven't come close to this yet. >>> the BAck will indeed go back. But if after this BU/BAck happening, >>> GW/HA wants to send a BRR (to refresh the binding and the NAT >>> state)? How does the code sending BRR know which was the port >>> number used by the code who sent BAck? BRR is triggered by a timer >>> while BAck by reception of a BU. It's not same code flow. >> >> Nonsense. All UDP applications basically work the same way: send the >> response back to the originators source port. > > We have no UDP "application" here. The "application" is a MIP6 > implementation which is not a payload type. There's no service number > assigned to MIP6. Real UDP applications are not preceded by IPv6 > headers, they are carried by UDP headers. As is the IPv6 payload in this case. *DID YOU READ THE DRAFT??????* >> I've implemented this for MIPv4 NAT traversal. > > Great. On what deployed NATs have you tried it? Oh, I'd guess around n*100 different ones. Do you usually get the brand and model of a firewall when you visit a hot-spot? >> Can you say the same? > > I've implemented NAT traversal using the MIP4 NAT traversal, and for > MIP6. The keepalive is every second RA and ping from both directions. > There is UDP virtual interface and there are IPv6 RAs on that. The CoA > is IPv6, the HoA is IPv6 too. No v4-mapped addresses. This sounds like an implementation which isn't 3519-compliant at all. > For a long time (really!) I've tried to understand the logic by which > NAT changes its src addres and concluded that I can't conclude anything, > just that it changes it whenever it pleases. Most certainly I've > concluded that NAT keepalives every 110s will risk (at most) 110s app > interrupts. No wonder if you haven't implemented what's described - and it really doesn't sound like it. > I've also successfully tested 6to4 on MN behind some more gentle NATs. > > Can you say the same? Yup. >> Unless you've actually coded this I'd suggest that you're whistling >> in the dark here. > > Let me return this back, if you permit: unless you've actually tried it > against some deployed NATs etc etc... > >>> Second, if we need MN to simply auto-configure an IPv6 CoA while >>> behind NAT then there should be RAs over the UDP "tunnel". >> >> This has absolutely nothing to do with keepalives or NATs. The only >> guess at a relevant answer I have is that it seems like you haven't >> read the draft at all. Please do so. > > I did, several times, since earliest versions, discussed extensively on > the list. If the draft doesn't specify that the address MN obtains > while behind NAT is a IPv6 Care-of Address from the tunnel interface > then that's its problem, not mine. You don't use an IPv6 CoA when you're in an IPv4 access, whether behind a NAT or not. >>> Third, BU/BAck is mainly meant to update HoA-CoA bindings. Or, >>> neither changes while MN is behind NAT, even if MN changes its v4 >>> address due to v4 mobility. >> >> Please read the draft. If you can say that there's no BU needed if >> the IPv4 CoA changes, I can't see how you can have read the draft. > > The fact that the draft mentions nothing at all about MN having a real > IPv6 CoA when behind NAT is none of my faults. It doesn't. It seems you haven't understood the basics. > The fact that DS-MIPv6 requires MN to support IPv4 Home Addresses, but > does not permit MN to have a real IPv6 CoA when behind NAT is > none of my faults either. No, but understanding the basics of the mechanism is, I believe, your responsibiltiy. >>> Do you think this is enough to motivate a different mechanism for >>> NAT state maintenance than just BU/BAck? Do you disagree with any >>> of the above items? (store NAT src port number on GW, BAck not >>> needed for keepalive, RA should happen on "tunnel", BU/BAck is not >>> the right tool for maintenance)? >> >> I think you need to read the draft. > > Ok I'll try again. Thank you. >>>> But with the keepalive mechanism, this does work, >>> The keepalive mechanism mentioned in the draft (BU/BAck) has not >>> been tested here. >> >> ?? I'm sorry that you haven't tested it. Maybe you should. > > I used ping and RAs, with parametrable timeouts, from both directions. > Isn't that the same with NAT traversal? It's just traffic. I haven't > used BU/BAck because the IPv6 address wouldn't change. > >>>> in the same manner as the tested and verified mechanism of RFC >>>> 3519. >>> That document talks about MIP4. It does make sense to take >>> advantage of RegReq/RegRep to maintain NAT state, because the IPv4 >>> address does change every now and then. But with DS-MIPv6 the >>> IPv6 CoA doesn't change at all while behind NAT. Would you agree? >> >> I think you've mixed this up wonderfully, and would prefer that you >> read the draft before we discuss this any further. > > Wonderful is our misunderstanding, indeed. > > So there seems to be a common understanding that with DS-MIPv6 MN will > have no real IPv6 CoA when behind NAT... well I, oppose that. > >>> Also I'm wondering whether in that document the NAT src port number >>> is stored in the registration table so that other code than >>> RegReq/RegRep can take advantage of it? >> >> Well, maybe the best way to find out is to read the document? > > Will try again. Maybe I should start with the requirements: > > draft: >> Since running Mobile IPv4 and Mobile IPv6 simultaneously is >> problematic (as illustrated in [MIP-PB]), this scenario adds a >> requirement on Mobile IPv6 to support IPv4 home addresses. > > Ok, but can MIPv6 MN (3775, 3776) still support an IPv6 Care-of Address > for this Mobile Node when MN behind NAT, over the UDP "tunnel" interface? Oh, I'm sure we could arrange for that, but there is no reason to, I believe. > How does 3776 work when the IPv6 CoA is actually an IPv4 CoA, and behind > NAT? Because when behind NAT the IPv4 address for two MNs is the same. That's why you need the UDP tunnel, using the port numbers to dis- ambiguate the connections. > How does HA know to whom to send traffic it intercepts for MN's HoA when > the CoA is NAT's public address and there's no port number saved? The statement that there's no port number used is incorrect. > And existing IPv6 bootstrapping work when CoA is IPv4 and not IPv6? > > Or is this something new to work upon? Probably > And finally, what do you guys have against MN having a real IPv6 CoA > when behind NAT? What would that break? Wouldn't software reusability > be good? 3775, 3776 and bootstrapping work work unmodified. If you want that functionality, define an extension for it. I don't see any reason to fake an IPv6 CoA when the active CoA is IPv4. Henrik _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 28 18:51:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZboK-0005fZ-Fl; Fri, 28 Apr 2006 18:51:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZboJ-0005fU-D2 for mip6@ietf.org; Fri, 28 Apr 2006 18:51:39 -0400 Received: from av8-1-sn3.vrr.skanova.net ([81.228.9.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZboH-0002es-Vd for mip6@ietf.org; Fri, 28 Apr 2006 18:51:39 -0400 Received: by av8-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 3C641381A8; Sat, 29 Apr 2006 00:51:37 +0200 (CEST) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av8-1-sn3.vrr.skanova.net (Postfix) with ESMTP id ED6C637EBF; Sat, 29 Apr 2006 00:51:36 +0200 (CEST) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 96A4B37E42; Sat, 29 Apr 2006 00:51:36 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.61) (envelope-from ) id 1FZboF-0006kw-4x; Sat, 29 Apr 2006 00:51:35 +0200 Message-ID: <44529C76.1060007@levkowetz.com> Date: Sat, 29 Apr 2006 00:51:34 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.2 (Macintosh/20060308) MIME-Version: 1.0 To: Alexandru Petrescu References: <1487A357FD2ED544B8AD29E528FF9DF002555F05@NAEX06.na.qualcomm.com> <44527AA1.8000501@motorola.com> In-Reply-To: <44527AA1.8000501@motorola.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: "Zhang, Qiang \[NTK\]" , Ryuji Wakikawa , "Soliman, Hesham" , mip6@ietf.org Subject: [Mip6] Re: When behind NAT MN should have a real IPv6 CoA not mapped X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi, With great hesitation, I'm afraid that I'll have to state my belief that you're now Trolling, Alexandru ... on 2006-04-28 22:27 Alexandru Petrescu said the following: ... > But if while in the visited network the MN opens a tunnel interface, > would this tunnel be able to have an IPv6 address? I guess yes. Do you > mind me calling it a "CoA"? Can I call it a "NAT IPv6 CoA"? > > Otherwise, if the "visited network" is actually the tunnel link, can I > still say that the IPv6 CoA of the MN when the tunnel link is up is a CoA? > > Otherwise, "visited network" isn't in 3753 "mobility related > terminology", and neither in the Definitions of 3775, although used > there extensively. > > But let's not blindly abide some definitions here. Technically speaking > what wrong do you see with a NAT IPv6 CoA? What would it break? What > software re-use would make it impossible? > >> Therefore, the draft doesn't talk about getting an IPv6 CoA when the >> MN is in an IPv4 network. > > Oh, I see. Maybe it should, because otherwise the DS-MIPv6 draft should > talk about decrementing some TTL when encapsulating. It currently doesn't. > >>> Wouldn't software reusability be good? 3775, 3776 and >>> bootstrapping work work unmodified. >> >> => What does bootstrapping and 3775/6 have to do with stateless >> autoconfig (defined in 2462)? Nothing... > > Well, from implementation again, if the first thing one does is to have > stateless auto-config (i.e. have a real IPv6 CoA) running on the UDP > tunnel, then bootstrapping would work unmodified, 3776 too. Otherwise I > wonder how 3776 would work with IPv4 Care-of Addresses, especially when > there is no real IPv6 Care-of Address, especially when the IPv4 CoA > behind NAT, so an IPv4 address is common to two nodes. > > Alex > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 28 19:04:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZc0M-0005PA-LB; Fri, 28 Apr 2006 19:04:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZc0L-0005P5-PH for mip6@ietf.org; Fri, 28 Apr 2006 19:04:05 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZc0K-0003Fv-H1 for mip6@ietf.org; Fri, 28 Apr 2006 19:04:05 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3SNKlKe011594; Fri, 28 Apr 2006 16:20:47 -0700 (MST) Received: from [10.169.4.42] (mvp-10-169-4-42.corp.mot.com [10.169.4.42]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k3SNKuID006880; Fri, 28 Apr 2006 18:20:57 -0500 (CDT) Message-ID: <44529F57.2010900@motorola.com> Date: Sat, 29 Apr 2006 01:03:51 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Henrik Levkowetz References: <1487A357FD2ED544B8AD29E528FF9DF002555F05@NAEX06.na.qualcomm.com> <44527AA1.8000501@motorola.com> <44529C76.1060007@levkowetz.com> In-Reply-To: <44529C76.1060007@levkowetz.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: "Zhang, Qiang \[NTK\]" , Ryuji Wakikawa , "Soliman, Hesham" , mip6@ietf.org Subject: [Mip6] Re: When behind NAT MN should have a real IPv6 CoA not mapped X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Henrik Levkowetz wrote: > Hi, > > With great hesitation, I'm afraid that I'll have to state my belief > that you're now Trolling, Alexandru ... Sorry, none of my intentions to troll. I can state with sufficient confidence that when MN behind NAT it gets an IPv4 private address, and uses the NAT's public IPv4 address to open UDP tunnels to the HA (that I call a GW). With this setup, the MN can arrange itself a publicly routable IPv6 address, configured right on its UDP tunnel interface. You're calling me trolling because I call that a "IPv6 CoA on MN behind NAT". I hope not. With all due respect, I refrain on this topic of calling it so. Alex > > on 2006-04-28 22:27 Alexandru Petrescu said the following: ... >> But if while in the visited network the MN opens a tunnel >> interface, would this tunnel be able to have an IPv6 address? I >> guess yes. Do you mind me calling it a "CoA"? Can I call it a >> "NAT IPv6 CoA"? >> >> Otherwise, if the "visited network" is actually the tunnel link, >> can I still say that the IPv6 CoA of the MN when the tunnel link is >> up is a CoA? >> >> Otherwise, "visited network" isn't in 3753 "mobility related >> terminology", and neither in the Definitions of 3775, although used >> there extensively. >> >> But let's not blindly abide some definitions here. Technically >> speaking what wrong do you see with a NAT IPv6 CoA? What would it >> break? What software re-use would make it impossible? >> >>> Therefore, the draft doesn't talk about getting an IPv6 CoA when >>> the MN is in an IPv4 network. >> Oh, I see. Maybe it should, because otherwise the DS-MIPv6 draft >> should talk about decrementing some TTL when encapsulating. It >> currently doesn't. >> >>>> Wouldn't software reusability be good? 3775, 3776 and >>>> bootstrapping work work unmodified. >>> => What does bootstrapping and 3775/6 have to do with stateless >>> autoconfig (defined in 2462)? Nothing... >> Well, from implementation again, if the first thing one does is to >> have stateless auto-config (i.e. have a real IPv6 CoA) running on >> the UDP tunnel, then bootstrapping would work unmodified, 3776 too. >> Otherwise I wonder how 3776 would work with IPv4 Care-of Addresses, >> especially when there is no real IPv6 Care-of Address, especially >> when the IPv4 CoA behind NAT, so an IPv4 address is common to two >> nodes. >> >> Alex >> _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 28 19:24:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZcJo-0007mw-LT; Fri, 28 Apr 2006 19:24:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZcJn-0007mr-Rf for mip6@ietf.org; Fri, 28 Apr 2006 19:24:11 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZcJn-0004sJ-Cx for mip6@ietf.org; Fri, 28 Apr 2006 19:24:11 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id k3SNkNZu009702; Fri, 28 Apr 2006 16:46:23 -0700 (MST) Received: from [10.169.4.42] (mvp-10-169-4-42.corp.mot.com [10.169.4.42]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id k3SNeo1T009610; Fri, 28 Apr 2006 18:40:51 -0500 (CDT) Message-ID: <4452A40F.9080409@motorola.com> Date: Sat, 29 Apr 2006 01:23:59 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Henrik Levkowetz References: <1487A357FD2ED544B8AD29E528FF9DF0024F2419@NAEX06.na.qualcomm.com> <44513C22.9090706@motorola.com> <445244F0.4010905@motorola.com> <44524D69.6080709@levkowetz.com> <44525415.3050103@motorola.com> <445262C7.6050603@levkowetz.com> <44526F9E.70709@motorola.com> <44529BC4.3040609@levkowetz.com> In-Reply-To: <44529BC4.3040609@levkowetz.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: "Zhang, Qiang \[NTK\]" , Ryuji Wakikawa , "Soliman, Hesham" , mip6@ietf.org Subject: [Mip6] Re: When behind NAT MN should have a real IPv6 CoA not mapped (was: Again on port number for DS-MIPv6) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Henrik Levkowetz wrote: >> Indeed, _if_ used appropriately. The way specified doesn't qualify >> as such. > > I believe you're wrong here. Since 3519 is known to work, and this > draft describes an equivalent mechanism, you'll have to be very > specific about what doesn't work. You haven't come close to this > yet. Do you think a DS-MIPv6 section about "Assumptions on NAT for NAT Traversal for DS-MIPv6" would be appropriate? Know that I'm not trying to have my name in the draft. Anybody can write it. Should at least contain "This draft assumes that the NAT leaves open the DS-MIPv6 port number [TBD]". > >>>> the BAck will indeed go back. But if after this BU/BAck >>>> happening, GW/HA wants to send a BRR (to refresh the binding >>>> and the NAT state)? How does the code sending BRR know which >>>> was the port number used by the code who sent BAck? BRR is >>>> triggered by a timer while BAck by reception of a BU. It's not >>>> same code flow. >>> Nonsense. All UDP applications basically work the same way: send >>> the response back to the originators source port. >> We have no UDP "application" here. The "application" is a MIP6 >> implementation which is not a payload type. There's no service >> number assigned to MIP6. Real UDP applications are not preceded by >> IPv6 headers, they are carried by UDP headers. > > As is the IPv6 payload in this case. *DID YOU READ THE DRAFT??????* YEs, I meant IPv6 per se doesn't know to "reply back" to some request, as DHCPv4 carried in UDPv4, or MIP4 carried in MIPv4 know. Not trolling, just read what I'm saying. The protocol carried by IPv6 may know to reply back, but the UDPv4 carrying that IPv6 doesn't know. Cross-layer architectural discussions can happen here, but it's not my intent. >>> I've implemented this for MIPv4 NAT traversal. >> Great. On what deployed NATs have you tried it? > > Oh, I'd guess around n*100 different ones. Do you usually get the > brand and model of a firewall when you visit a hot-spot? No I don't get brand model. I do get though the NAT's public address and the open port numbers through it. I can assure you that each ISP lets out different things. And I can assure you that it's not because IANA says that there should be some port number open that it will. >>> Can you say the same? >> I've implemented NAT traversal using the MIP4 NAT traversal, and >> for MIP6. The keepalive is every second RA and ping from both >> directions. There is UDP virtual interface and there are IPv6 RAs >> on that. The CoA is IPv6, the HoA is IPv6 too. No v4-mapped >> addresses. > > This sounds like an implementation which isn't 3519-compliant at all. Sorry, I did my best. That RFC is an excellent idea. Especially it can be re-used between MIP4 and MIP6. I haven't participated into writing it and still I got the idea from it and implemented it. If the effort of an implementor to write somebody else's doc is recognized with "not correctly done" then I'm sorry. >> I've also successfully tested 6to4 on MN behind some more gentle >> NATs. >> >> Can you say the same? > > Yup. And so you know that having an IPv6 address on MN behind the NAT is not "trolling". >> I did, several times, since earliest versions, discussed >> extensively on the list. If the draft doesn't specify that the >> address MN obtains while behind NAT is a IPv6 Care-of Address from >> the tunnel interface then that's its problem, not mine. > > You don't use an IPv6 CoA when you're in an IPv4 access, whether > behind a NAT or not. Sorry, I don't get it. It's just an IPv6 CoA on some tunnel interface. It's assigned on the MN. IPv6 apps run over it. You don't want me to call it a CoA - fine! But I use it. >> The fact that the draft mentions nothing at all about MN having a >> real IPv6 CoA when behind NAT is none of my faults. > > It doesn't. It seems you haven't understood the basics. Great great, and when I'll implement these basics you'll say it's wrongly implemented. >> The fact that DS-MIPv6 requires MN to support IPv4 Home Addresses, >> but does not permit MN to have a real IPv6 CoA when behind NAT is >> none of my faults either. > > No, but understanding the basics of the mechanism is, I believe, your > responsibiltiy. Henrik, the WG can't impose some users what the WG thinks the user needs. If an IPv6 user on some IPv6 MN is behind a NAT needs an IPv6 address to run his/her IPv6 application, the WG can't tell him/her "no no, use an v4-mapped CoA, it's better". >> Ok, but can MIPv6 MN (3775, 3776) still support an IPv6 Care-of >> Address for this Mobile Node when MN behind NAT, over the UDP >> "tunnel" interface? > > Oh, I'm sure we could arrange for that, but there is no reason to, I > believe. Why not? Having a real IPv6 address on the MN is a godsend for pure IPv6 applications and pure IPv6 DNS. I won't ask you why you think there's no reason because I don't want to troll. >> How does HA know to whom to send traffic it intercepts for MN's HoA >> when the CoA is NAT's public address and there's no port number >> saved? > > The statement that there's no port number used is incorrect. Currently the port numbers aren't in the binding cache. >> And existing IPv6 bootstrapping work when CoA is IPv4 and not IPv6? >> >> >> >> >> >> >> >> >> Or is this something new to work upon? > > Probably Why so if we can get that straight from the start? Current bootstrapping would work unmodified if the MN gets an IPv6 address when behind NAT. >> And finally, what do you guys have against MN having a real IPv6 >> CoA when behind NAT? What would that break? Wouldn't software >> reusability be good? 3775, 3776 and bootstrapping work work >> unmodified. > > If you want that functionality, define an extension for it. I don't > see any reason to fake an IPv6 CoA when the active CoA is IPv4. It's not a "fake IPv6" CoA. It's a real IPv6 address. It's publicly routable on the entire IPv6 Internet. It's distributed to it from the real IPv6 prefix advertised to it by the HA (that I currently call GW). I don't understand what you mean by fake. Anyways. Again, not trolling. Otherwise a bit tired about this discussion. I guess others too. Just take my intention to reuse the UDP tunnel of MIP4 as a good intent, whatever that may mean for you, good or badly implemented. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Apr 29 05:22:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZleM-0002l6-CA; Sat, 29 Apr 2006 05:22:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZleK-0002kt-Kb for mip6@ietf.org; Sat, 29 Apr 2006 05:22:00 -0400 Received: from av6-1-sn3.vrr.skanova.net ([81.228.9.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZleJ-0003Ku-TK for mip6@ietf.org; Sat, 29 Apr 2006 05:22:00 -0400 Received: by av6-1-sn3.vrr.skanova.net (Postfix, from userid 502) id C8F67381E4; Sat, 29 Apr 2006 11:21:58 +0200 (CEST) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av6-1-sn3.vrr.skanova.net (Postfix) with ESMTP id B8940380DE; Sat, 29 Apr 2006 11:21:58 +0200 (CEST) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 7019337E45; Sat, 29 Apr 2006 11:21:57 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.61) (envelope-from ) id 1FZleG-0003WE-SX; Sat, 29 Apr 2006 11:21:56 +0200 Message-ID: <44533034.7070106@levkowetz.com> Date: Sat, 29 Apr 2006 11:21:56 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.2 (Macintosh/20060308) MIME-Version: 1.0 To: Alexandru Petrescu References: <1487A357FD2ED544B8AD29E528FF9DF0024F2419@NAEX06.na.qualcomm.com> <44513C22.9090706@motorola.com> <445244F0.4010905@motorola.com> <44524D69.6080709@levkowetz.com> <44525415.3050103@motorola.com> <445262C7.6050603@levkowetz.com> <44526F9E.70709@motorola.com> <44529BC4.3040609@levkowetz.com> <4452A40F.9080409@motorola.com> In-Reply-To: <4452A40F.9080409@motorola.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 Cc: "Zhang, Qiang \[NTK\]" , Ryuji Wakikawa , "Soliman, Hesham" , mip6@ietf.org Subject: [Mip6] Re: When behind NAT MN should have a real IPv6 CoA not mapped (was: Again on port number for DS-MIPv6) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi, on 2006-04-29 01:23 Alexandru Petrescu said the following: > Henrik Levkowetz wrote: > >>> Indeed, _if_ used appropriately. The way specified doesn't qualify >>> as such. >> >> I believe you're wrong here. Since 3519 is known to work, and this >> draft describes an equivalent mechanism, you'll have to be very >> specific about what doesn't work. You haven't come close to this >> yet. > > Do you think a DS-MIPv6 section about "Assumptions on NAT for NAT > Traversal for DS-MIPv6" would be appropriate? Know that I'm not trying > to have my name in the draft. Anybody can write it. Should at least > contain "This draft assumes that the NAT leaves open the DS-MIPv6 port > number [TBD]". No. That's not even a NAT functionality you're talking about, it's a firewall functionality. >> >>>>> the BAck will indeed go back. But if after this BU/BAck >>>>> happening, GW/HA wants to send a BRR (to refresh the binding >>>>> and the NAT state)? How does the code sending BRR know which >>>>> was the port number used by the code who sent BAck? BRR is >>>>> triggered by a timer while BAck by reception of a BU. It's not >>>>> same code flow. >>>> Nonsense. All UDP applications basically work the same way: send >>>> the response back to the originators source port. >>> We have no UDP "application" here. The "application" is a MIP6 >>> implementation which is not a payload type. There's no service >>> number assigned to MIP6. Real UDP applications are not preceded by >>> IPv6 headers, they are carried by UDP headers. >> >> As is the IPv6 payload in this case. *DID YOU READ THE DRAFT??????* > > YEs, I meant IPv6 per se doesn't know to "reply back" to some request, > as DHCPv4 carried in UDPv4, or MIP4 carried in MIPv4 know. Not > trolling, just read what I'm saying. So there's a UDP encapsulation which is handled by the MIPv6 client and the MIPv6 HA. The IPv6 stack only sees the packet after this has been removed, so shouldn't care and doesn't have to know. > The protocol carried by IPv6 may know to reply back, but the UDPv4 > carrying that IPv6 doesn't know. Cross-layer architectural discussions > can happen here, but it's not my intent. > >>>> I've implemented this for MIPv4 NAT traversal. >>> Great. On what deployed NATs have you tried it? >> >> Oh, I'd guess around n*100 different ones. Do you usually get the >> brand and model of a firewall when you visit a hot-spot? > > No I don't get brand model. I do get though the NAT's public address > and the open port numbers through it. I can assure you that each ISP > lets out different things. And I can assure you that it's not because > IANA says that there should be some port number open that it will. > >>>> Can you say the same? >>> I've implemented NAT traversal using the MIP4 NAT traversal, and >>> for MIP6. The keepalive is every second RA and ping from both >>> directions. There is UDP virtual interface and there are IPv6 RAs >>> on that. The CoA is IPv6, the HoA is IPv6 too. No v4-mapped >>> addresses. >> >> This sounds like an implementation which isn't 3519-compliant at all. > > Sorry, I did my best. That RFC is an excellent idea. Especially it can > be re-used between MIP4 and MIP6. I haven't participated into writing > it and still I got the idea from it and implemented it. If the effort > of an implementor to write somebody else's doc is recognized with "not > correctly done" then I'm sorry. ??? "The keepalive is every second RA and ping from both directions" is very far from what's described in 3519. >>> I've also successfully tested 6to4 on MN behind some more gentle >>> NATs. >>> >>> Can you say the same? >> >> Yup. > > And so you know that having an IPv6 address on MN behind the NAT is not > "trolling". No, but it has nothing to do with the current MIPv6 over IPv4 mechanism. >>> I did, several times, since earliest versions, discussed >>> extensively on the list. If the draft doesn't specify that the >>> address MN obtains while behind NAT is a IPv6 Care-of Address from >>> the tunnel interface then that's its problem, not mine. >> >> You don't use an IPv6 CoA when you're in an IPv4 access, whether >> behind a NAT or not. > > Sorry, I don't get it. It's just an IPv6 CoA on some tunnel interface. > It's assigned on the MN. IPv6 apps run over it. You don't want me to > call it a CoA - fine! But I use it. Terminology is important. It's what makes a sane discussion possible. A MIP CoA is a very specific thing, and if you use it about something else, no wonder people get confused. >>> The fact that the draft mentions nothing at all about MN having a >>> real IPv6 CoA when behind NAT is none of my faults. >> >> It doesn't. It seems you haven't understood the basics. > > Great great, and when I'll implement these basics you'll say it's > wrongly implemented. When you say things that doesn't match my understanding and what's in the draft, what do you expect me to do?? Just say 'Yes, master' and let you go on believing something which to me seems incorrect? I say that it seems you haven't understood the basics because that's the way it seems to me, from what you're saying, *not* to insult you. When the MN acquires an IPv4 address in an IPv4-only network and uses that as a MIPv6 CoA, there is **no** IPv6 CoA involved anywhere. >>> The fact that DS-MIPv6 requires MN to support IPv4 Home Addresses, >>> but does not permit MN to have a real IPv6 CoA when behind NAT is >>> none of my faults either. >> >> No, but understanding the basics of the mechanism is, I believe, your >> responsibiltiy. > > Henrik, the WG can't impose some users what the WG thinks the user > needs. If an IPv6 user on some IPv6 MN is behind a NAT needs an IPv6 > address to run his/her IPv6 application, the WG can't tell him/her "no > no, use an v4-mapped CoA, it's better". An application on a MN running MIPv6 sees the MN's IPv6 home address, (HoA) and shouldn't care whether MIPv6 uses an IPv4 CoA to transport the app's IPv6 traffic to the HA. It now seems to me (and I'm saying this because it's just what it here seems like, no other reason) that you're saying 'CoA' when you are referring to the address the applications see. But that is the MN's HoA, nothing else. >>> Ok, but can MIPv6 MN (3775, 3776) still support an IPv6 Care-of >>> Address for this Mobile Node when MN behind NAT, over the UDP >>> "tunnel" interface? >> >> Oh, I'm sure we could arrange for that, but there is no reason to, I >> believe. > > Why not? Having a real IPv6 address on the MN is a godsend for pure > IPv6 applications and pure IPv6 DNS. I won't ask you why you think > there's no reason because I don't want to troll. Because the apps use the IPv6 HoA provided by MIPv6! >>> How does HA know to whom to send traffic it intercepts for MN's HoA >>> when the CoA is NAT's public address and there's no port number >>> saved? >> >> The statement that there's no port number used is incorrect. > > Currently the port numbers aren't in the binding cache. I don't care where you put them in your implementation. They have to be known and remembered. >>> And existing IPv6 bootstrapping work when CoA is IPv4 and not IPv6? >>> >>> >>> >>> >>> >>> >>> >>> >>> Or is this something new to work upon? >> >> Probably > > Why so if we can get that straight from the start? Current > bootstrapping would work unmodified if the MN gets an IPv6 address when > behind NAT. ??? If the MN is in an IPv4 only network, that seems a bit weird. Are you proposing that we set up a 6to4 tunnel so we can get a MIPv6 address which we can use as a CoA? That approach has been discussed, but has much higher overhead than the current proposal. See http://tools.ietf.org/html/draft-larsson-v6ops-mip-scenarios-01 >>> And finally, what do you guys have against MN having a real IPv6 >>> CoA when behind NAT? What would that break? Wouldn't software >>> reusability be good? 3775, 3776 and bootstrapping work work >>> unmodified. >> >> If you want that functionality, define an extension for it. I don't >> see any reason to fake an IPv6 CoA when the active CoA is IPv4. > > It's not a "fake IPv6" CoA. It's a real IPv6 address. It's publicly > routable on the entire IPv6 Internet. It's distributed to it from the > real IPv6 prefix advertised to it by the HA (that I currently call GW). Seems to me you're talking about the HoA, then. The whole purpose of the current draft is to provide an IPv6 HoA by means of MIPv6. But if you insist on calling the HA by the name of 'GW', and calling the HoA by the name of 'CoA', then it is very hard to communicate. > I don't understand what you mean by fake. > > Anyways. > > Again, not trolling. Otherwise a bit tired about this discussion. I > guess others too. Just take my intention to reuse the UDP tunnel of > MIP4 as a good intent, whatever that may mean for you, good or badly > implemented. Oh, I'm not overjoyed about this thread either, thank you. Especially if it turns out that the main cause of confusion is using the wrong terminology. Henrik _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Apr 30 08:19:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaAtU-0006tU-75; Sun, 30 Apr 2006 08:19:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaAtS-0006r9-KH for mip6@ietf.org; Sun, 30 Apr 2006 08:19:18 -0400 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaAtR-0000AL-7b for mip6@ietf.org; Sun, 30 Apr 2006 08:19:18 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.10.03) with ESMTP id k3UCJ4vu028055; Sun, 30 Apr 2006 14:19:04 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [192.44.77.29]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.09.01) with ESMTP id k3UCIxL4028050; Sun, 30 Apr 2006 14:18:59 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id k3UCIv0H023189; Sun, 30 Apr 2006 14:18:58 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200604301218.k3UCIv0H023189@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Soliman, Hesham" Subject: Re: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt In-reply-to: Your message of Fri, 28 Apr 2006 14:07:09 PDT. <1487A357FD2ED544B8AD29E528FF9DF002555FD6@NAEX06.na.qualcomm.com> Date: Sun, 30 Apr 2006 14:18:57 +0200 X-Virus-Scanned: amavisd-new at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Gopal Dommety , mip6@ietf.org, jari.arkko@ericsson.com, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org In your previous mail you wrote: > => I consider the HAO as a degenerated tunnel so you have double > tunneling (one tunnel for IPsec, one for MIPv6) when obviously only > one is needed. => Understood. I do think this is a matter of taste though not architecture. => yes, it is a matter of taste about an architectural view of things... > I think > it's a more "correct" use of IPsec to not use tunnel mode > between two end nodes. > > => but is the right end the HA or the CN (:-)? => It's always the HA as far as IPsec is concernced. In some cases the messages are processed by the HA (BU, MPD), in others the HA is treated like a security GW (HOTI, payload). So as far as IPsec is concerned the end node is always the HA. The fact that the packet is then forwarded somewhere else is irrelevant to IPsec. => for IPsec the transport mode is strictly end-to-end so either the real end node is the CN and tunnel mode is required, or the tunnel between MN-HA and the forwarding to/from CN is part of the "MIPv6 application" and my concern about double tunneling is more important. BTW the term SG (security gateway) implies tunnel mode. Regards Francis.Dupont@point6.net _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Apr 30 14:12:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaGPE-0005R7-Pu; Sun, 30 Apr 2006 14:12:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaGPC-0005R2-Vq for mip6@ietf.org; Sun, 30 Apr 2006 14:12:26 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaGPB-0005JD-JW for mip6@ietf.org; Sun, 30 Apr 2006 14:12:26 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3UICHDl007842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 30 Apr 2006 11:12:18 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3UICFwT027864; Sun, 30 Apr 2006 11:12:16 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 30 Apr 2006 11:12:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt Date: Sun, 30 Apr 2006 11:12:13 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF00255622A@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt Thread-Index: AcZsUFxYG0huZO1TT3+g+cEpg5Sd/wAMG+BQ From: "Soliman, Hesham" To: X-OriginalArrivalTime: 30 Apr 2006 18:12:15.0383 (UTC) FILETIME=[9C335A70:01C66C81] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Gopal Dommety , mip6@ietf.org, jari.arkko@ericsson.com, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org =20 > =3D> for IPsec the transport mode is strictly end-to-end so either > the real end node is the CN and tunnel mode is required, or the > tunnel between MN-HA and the forwarding to/from CN is part of the > "MIPv6 application"=20 =3D> Ok. So at least there is one agreement here, that is, for the=20 "MIPv6 application" transport mode makes sense since the communication is between MN and HA. Also, there is no double tunneling since there is=20 only one header in this case and the HAO. There would be unnecessary tunnelling IMO in tunnel mode for the BU or MPD. and my concern about double tunneling is more > important. BTW the term SG (security gateway) implies tunnel mode. > =20 =3D> Ok. So we don't agree about the utility of transport mode in this=20 scenario. I'm fine with doing what we agree on and leaving the SGW case out. Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Apr 30 16:30:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaIYq-0007f6-L0; Sun, 30 Apr 2006 16:30:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaIYo-0007f1-Ox for mip6@ietf.org; Sun, 30 Apr 2006 16:30:30 -0400 Received: from nproxy.gmail.com ([64.233.182.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaIYo-0003Ae-DA for mip6@ietf.org; Sun, 30 Apr 2006 16:30:30 -0400 Received: by nproxy.gmail.com with SMTP id l36so1744526nfa for ; Sun, 30 Apr 2006 13:30:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=OTSNGRXgzQtMWS1eWWTMG++Nqu9ezdNdjRxMBHl4dgiFiGkQViw1ycEUcuuFS3nmtZxRp245sv3qEiqyigRG5xR9UKd1z7rb/HQwqadGD2WJWNuBoKHE3rm4+/hptgwHEhZBlY4/tuSaNiA9sCfXwKTu2Xe7VIwSBdPPAzwtDTA= Received: by 10.49.71.14 with SMTP id y14mr122573nfk; Sun, 30 Apr 2006 13:30:29 -0700 (PDT) Received: by 10.49.40.20 with HTTP; Sun, 30 Apr 2006 13:30:29 -0700 (PDT) Message-ID: Date: Sun, 30 Apr 2006 22:30:29 +0200 From: "Gerardo Giaretta" To: mip6@ietf.org Subject: RE: [Mip6] FW: DISCUSS and COMMENT: draft-ietf-mip6-bootstrap-ps MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Sam, thanks for the comments and sorry for very late answers. Concerning the EAP issue, I think that both solutions that are under definition in the WG does not follow the directions you mentioned. After your and others' comments (also during ICOS BOF and HOAKEY BOF) the WG has been producing solutions where network access authentication and mobility service authentication are considered fully separated. It seems to me that this problem statement does not suggest this kind of solutions. Please let me know if you think some clarifying text needs to be added to this problem statement. Concerning rfc4285, the WG is currently not working on a solutions for bootstrapping rfc4285 SAs. I'm OK with removing all references to rfc4285. Is this your suggestion? > Comment: > The claim in section 5.2.1 that use of certificates would require > deploying a PKI is false. I do agree that certificates do not align > well with AAA. I'd recommend rewording as "Certificates are not easily > supported by traditional AAA infrastructures." > Done. --Gerardo > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com] > Sent: mercoled=EC 1 marzo 2006 22.16 > To: mip6@ietf.org > Subject: [Mip6] FW: DISCUSS and COMMENT: draft-ietf-mip6-bootstrap-ps > > > FYI, > > ------ Forwarded Message > > From: ext Sam Hartman > > Date: Wed, 01 Mar 2006 16:03:22 -0500 > > To: > > Cc: , > > Subject: DISCUSS and COMMENT: draft-ietf-mip6-bootstrap-ps > > > > Discuss: > > First, thanks for a good job on a well written problem > statement. My > > concerns here are concernes about the document but can be > interpreted > > as early warnings about the direction the WG seems to be taking. > > Addressing the concerns against the document can probably > be done very > > simply, but it is important to discuss the working group's direction > > now to make sure that you will not end up with a discuss challenging > > something fundamental about your solution when it comes to the IESG. > > > > In section 7.2 you discuss using the authentication to both set up > > network access and mobility access. I don't think this is > compatible > > with how the EAP working group and security area invision EAP being > > used. For example the key management framework requires > that all keys > > based on the EMSK be generated at the beginning of the > exchange. We've > > explicitly resisted several attempts to use EAP keying information > > used to set up network access to later generate keys for other > > purposes. Both mobility and network access are at least valid EAP > > applications. I recommend that you note that the question > of whether > > this authentication can be reused is open in your document. I > > recommend that you get together with Russ Housley, Jari, > myself and the EAP > > community and decide whether this use is OK before designing a > > solution that assumes you will be able to do this. > > > > I'm assuming that this problem statement is for a standards track > > solution. As such, I don't think considering RFC 4285 is > appropriate. > > In particular I don't think it makes sense for us to base standards > > trackrequirements on a protocol we were unwilling to > standardize. It > > feels too much like using the informational RFC series as a > mechanism > > for doing ongoing standards work without meeting our > requirements for > > review. If the working group believes that something like > RFC 4285 is > > needed, then the working group should commit to doing the necessary > > work to make a standard in this space: write a service model for > > Mobile IP security and then write both the authentication > protocol and > > the IPsec security solution as architectural blocks that fit that > > model. If the working group does not want to do this work, then RFC > > 4285-like solutions need not influence requirements here. > > > > Comment: > > The claim in section 5.2.1 that use of certificates would require > > deploying a PKI is false. I do agree that certificates do not align > > well with AAA. I'd recommend rewording as "Certificates are > not easily > > supported by traditional AAA infrastructures." > > > > ------ End of Forwarded Message > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Apr 30 16:31:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaIZe-0007jH-1q; Sun, 30 Apr 2006 16:31:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaIZc-0007im-Ui for mip6@ietf.org; Sun, 30 Apr 2006 16:31:20 -0400 Received: from nproxy.gmail.com ([64.233.182.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaIZb-0003GL-KP for mip6@ietf.org; Sun, 30 Apr 2006 16:31:20 -0400 Received: by nproxy.gmail.com with SMTP id l36so1744593nfa for ; Sun, 30 Apr 2006 13:31:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=heT3yz6YOhCFHCdu8GBVRVfezdeC9ZxDceINbduRelUS5zQrX42Yq53SzC4g/DCT2ezjoGoqgDAueBcezOsxHtv5rdmsiLIGuejK8NzgVvO2id0kDMVY1wP/GJeNCJ6W/Qj3TMGKBmAK7XUmUchRYPmUJT6mNRxITEUoXCHtFhU= Received: by 10.48.203.8 with SMTP id a8mr129735nfg; Sun, 30 Apr 2006 13:31:19 -0700 (PDT) Received: by 10.49.40.20 with HTTP; Sun, 30 Apr 2006 13:31:19 -0700 (PDT) Message-ID: Date: Sun, 30 Apr 2006 22:31:19 +0200 From: "Gerardo Giaretta" To: mip6@ietf.org Subject: RE: [Mip6] FW: COMMENT: draft-ietf-mip6-bootstrap-ps MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Sorry for late comments on this. All editorial changes proposed have been fixed in the new version (will be available very soon). Below the answers to some detailed comments: - s3, 1st bullet: If boostrapping creates an IKE pre-shared secret, isn't that enough to be able to create the SA between HA and MN? Do you need both? Or does it depend on whether RFC4285 is being used or not? IKE pre-shared key is enough if IPsec is used between MN and HA. If rfc4285 is used, some dedicated keys may be needed. This is still not covered by current RFCs and I-Ds and let open in this document. - s5.2.1: Is the phrase 'traditional AAA infrastructure' sufficiently well-understood? I think it may need a few hints as what is traditional will change over time! I would rephrase as the following: " Where an AAA scheme based on RADIUS or Diameter protocols is used, the home agent is not able to leverage authentication and authorization information established between the mobile node, the foreign AAA server, and the home AAA server." - s5.2.2: I would have thought this section belong with 5.1 (addressing) rather then 5.2 (security infrastructure). Right, moved to 5.1 Thx, --Gerardo > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com] > Sent: mercoled=EC 1 marzo 2006 14.56 > To: mip6@ietf.org > Subject: [Mip6] FW: COMMENT: draft-ietf-mip6-bootstrap-ps > > > Gen-ART review: > > ------ Forwarded Message > > From: ext Brian Carpenter > > Date: Wed, 01 Mar 2006 05:48:24 -0500 > > To: > > Cc: , > > Subject: COMMENT: draft-ietf-mip6-bootstrap-ps > > > > Comment: > > From Gen-ART review by Elwyn Davies: > > > > ..There are a small number of very minor issues and > questions plus a fair > > number of editorial nits... > > > > The detailed review with these points is posted at > > > http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-mip6-boot strap-ps-04-davi > > es.txt > > > > ------ End of Forwarded Message > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6