Subject: [homenet] Stephen Farrell's No Objection on draft-ietf-homenet-prefix-assignment-07: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 08 Jul 2015 08:37:17 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-homenet-prefix-assignment-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-homenet-prefix-assignment/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- section 3: I expected some security text here, not to say that
this all needs to be encrypted but rather to say that because
this is flooding, you can't really encrypt it and that hence
this scheme is only suited for smaller deployments and/or those
with lower layer security already in place. (And hence also
probably small.) 

- section 3: Similarly, you could also add some privacy text to
the effect that this scheme only applies where the privacy
characteristics of the various prefixes involved are all
roughtly similar, that is, where there's no real privacy
difference in which prefixes end up with which nodes. (Mind you,
I need to ponder that a bit myself to see if it's really the
case;-)

- sections 4 & 5: I found this impossible to understand in a
(quick) linear reading. I'd find actual code easier tbh. It's
interesting that Barry found this clear though (I did not,
clearly:-) so this isn't a discuss. But why didn't you first
provide an overview of the algorithm? 

- Where is the evidence that the algorithm converges? I'd have
thought there would be a reference to an academic publication
that also described the algorithm and a proof for convergence.

---

From: Pierre Pfister <[email-masked]>
Date: Wed, 8 Jul 2015 23:52:42 +0200

Hello Stephen

Thanks for the comments,

See inline for my proposals.

> Le 8 juil. 2015 à 17:37, Stephen Farrell <[email-masked]> a écrit :
> 

What about this addition to the applicability statement section:

NEW:
   Finally, leaving the Flooding Mechanism or Node ID assignment process
   unsecured makes the network vulnerable to deny of service attacks, as
   detailed in Section 8.  Additionally, as this algorithm requires all
   Nodes to know which Node has made which assignment, it may be
   unsuitable depending on privacy requirements among participating
   Nodes.

> provide an overview of the algorithm? 

It is, indeed, not straightforward, but I personally believe the text has the merit
of being unambiguous. 
I would recommend multiple pass anyway. And I believe it gets clearer when you
try to implement it.

> that also described the algorithm and a proof for convergence.

I wrote a proof, but could not find the time to publish it in a scientific paper.
I am not sure describing the algorithm in a paper would be interesting, but the proof as well as best and worst case behaviors
might be nice to have.

Thanks,

- Pierre

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 09 Jul 2015 09:05:00 +0100

Hiya,

On 08/07/15 22:52, Pierre Pfister wrote:
>> When responding, please keep the subject line intact and reply to
>> all email addresses included in the To and CC lines. (Feel free to
>> cut this introductory paragraph, however.)
>> 
>> 
>> Please refer to
>> https://www.ietf.org/iesg/statement/discuss-criteria.html for more
>> information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> this all needs to be encrypted but rather to say that because this
>> is flooding, you can't really encrypt it and that hence this scheme
>> is only suited for smaller deployments and/or those with lower
>> layer security already in place. (And hence also probably small.)
>> 
>> - section 3: Similarly, you could also add some privacy text to the
>> effect that this scheme only applies where the privacy 
>> characteristics of the various prefixes involved are all roughtly
>> similar, that is, where there's no real privacy difference in which
>> prefixes end up with which nodes. (Mind you, I need to ponder that
>> a bit myself to see if it's really the case;-)
> 
> NEW: Finally, leaving the Flooding Mechanism or Node ID assignment
> process unsecured makes the network vulnerable to deny of service
> attacks, as detailed in Section 8.

That's good.

> Additionally, as this algorithm requires all Nodes to know which Node
> has made which assignment, it may be unsuitable depending on privacy
> requirements among participating Nodes.

I'm less sure of that. I think the main point is that given how the
algorithm distributes prefixes one cannot assume there are any
privacy-relevant differences between any of the prefixes. (But again,
I'd need to think more to be sure that's correct.)

> It is, indeed, not straightforward, but I personally believe the text
> has the merit of being unambiguous.

Well, I cannot tell of course, given that I don't find it very
comprehensible;-) But I'm quite willing to believe that's just
my too-quick reading.

> I would recommend multiple pass anyway. 

I would recommend trying to make it easier for the reader. Adding
an overview at the front should do that.

> And I believe it gets clearer
> when you try to implement it.

Sure.

>> thought there would be a reference to an academic publication that
>> also described the algorithm and a proof for convergence.
>> 
> 

Hmmm. Those sound like famous last words don't they? I think if we
can't point at any evidence for the claim then we ought not make
the claim. (The evidence doesn't have to be a peer-reviewed academic
publication of course - if it has been discussed on the WG list
in enough detail that'd be perfectly fine.)

> I am not sure describing the algorithm in a paper would be
> interesting, but the proof as well as best and worst case behaviors 
> might be nice to have.

Sure, but not here. And if they're not published anywhere so far
then better to not refer to it at all for now.

Cheers,
S

> 
> 
> Thanks,
> 
> - Pierre
> 
> 
> 
> 
> _______________________________________________ homenet mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/homenet
>