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

[Christian Vogt <[e-mail]>]

Hi Lakshminath,

thanks for reviewing draft-arkko-mipshop-cga-cba-04.  My comments
in-line.

> I think the draft needs a revision and some major surgery.   Whether 
> that happens before it becomes a WG item or after really doesn't
> matter to me.

Let's resolve whatever is necessary before the draft becomes WG item. ;-)

> So, I had a tough time trying to follow what's being proposed, but 
> when I got to the security considerations section, things were 
> clearer; that section seems to capture the problem space very 
> clearly.  I think the draft needs to be revised using that as the 
> guideline. 

Ah, that's interesting.  So I guess we'll elaborate on the introductory
section(s) of the draft to clarify what the protocol is up to.

>            Specifically, I find that the proposed solution is too
> dependent on the 3775's solution for RO.  I think the consideration 
> should be on the problem itself and a solution based on CGAs.  Any 
> problems that are native to IPv6 itself need not be addressed in this
>  draft.  To that end, I am proposing that the draft be split into two
>  parts and considered separately.

I'm not sure if the description of the protocol operation can be split
that easily--- not because the HoA and CoA test optimizations would not
be orthogonal, but because the description is more compact and easier to
read if the description follows the steps of the correspondent registration.

I fully agree, however, that the security considerations should be split
into two parts.  And, referring to your first comment, the revised
introduction should probably attend to the HoA and CoA test
optimizations individually.

> Let me pose that as a question actually.  Are flooding attacks (from 
> the last paragraph of the sec considerations section) specific to 
> MIP6 or IPv6?  If there is nothing MIP6 specific there, that problem 
> and the solution should be moved out of this draft.

Redirection-based flooding attacks are specific to MIPv6.  Actually,
they are specific to multi-addressing in general, be it mobility or
multi-homing.

Other types of flooding, such as TCP-SYN attacks, Smurf attacks, or DDoS
attacks are not MIPv6-specific.  DDoS attacks could be combined with
redirection-based flooding, however.  See my response to Vidya's review.

> To address redirection attacks, does a CN need to verify reachability
>  of a HoA or whether the HoA is valid or not?  Perhaps the latter is
> sufficient?

Reachability verification is required to prevent so-called
"return-to-home flooding attacks".  See section 3.2.2 of RFC 4225 (MIPv6
Security Background).

> Next, if the goal in generating a symmetric key is to amortize the 
> cost of a public-key operation, it should be specified as such.  The 
> concept of keygen is confusing in this draft and that seems to be due
>  to the re-use of the terminology from 3775.  I think it is best to 
> avoid that confusion here.

Allright.  Will clarify that.

> I realize those are high-level comments, but feel free to start a 
> discussion on any of those if anything is unclear.

Ok, thanks anyway.

- Christian

-- 
Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH)
www.tm.uka.de/~chvogt/pubkey/

"Everything should be made as simple as possible, but not simpler."
(Albert Einstein)


Lakshminath Dondeti wrote:
> This is in response to the call on whether to adopt 
> draft-arkko-mipshop-cga-cba-04 as a MIPSHOP WG item.  Given that the
>  charter already says "MIPv6 Return Routability via both 
> Cryptographically Generated Addresses and Credit-based Authorization
>  for advancement as Proposed Standard
> 
> * Documents: draft-ietf-mipshop-cga-cba-XX.txt"
> 
> I am not really sure whether there is anything to say about adopting
>  the I-D as a working group item.
> 
> I think the draft needs a revision and some major surgery.   Whether
>  that happens before it becomes a WG item or after really doesn't
> matter to me.
> 
> So, I had a tough time trying to follow what's being proposed, but 
> when I got to the security considerations section, things were 
> clearer; that section seems to capture the problem space very 
> clearly.  I think the draft needs to be revised using that as the 
> guideline.  Specifically, I find that the proposed solution is too 
> dependent on the 3775's solution for RO.  I think the consideration 
> should be on the problem itself and a solution based on CGAs.  Any 
> problems that are native to IPv6 itself need not be addressed in this
>  draft.  To that end, I am proposing that the draft be split into two
>  parts and considered separately.
> 
> Let me pose that as a question actually.  Are flooding attacks (from
>  the last paragraph of the sec considerations section) specific to 
> MIP6 or IPv6?  If there is nothing MIP6 specific there, that problem
>  and the solution should be moved out of this draft.
> 
> To address redirection attacks, does a CN need to verify reachability
>  of a HoA or whether the HoA is valid or not?  Perhaps the latter is
> sufficient?
> 
> Next, if the goal in generating a symmetric key is to amortize the 
> cost of a public-key operation, it should be specified as such.  The
>  concept of keygen is confusing in this draft and that seems to be
> due to the re-use of the terminology from 3775.  I think it is best
> to avoid that confusion here.
> 
> I realize those are high-level comments, but feel free to start a 
> discussion on any of those if anything is unclear.
> 
> regards, Lakshminath




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