Confirmation on decision on HMIPv6 Security

I don't believe you are missing anything. However, if we did
IKEv2 with
EAP, the ID (Say, NAI) is tied to the IKE_SA. The ID is
authenticated
(due to client authentication) and if the peer is required
to send the
chosen IP address in IKEv2 to the MAP, the MAP can tie that
to the SA
after performing a proxy DAD and ensuring that it doesn't
have the
address registered for any other node. So, while there is no
"absolute"
address authorization, this will still ensure that no live
node's
traffic is being redirected to an attacker. We can do the
same with
self-signed certs, but the issue will be that, in the event
of problems,
it is much harder (impossible) to track down the attacker,
since there
was no authentication. But then, the fact that the system is
infrastructureless may imply that there is no reason to
track anyone
down 

jak>> If proxy DAD is used, then the MAP is restricted
to be on the last 
hop, right? If this is the case for any solution where the
RCoA is 
autoconfigured, then the deployment scenerios for HMIP
become quite 
restricted, IMO. If that is the case, then I think the WG
needs to think 
about adding assignment of the RCoA within the IKEv2 SA
regardless of 
whether self-signed certs are mentioned, so that deployment
scenerios where 
the MAP is acting as a gateway to an entire access network
can also be 
securely accommodated.

Such details on address authorization should be captured in
the document
for a complete security solution.

jak>> Yes, I agree. The current document is really
lacking in discussion of 
details such as these.

            jak 


_______________________________________________
Mipshop mailing list
Mipshopietf.org
https:
//www1.ietf.org/mailman/listinfo/mipshop