Re: [Mipshop] Review of draft-arkko-mipshop-cga-cba-04

[Wassim Haddad <[e-mail]>]

Just want to ask you if you have read the charter of the mipshop WG?
Or maybe you're planning to write another one soon?!


Wassim H.


On Mon, 7 Aug 2006, Narayanan, Vidya wrote:

>
> Summary:
> ---------
> Overall, I do believe that MIP6 RO needs to be revised for better
> security and optimization. I think using CGAs to generate HoAs is a good
> step towards that. From that perspective, this draft is good. I do,
> however, think that we don't need any CoA tests (more on that in the
> details below). By using CGAs and signed proof to verify HoAs and an
> initial HoA test, the CN gets the same assurance about the addresses of
> an MN as the HA. That alone is sufficient to generate a binding and
> optionally exchange a symmetric key. Hence, I think the "cga" part of
> the draft is useful, while the "cba" part is non-essential.
>
> Having said that, I think it would be best if this document actually
> takes a two-step process, going through experimental track first. That
> would give us the opportunity to mature the concept and have a solid
> proposal for MIP6 RO. I don't think we should target a proposed standard
> right away - I think in this case, going to an experimental RFC first is
> useful (as we've done before with mobility optimizations such as FMIP
> and HMIP).
>
> Detailed comments
> -----------------
>
> (I've limited these to sections 1 to 3, since that captures the concept)
>
> Major:
> ------
>
> 1. After some thought, I think we don't need CoA tests (and
> consequently, CBA) at all here. In MIP6, CoA test makes sense, since an
> attacker has to be present both on the link between the MN and the CN
> and on the link between the MN and HA to successfully arrive at the Kbm.
> Without the HoTi/HoT or CoTi/CoT, this becomes easier for the attacker,
> since presence is required only on one link. However, if the MN's HoA
> can be cryptographically verified and the initial HoA test can be done
> to (indirectly) prove the existence of a valid registration at the HA,
> there should be no need for CoTi/CoT. For e.g., the HA today does not do
> a CoA verification - it goes to the same point as in 1 above that if the
> MN wants to flood another node by claiming a wrong CoA, it can do that
> anyway by other means.
>
> 2. The text under "Initial home address tests" in section 3 is
> confusing. I'm not sure I understand the flooding attack as described.
> If the goal is to flood any network, as I said in my first point above,
> it doesn't need to be done with MIP6. What is more important is ensuring
> that an MN that does not have a binding with its HA doesn't end up
> creating a binding with a random CN. The fact that the MN has a valid
> binding with its HA implies a couple of things - that it has been
> authenticated and authorized for MIP6 use and that it is not claiming
> another node's HoA.
>
> Given that, the initial home address test will achieve this - it is just
> that the motivation seems to differ in my mind.
>
> Not-so-major (not-so-minor :))
> ------------------------------
>
> 3. Section 2.2 talks about redirection of an MN's communications to a
> third party, thereby flooding the victim (2nd bullet). In my view, this
> is not a threat that MIP6 brings. If a malicious node has a goal of
> flooding a given node, it doesn't need MIP6 to achieve that. It can send
> packets to that IP address and those will do. There isn't a real need to
> set up a bogus MIP6 binding to realize that attack. So, I think that
> paragraph should be removed.
>
> 4. Also, the point about DoS attacks may stay - but, it is probably
> worth mentioning that DoS attacks are achieved by a variety of other
> means, some of them, much simpler than engaging in expensive
> computations.
>
> 5. Section 3 talks about cryptographically generated home addresses
> providing authentication - CGAs provide address ownership validation,
> but not really authentication. In order to authenticate a node (i.e., to
> verify the node is "who" it claims to be), a verification of its
> identity needs to occur - which implies a shared key or a public/private
> key pair endorsed by a certificate. I'm assuming this section meant to
> really talk about HoA ownership validation?
>
>
> Vidya
>
> _______________________________________________
> Mipshop mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mipshop
>
>

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