RE: [Mipshop] Review of draft-arkko-mipshop-cga-cba-04
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Mipshop] Review of draft-arkko-mipshop-cga-cba-04
Wassim,
I have and I'm expressing my opinion along with detailed technical
comments. If you have specific points to make, please do so.
Vidya
> -----Original Message-----
> From: Wassim Haddad [mailto:whaddad at tcs.hut.fi]
> Sent: Monday, August 07, 2006 3:18 PM
> To: Narayanan, Vidya
> Cc: mipshop at ietf.org
> Subject: Re: [Mipshop] Review of draft-arkko-mipshop-cga-cba-04
>
> 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
> > Mipshop at ietf.org
> > https://www1.ietf.org/mailman/listinfo/mipshop
> >
> >
>
_______________________________________________
Mipshop mailing list
Mipshop at ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.