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

From: "Narayanan Vidya-CVN065" <[email-masked]>
Date: Thu, 1 Dec 2005 00:43:35 -0500

> 
> 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.
> 

I think it would make sense to do it when allocating the address.
Atleast some text to that extent would make sense to me. 

> > 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.

not when the MN is auto-configuring a HoA. Also, in some cases, the HA
itself may get the IP address for the MN from a DHCP server or AAA
server. 

> 
> > 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.
> 

I don't know what good it brings to have a "MUST" for authorization when
there is no clarity as to what this really means. I agree that there is
more than one way of doing an auth check - and I actually don't think
the draft should mandate one - instead, I think the auth check should be
a "SHOULD", not a "MUST" :) 

> > 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.
> 

I'm not sure we are talking about the same thing here. I wasn't talking
about authorizing the MN for a service. While doing a DNS update, the
only thing needed is to authorize the MN as the owner of the FQDN. And,
certs can contain the FQDN of an entity. 

> > 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. 
> 
> its about the MN rebooting and forgetting that it had the HA 
> create the DNS entry. just a cleanup once in a while.

yes, which is why it is not a bootstrapping problem :)

Vidya

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 01 Dec 2005 11:42:19 -0800

> Atleast some text to that extent would make sense to me. 

I am not keen on having IKEv2 perform proxy DAD for
addresses allocated through the INTERNAL_IP6_ATTRIBUTE.

> not when the MN is auto-configuring a HoA. 

disagree. even when the MN atuo-configures the HoA, the
HA gets to know about it in the subsequent CREATE_CHILD_SA
exchange.

> Also, in some cases, the HA

fine. but the HA still knows which HoA was allocated to
which FQDN.

> certs can contain the FQDN of an entity. 

then I misunderstood your original question. we are not
concerned about the check to see if the MN is the owner
of a particular FQDN. in MIP6 bootstrapping we are
concerned about the authorization step where the DNS
server has to check if the MN with a particular FQDN is
allowed to send a dynamic DNS update for a particular
HoA.

> yes, which is why it is not a bootstrapping problem :)

well, we created the DNS entries. if the MN crashes we
need to do the cleanup.

Vijay

---

From: Francis Dupont <[email-masked]>
Date: Thu, 01 Dec 2005 23:51:39 +0100

In your previous mail you wrote:

=> it should perform proxy DAD when it provides proxy NDP,
so in fact the only clear case when it is not useful is
the MIP6 HA case (when both are done by the mobility code,
not IKE).

   disagree. even when the MN auto-configures the HoA, the
   HA gets to know about it in the subsequent CREATE_CHILD_SA
   exchange.
   
=> here you are talking about IKE, not the mobility code in the HA.
(and of course the HoA will be in the traffic selector for the BU/BA).

=> same, the knowledge is in IKE as soon as the FQDN is in
an ID payload or a certificate (BTW it shall be the case here).

=> in the RFC 2136 & co in the last statement you have only
the particular FQDN for the direct tree and the particular HoA
in the reverse tree. This is why the second is usually done
by the entity which controls the address allocation (which
is never the MN when the address is dynamic).

Regards

[email-masked]

---

From: Vidya Narayanan <[email-masked]>
Date: Fri, 2 Dec 2005 20:15:55 -0600

> addresses allocated through the INTERNAL_IP6_ATTRIBUTE.

That seems like the logical thing to do to me.

> HA gets to know about it in the subsequent CREATE_CHILD_SA

I never said the HA doesn't *know* about the address - only that it
doesn't *allocate* the address in the case of MN auto-configuring a
HoA. The question was about whether it should be the entity allocating
the address that should be performing the DDNS update or can the HA do
it in all cases.

> fine. but the HA still knows which HoA was allocated to

Again, no question about the HA's knowledge of the HoA.

> of a particular FQDN.

Why not? Without this check, a node that knows the FQDN and HoA of
another MN can then perform a DNS update for that MN.

Vidya

> in MIP6 bootstrapping we are

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 05 Dec 2005 11:37:18 -0800

> That seems like the logical thing to do to me.

it doesnt today. no reason to require this.

> the address that should be performing the DDNS update or can the HA do

well, the HA is one that the mobile node is always in
touch with. lets say the mobile node sometime uses
assigned addresses and sometimes home address configured
with RFC 3041. it might want to be reachable at the
assigned home address, but not at the 3041 home address.
the mobile node can now tell the HA update the DNS
with the assigned home address, but not the 3041 home
address. no other entity in the network can enable such
feature. ofcourse the mobile node itself could do these
updates. but we have scalability and address ownership
issues.

