In your previous mail you wrote:
> - DHCPv6 security doesn't work well in multi-domain environments
> so in the mobility context. Quoting RFC 3118:...
Yes, these are right. But, is there any specifics of the DHCP usage
outlined in this document that relates to the above discussion? Whatever
DHCP security or insecurity exists apply to this usage as well.
=> the document recommends DHCPv6 in a context where its security
can't be insured. IMHO this is a major issue.
> - IMHO this paragraph is not sound:
=> s/sound/consistent/?
> The communication between the DHCP client and the DHCP server for
...
=> the paragraph begins by "security sensitive" and "requires".
The proposed solutions are lower-layer security, something which can't
be assumed to be always available, and DHCPv6 security, which doesn't
work well in the context (this is my previous comment). It finishes
by explaining the security in fact doesn't matter: this is both
arguable (security matters soon or late, and HA assignment is more
vulnerable then HA discovery) and not consistent with the
beginning.
> I have
> a concern about this because AAA is the only practical way to
> attach security properties (i.e., a proof it is not fake) to
> the care-of address so to improve the MIPv6 security.
> Unfortunately the document does nothing for this...
CoA ownership issue is outside the scope of "MIP6 bootstrapping"
problem.
=> so we have to find a way to put it inside! Note we have CoA
authentication by a trusted third party, a bit more than ownership.
Regards
Francis.Dupont@xxxxxxxxxxxxxxxx
PS: this is a bit strange: everybody seem to agree that AAA can provide
many good things and at the result it gives only the very minimum...
Perhaps what is wanted is a HA assignment in IKEv2 (making bootstrapping
current work useless) ? cf my checking message in the IPsec list:
http://msgs.securepoint.com/cgi-bin/get/ipsec-0510/26.html
|
Try Searching:
servers, voip, java, networking, microsoft ...
|
|
|
| 
