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

[Vidya Narayanan <[e-mail]>]

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

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.

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

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.

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

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.

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

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

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