Subject: Re: [CGA-EXT] review of draft-ietf-csi-sndp-prob-00.txt

From: "Michaela Vanderveen" <[email-masked]>
Date: Wed, 17 Dec 2008 16:33:15 -0800

Hi,

I have reviewed this draft and have the following comments:

Other reviewers think that the draft is reaching too far into the solution
space, for a problem statement. I find the level of solution hints to be
acceptable. In any case it seems that maybe it's a bit late for a WGLC?

It would be nice if the text below Fig. 5 actually referred to nodes M and N
and their locations, to illustrate the issues therein in a more  concrete
fashion. Ditto goes for Fig. 6.

Section 2.3: The last part of the sentence "but may be matched with Neighbor
solicitation and advertisement services using the proxy's source
   address in the same way as Mobile IPv6 [RFC4389] [RFC3775]"
is not clear; more text about how Mobile IPv6 does matching of what to what.

Section 4.3: Not sure why we worry about the case when a node leaves the
link before it completes DAD, so it does not really have an address. Is this
any more common than the case of mobiles moving so fast that they can't
complete a handshake registration?

Section 8.3, first paragraph: why is accurate timekeeping required for
certificates? Certificates should be longer-term, unlike binding messages,
say, which need timestamps for anti-replay.

Some editorials below:

Abstract: First sentence needs rephrasing (at least replace "no" by "not")

Section 2.2.:  * "This is case" -> "This is the case"
           * "this latest assigns it" -> "the latter assigns such an
    address"
           * "to be able to intercept messages, sent to the node, to tunnel
them to this latest" -> "to be able to intercept and tunnel messages to the
node".

Section 3: "These advertisements must therefore have enough authority to
override Neighbor cache entries even though they are secured." ->
           " These advertisements must therefore have enough authority to
override secured Neighbor cache entries." (not clear which are secured, the
advertisements or the cache entries).

Section 4.1: Reference to CGA is not [3971] but [3972].

Section 4.2: "and infers support for CGA verification.
   Clarification or changing of this issue for non-CGA operations may be
   necessary." ->
        "and allows for CGA verification.
   Updating of the signature function to support non-CGA operations may be
necessary." (or something along these lines)

Section 5.1.2. " This certificate would need to be passed near to binding
time" - clarify: passed to whom, and what does "near" mean, shortly before
or shortly after binding update time instance?

Section 5.1.3: The sentence starting with "This is the case..." is too long
and needs to be split into two for clarity (e.g. at the "but to check..")).

Section 5.1.4: * "the HA no more needs to" -> "the HA no longer needs to"
       * "this results to use a virtual" -> "this results in a virtual"

Section 5.2.2:  * "Routers advertising on networks without routers" sounds
strange. Rephrase?

 * "Any device can set up to be" -> "Any device can set out to be"

Section 5.2.6: * "supercede" -> "supersede".
         * "and may wish two network segments to appear to be
   connected" -> " and may want to make two network segments appear to be
   connected"

Section 6: "defending a same"  -> "defending the same"
           "a same PMIP " -> "the same PMIP"

Regards,
Michaela
_______________________________________________
CGA-EXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cga-ext

---

From: Julien Laganier <[email-masked]>
Date: Thu, 18 Dec 2008 14:42:50 +0100

Hi Michaela,

On Thursday 18 December 2008, Michaela Vanderveen wrote:
> Other reviewers think that the draft is reaching too far into the
> solution space, for a problem statement. I find the level of solution
> hints to be acceptable. In any case it seems that maybe it's a bit
> late for a WGLC?

Wandering into solution space in a problem statement document is not 
problematic per se.

But we're looking at a security problem, thus what is problematic is, 
the problem statement does not define the trust model from which we can 
observe what the problem is. 

As a start we could try to answer these questions: where is the NDproxy, 
who owns it, who operates it, who authorizes it, to do what? 

An answer could be: the NDproxy is on small residential network 
connected to an ISP by a CPE, it is owned by the customer but operated 
by said ISP, it is authorized by CGA owners on the link to send NS/NAs 
for said CGA owners, and by said ISP to advertize the prefix delegated 
to the CPE.

Is this a good answer? Is it the only good one?

--julien

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Sat, 27 Dec 2008 18:52:54 +0100

Hi,

At first sorry for the late reply and thanks for your review.

> acceptable. In any case it seems that maybe it's a bit late for a WGLC?

BTW, that was something asked by people from the WG :)

> fashion. Ditto goes for Fig. 6.

OK.

> is not clear; more text about how Mobile IPv6 does matching of what to what.

All is normally described in section 2.1 but I can add a reference to
this section :)

> complete a handshake registration?

E.g., MIPv6 bootstrapping where the HA has to perform a DAD for the
HoA before to assign it.

> say, which need timestamps for anti-replay.

Yes and no :)
Depends whether a certificate based authorization of ND proxy is
short-term as a CGA or not ... I must admit this is unclear for me for
the moment :s

> Abstract: First sentence needs rephrasing (at least replace "no" by "not")

OK. Thanks.

> them to this latest" -> "to be able to intercept and tunnel messages to the

OK. Thanks.

> advertisements or the cache entries).

OK. Thanks.

> Section 4.1: Reference to CGA is not [3971] but [3972].

OK. Thanks

> necessary." (or something along these lines)

OK. Thanks.

> or shortly after binding update time instance?

OK.

> and needs to be split into two for clarity (e.g. at the "but to check..")).

OK.

>        * "this results to use a virtual" -> "this results in a virtual"

OK.

> Section 5.2.2:  * "Routers advertising on networks without routers" sounds

OK (cf. previous reply to another review).

>  * "Any device can set up to be" -> "Any device can set out to be"

OK.

>    connected" -> " and may want to make two network segments appear to be

OK.

>            "a same PMIP " -> "the same PMIP"

OK. Thanks.

Best regards and happy new year.

JMC.