> another MN can then perform a DNS update for that MN.

well, then you are questioning RFC 2136 itself.

the problem is simple. when we bootstrap a HoA, the
MN is no longer reachable at the new HoA. so we fix
this by update the DNS entry for the mobile node.
one issue we have is how does the MN prove ownership
of the home address. so we avoid this problem by
having the HA do the update. this assumes that the
DNS server trusts the HA.

Vijay

---

From: Francis Dupont <[email-masked]>
Date: Mon, 05 Dec 2005 22:48:11 +0100

touch with.

=> the "HA" here is ambiguous as it is both the mobility code
and the IPsec code: you mean the first when we (me and Vidya) want
the second.

   of course the mobile node itself could do these
   updates. but we have scalability and address ownership
   issues.
   
=> there is no scalability issue and the address ownership
is a MIP WG home made issue in the scope of another WG...

   
=> BTW IMHO Vidya follows the RFC 2136 but not you...

   of the home address.

=> no, this is not in RFC 2136!

   so we avoid this problem by
   having the HA do the update. this assumes that the
   DNS server trusts the HA.
   
=> the assumption is not always true, the only thing you can assume
is the DNS server trusts the MN for the direct tree, nothing else
even usually the DNS server trusts the entity which controls the
allocation (which is not the mobility code) for the reverse tree
and sometimes for the direct tree too.

Regards

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 05 Dec 2005 13:56:25 -0800

> and the IPsec code: you mean the first when we (me and Vidya) want

okay. the MN is in touch with the mobility code on the
HA always. not IPsec. especially when the authentication
option protocol is used.

> is a MIP WG home made issue in the scope of another WG...

Francis, there is an issue whether it is in the scope of
MIP6 WG or the DNS WG.

> => BTW IMHO Vidya follows the RFC 2136 but not you...

??? Vidya wanted an authorization check on the FQDN itself.
she wanted the DNS server to check if the mobile node owns
the FQDN itself. I am trying to deal with a much smaller
issue of checking whether the MN owns the home address it
is  claiming. I do want to use RFC 2136 for doing the
update. that what we have specified in the bootstrapping
document.

> => no, this is not in RFC 2136!

that *is* the issue. RFC 2136 does not talk about address
ownership. we are getting nowhere, Francis!!

> and sometimes for the direct tree too.

well, the HA can do the update for the direct and reverse
tree.

Vijay

---

From: Francis Dupont <[email-masked]>
Date: Tue, 06 Dec 2005 01:33:16 +0100

HA always. not IPsec.

=> IPsec is mandatory and the split document requires IKEv2
(these are facts).

   especially when the authentication option protocol is used.

=> Not only the authentication option protocol is not mentioned
in any bootstrapping document and there is no proposal about
providing home address allocation using it, so we speak in a void
space...

   
=> I claim that both the issue if it exists is in the scope of
the DNS WG and it is the job of the DNS WG to determine if it
is an issue or not. I can guess the answer will be no...
(BTW there is no DNS WG but a dnsext and a dnsop WGs :-)

=> for the update to the direct tree this makes sense in
the RFC 2136 context.

=> so you confirm you are totally out of phase with the RFC 2136.

   
=> yes, as both a mobility and a DNS person I can see there is
more than a misunderstanding of the DNS here... And the problem
is not about the RFC 2136 but about the DNS itself: the only
notion of ownership in the DNS is about the left/name part of RRs,
i.e., FQDN is the direct tree and reversed addresses in .arpa in
the reverse tree.

   
=> even if I include in "the HA" all the entities running on the HA
this is not always true...

So to summary you'd like to enforce a security property which doesn't
exist in the DNS and you don't provide the required dynamic DNS update
in all cases. It should be hard to more disagree!

Regards

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 05 Dec 2005 18:00:36 -0800

> providing home address allocation using it, so we speak in a void

there will be one soon.

> is an issue or not. I can guess the answer will be no...

again, you insist that there is no issue. meanwhile we
want a solution that works today.

> i.e., FQDN is the direct tree and reversed addresses in .arpa in

FWIW, I think we need a return routability check from
the DNS server to the mobile node. I dont see this
happening in the near fugure. so lets agree to disagree
on this issue.

Vijay