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

From: Gerardo Giaretta <[email-masked]>
Date: Thu, 01 Dec 2005 11:37:02 +0100

Hi Vidya,

thanks for your review. Some comments inline..

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

what kind of text would you suggest?

As mentioned by Vijay, the choice was done to require minimal changes to RFC3775. I think that, whatever bootstrapping mechanism is in place, the BU processing should remain the same as specified in RFC 3775 (modulo new options). This implies that if there is no entry in the BC, the HA MUST perform Proxy DAD when creating a new entry.

I also àgree with Vijay that we should not mandate that any IKEv2 implementation performs proxy DAD.
 
> 
> > > 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. 
> 

This is true. 

History: the DT thought that a DNS update is needed for a full IP reachability service. Initially we thought that the MN should do the DDNS update, but then an address (and FQDN) ownership issue was raised, as discussed in Security Considerations. So we came up with the solution that the HA performs the DDNS update since the authorization issue can be solved via AAA. I think this is still a good approach since it requires modifications only to HA and let the MN to request the DNS update as an optional feature.

Having said that, are you against a DDNS solution in this draft (i.e. out of scope) or against the specific solution defined? 

> > 
> > > 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" :) 
> 

DT agreed that authorization is a MUST. From security considerations section (as highlighted previously by Vijay):

    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.

The draft is not mandating an authorization check solution; as you mention it is quite vague. Probably subsequent AAA documents will specify a way to perform this check.

> > > 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 :)
> 

Are you suggesting to remove it?

--Gerardo

> Vidya

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

---

From: Vidya Narayanan <[email-masked]>
Date: Fri, 2 Dec 2005 19:59:36 -0600

Hi Gerardo,

> what kind of text would you suggest?

I'll take a look at the draft again and see if I can come up with something :)

> As mentioned by Vijay, the choice was done to require minimal changes to
> RFC3775. I think that, whatever bootstrapping mechanism is in place, the BU processing should remain the same as specified in RFC 3775 (modulo new options). This implies that if there is no entry in the BC, the HA MUST perform Proxy DAD when creating a new entry.
>

I think it would make sense to do a proxy DAD when it is assigning the
IP address. I am okay with not mandating this, but I feel the draft
should at least mention it.

> Having said that, are you against a DDNS solution in this draft (i.e. out of scope) or against the specific solution defined?

A bit of both, actually :) I think it would be better if DDNS was left
out from the draft. As for the solution, where the HA assigns the
address, it makes sense to have it do the DNS update. When it is not
the entity assigning the address, I am not comfortable with still
having the HA do the update.

> The draft is not mandating an authorization check solution; as you mention it is quite vague. Probably subsequent AAA documents will specify a way to perform this check.

What does a "MUST" really mean here? How do you know whether an
implementation does this authorization or not? Given that a solution
is not mandated, there is no value for the "MUST" from an
interoperability point of view. Perhaps the security considerations
section should state that it is RECOMMENDED that an authorization be
done - I still fail to see the value of mandating the check. If
subsequent documents were to define a solution, then we can define
some requirements for basic interoperability.

> Are you suggesting to remove it?

If the DNS stuff must remain in the draft, then, perhaps a sentence or
two on the fact that such implementations should also have provisions
for a cleanup would make sense. In general, I do believe it is outside
the scope of the draft.

Vidya

---

From: Francis Dupont <[email-masked]>
Date: Sat, 03 Dec 2005 10:00:38 +0100

In your previous mail you wrote:

=> note your message is in UTF-8 and encoded in base64 (:-)?!

=> it seems we agree about this but we have to find the right way
to present our solution... I propose to use the IKEv2 clarification
document (draft-eronen-ipsec-ikev2-clarifications-XX.txt) to
introduce the issue, i.e., specify the server endpoint should provide
a proxy NDP service, including proxy DAD, for the individual addresses
it allocates, and to specify in the split document that this proxy
NDP service, including proxy DAD, is done by the mobility code in
the mobility case, because the client (i.e., the MN) can move so
can come back to home, a case the mobility code but not IKE is
prepared to handle.

=> fully agree. I am for no more than a mention to this.

   (about the authorization check)
   What does a "MUST" really mean here? How do you know whether an
   implementation does this authorization or not?

=> currently *no* DNS update implementation does this authorization on
both the FQDN and the address: all implementations check only the "name
part" of RRs and trust the updater to put the right "values" into RRs.
And this is both against the current usage and outside the scope of
the WG...

Regards

[email-masked]

---

From: Vidya Narayanan <[email-masked]>
Date: Sun, 4 Dec 2005 10:53:02 -0600

> => note your message is in UTF-8 and encoded in base64 (:-)?!

Ok.. hopefully, that is fixed now :)

> can come back to home, a case the mobility code but not IKE is

That would be okay.

> And this is both against the current usage and outside the scope of

I am not sure that not doing any authorization checks is the right
thing... but, yes, it is not a MIP6 WG thing to fix.

Vidya

---

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

> can come back to home, a case the mobility code but not IKE is

please go ahead and do this. when you get these changes done,
we can deprecate the DNS update feature from the bootstrapping
draft. there will be lot more revisions of the document before
it is final, anyway.

> And this is both against the current usage and outside the scope of

Francis, I call this ignoring the problem rather than finding
a workaround solution to the problem. FWIW, I think it is kind
of important for the DNS server to check if the MN actually
owns the address. otherwise it is too easy to sends a DNS
update for another mobile node's home address.

Vijay

---

From: Francis Dupont <[email-masked]>
Date: Mon, 05 Dec 2005 23:17:33 +0100

please go ahead and do this.

=> I'll contact Pasi.

   when you get these changes done, we can deprecate the DNS update
   feature from the bootstrapping draft. there will be lot more
   revisions of the document before it is final, anyway.
   
=> hum, my proposal was about the proxy NDP... but we can discuss
about DNS update too (IMHO it is a good usage of CFG_SET even I
agree with:
   Extensions via the CP payload SHOULD NOT be used for general purpose
   management.  Its main intent is to provide a bootstrap mechanism to
   exchange information within IPsec from IRAS to IRAC.  While it MAY be
   useful to use such a method to exchange information between some
   Security Gateways (SGW) or small networks, existing management
   protocols such as DHCP [DHCP], RADIUS [RADIUS], SNMP or LDAP [LDAP]
   should be preferred for enterprise management as well as subsequent
   information exchanges.
and of course MPD).

   Francis, I call this ignoring the problem rather than finding
   a workaround solution to the problem.

=> it is not in the scope of the MIP6 WG to deal with this, i.e.,
to decide whether it is a problem and if it is to find a solution.

   FWIW, I think it is kind
   
=> OK, I'll put your mail server address in my DNS which BTW is a DNSSEC.
And I'll see what happens (nothing of course but it is too easy :-).

Regards