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

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 07 Aug 2006 17:10:35 -0700

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: Christian Vogt <[email-masked]>
Date: Tue, 08 Aug 2006 18:45:43 +0200

Hi Lakshminath,

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

> that happens before it becomes a WG item or after really doesn't

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

> 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

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.

> 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.

>  of a HoA or whether the HoA is valid or not?  Perhaps the latter is

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

> avoid that confusion here.

Allright.  Will clarify that.

> 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:
>  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.
> 
> regards, Lakshminath