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

[Gerardo Giaretta <[e-mail]>]

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
[e-mail]. Thank you
====================================================================

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