Subject: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-split-01 - Comments

From: "Narayanan Vidya-CVN065" <[email-masked]>
Date: Wed, 30 Nov 2005 01:31:56 -0500

Gerardo, all,
Sorry for such a long delay in sending these comments. I have a few comments on the draft: 

Technical: 

1. Currently, the draft proposes a proxy DAD procedure by the HA upon receiving the BU (section 5.3.1.) - would it not make sense to do this upon receiving the autoconfigured address in IKEv2 first? When the HA performs the check to ensure that the address is valid, it could do a proxy DAD and if it fails, propose a different address in the INTERNAL_IP6_ADDRESS attribute. This would avoid having to create a child SA after receiving a negative BAck due to DAD failure. Is this present just to be in line with RFC3775? 

2. Regarding the DNS update, I share some of the concerns that Francis has expressed. Typically, the DDNS updates are tied to address allocation. By having the HA do the DNS updates, this is somewhat violated. The security considerations section has some text about FQDN authorization, but I am not sure it covers it all. The draft really says that authorization of the FQDN MUST be done, but the method of authorization is outside the scope of the draft - given the latter, I don't know that a "MUST" for authorization makes sense. Section 6 is also somewhat vague on the procedure itself - it talks about the AAA doing the DNS update when the MSA's DNS must be updated. However, what if the MN used certs and there was no AAA? Either the draft should be providing a clear solution or leave this out. Or, have an appendix that talks about possible ways of doing DNS updates. If we want to standardize this, I think this will need more work. 

3. Also on the DNS topic, section 6 gets into removing stale DNS entries and so on. The presence of this detail seems to be a direct consequence of the fact that this draft attempts to address DNS updates in the first place. Ongoing DNS updates/maintanence/removal etc have nothing to do with bootstrapping itself. So, I would vote for not having this detail as part of this draft. 

Editorial:

1. In figures 3 & 4, the last message (from HA to MN) should be BAck (not BU). 

Thanks,
Vidya

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Gerardo Giaretta
> Sent: Thursday, November 24, 2005 8:52 AM
> To: [email-masked]
> Subject: Reminder -- [Mip6] WGLC: 
> draft-ietf-mip6-bootstrapping-split-01(Deadline is Nov 30, 05)
> 
> Hi all,
> 
> no comments have been sent so far on 
> draft-ietf-mip6-bootstrapping-split-01. 
> Please review the draft and provide your feedback. The 
> deadline is November 30th 2005.
> 
> Thanks,
> --Gerardo 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > Of Basavaraj Patil
> > Sent: venerdì 4 novembre 2005 21.15
> > To: [email-masked]
> > Subject: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-split-01
> > (Deadline is Nov 30, 05)
> > 
> > 
> > 
> > Hello,
> > 
> > This is a Working Group last call for the following I-D:
> > I-D :draft-ietf-mip6-bootstrapping-split-01
> > Title: Mobile IPv6 bootstrapping in split scenario
> > 
> > The status associated with this I-D is : Standards track
> > 
> > Please review and post your comments by November 30th, 2005.
> > 
> > -Chairs
> > 
> > URL to I-D:
> > http://ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-
> > split-01.txt
> > 
> > 
> > _______________________________________________
> > Mip6 mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/mip6
> > 
> 
> 
> Gruppo Telecom Italia - Direzione e coordinamento di Telecom 
> Italia S.p.A.
> 
> ====================================================================
> 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 send an e_mail to 
> [email-masked]. Thank you 
> ====================================================================
> 
> _______________________________________________
> Mip6 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mip6
> 

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Francis Dupont <[email-masked]>
Date: Wed, 30 Nov 2005 11:53:55 +0100

In your previous mail you wrote:

   Technical: 
   
   1. Currently, the draft proposes a proxy DAD procedure by the HA
  upon receiving the BU (section 5.3.1.) - would it not make sense to do
  this upon receiving the autoconfigured address in IKEv2 first? When
  the HA performs the check to ensure that the address is valid, it
  could do a proxy DAD and if it fails, propose a different address in
  the INTERNAL_IP6_ADDRESS attribute. This would avoid having to create
  a child SA after receiving a negative BAck due to DAD failure. Is this
  present just to be in line with RFC3775?
   
=> IMHO we should follow exactly what should be done for DHCPv6, i.e.,
if the DHCPv6 server has to perform the check we put it in IKEv2,
if the client has to perform the check (there is a discussion about this
in the DHCPv6 mailing-list but the default was the check is performed
by the client and is mandatory) then the RFC3775 solution has to be
applied. So the only difference for the mobility is the word "proxy".
(the whole idea is not to redo the job of the IPv6/DHCP/DNSEXT/... WGs)

Regards

[email-masked]

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 30 Nov 2005 11:38:57 -0800

> 1. Currently, the draft proposes a proxy DAD procedure by the HA upon receiving the BU (section 5.3.1.) - would it not make sense to do this upon receiving the autoconfigured address in IKEv2 first…

it was done this way to require minimal changes to RFC 3775 and
the IKEv2 implementation on the HA. an IPsec implementation
typically does not perform proxy DAD when allocating an address
and returning it in the CFG_REPLY message.

> 2. Regarding the DNS update, I share some of the concerns that Francis has expressed. Typically, the DDNS updates are tied to address allocation. By having the HA do the DNS updates, this is somewhat violated.

the HA is allocating the address.

> The security considerations section has some text about FQDN authorization, but I am not sure it covers it all. The draft really says that authorization of the FQDN MUST be done, but the method of authorization is outside the scope of the draft - given the latter, I don't know that a "MUST" for authorization makes sense. 

the authorization check is required. cant be skipped. one way
of doing it would be to associate the FQDN presented in the
IKE_AUTH exchange to the home address allocated in the
CFG_REQ/REP exchange and store this state on the HA. later on
when the HA receives the BU and needs to perform a DNS update
it goes and checks this state to see if the HoA is allowed
for the FQDN. there are many ways of doing the auth check. so
it is not specified in detail.

> Section 6 is also somewhat vague on the procedure itself - it talks about the AAA doing the DNS update when the MSA's DNS must be updated. However, what if the MN used certs and there was no AAA? Either the draft should be providing a clear solution or leave this out. Or, have an appendix that talks about possible ways of doing DNS updates. If we want to standardize this, I think this will need more work. 

certificates are typically used only to authenticate the mobile
node. to check if the mobile node is authorized for a particular
service, AAA (or something similar) might still be needed.

> 3. Also on the DNS topic, section 6 gets into removing stale DNS entries and so on. The presence of this detail seems to be a direct consequence of the fact that this draft attempts to address DNS…

its about the MN rebooting and forgetting that it had the HA
create the DNS entry. just a cleanup once in a while.

Vijay

---

From: Francis Dupont <[email-masked]>
Date: Thu, 01 Dec 2005 00:48:30 +0100

=> IMHO an IKEv2 implementation should perform a proxy DAD when it
allocates an address before returning it as it should provide
a proxy NDP service (i.e., reply to NS by not-overriding NA).
Both should be configurable with by default being on.
Now what to do for the mobility case: if the MN can come back to home
(and by default it can) both functions should be delegated to
the mobility code. So in fact an IKEv2 implementation on the HA
should use a dedicated and simpler default policy...
Note as the home address is not allocated for a tunnel mode SA
the IPsec implementation can easily recognize this special case
(i.e., one has not to say to the IKEv2 daemon it is used for
HA or not).

   the authorization check is required. cant be skipped.

=> show us where this authorization for the address is required
or even mentioned in RFC 2136, PLEASE!

Regards

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 30 Nov 2005 16:24:35 -0800

> Both should be configurable with by default being on.

okay, but I dont think we should mandate the IKEv2 implementation
to do proxy DAD.

> or even mentioned in RFC 2136, PLEASE!

in the security considerations section we have the following.

    This
    choice was motivated by a concern for preventing redirection-based
    flooding attacks (see draft-ietf-mip6-ro-sec [19] for more
    information about redirection-based flooding attacks and the role
    preventing them played in the design of Mobile IPv6 route
    optimization security). Exactly as for route optimization, it is
    possible for a node that is the legitimate owner of a DNS FQDN -
    in the sense that it has a security association with the DNS
    server allowing it to perform dynamic DNS update of its FQDN - to
    bind its FQDN to the address of a victim, then redirect large
    volumes of traffic at the victim. The attack may be propagated
    without the owner's knowledge, for example, if the node is
    compromised by malware, or it may be intentional if the node
    itself is the attacker.

if RFC 2136 ignored this, I cant help it.

Vijay