Re: [6tisch] Comments on draft-ietf-6tisch-msf-02 - Re: draft-ietf-6tisch-msf-02.txt is published

[Tengfei Chang <[e-mail]>]

Hi Yatch,

Thanks for the following-up comments! I replied inline below.

On Thu, Mar 21, 2019 at 4:25 PM Yasuyuki Tanaka <[e-mail]>
wrote:

> Thank you, Tengfei.
>
> Additional and following-up comments:
>
>
> [Section 5.1, what to do after timeout of a 6P transaction]
> https://tools.ietf.org/html/draft-ietf-6tisch-msf-02#section-5
>
> The draft does not say anything about how to handle timeout of a 6P
> transaction. I know, the initiator of the timed out transaction will
> resend a 6P request to the same peer ;-) But, it's better to mention
> that as well as the maximum number of retries if we have.
>
>
Comment accepted!


>
> [Section 9, 6P Timeout Value]
> https://tools.ietf.org/html/draft-ietf-6tisch-msf-02#section-9
>
> A couple of questions:
>
> - "C" includes the autonomous cell to the neighbor or it is the number
>    of the managed cells?
> - How can the timeout value be calculated while PDR is not available?
>
>
I agree that those questions are not clear for the current version.
As the current version allows 6P to send on the autonomous SHARED cell
mentioned in the draft (MAY send on the Managed Cell as well, as mentioned
in the draft.), the PDR value is not realistic.
The calculation of TIMEOUT in the draft MAY not apply anymore.

Instead of a complex calculation, I propose to use a fixed value.
The value is the worst case to have a 6P response received on the
autonomous SAHRED cell after maxmium re-tries.
The worse case means each time when 6P response is failed to send out, it
back-off with the largest number of cells (autonomous SHARED cell).
Since there is only one autonomous SHARED cell each node, the node will
wait for the same number of slotframes.

The calculation is like:

for maxmium 3 retries:

backoff exponent start from 2 and increase each re-transmission

6P Timeout = slotframeDuration * (1 +  (2^2-1)+(2^3-1)+(2^4-1)  )


> [Section 4.5, Step 4 of the bootstrap process]
> https://tools.ietf.org/html/draft-ietf-6tisch-msf-02#section-4.5
>
> tengfei> I don't know whether there is a specification for how the
> tengfei> neighbor table should be managed. If no, I think PERSONALLY
> tengfei> it's better not keeping the address from pledge in neighbor
> tengfei> table.
>
> Although the actual way to manage neighbor information is
> implementation-dependent, the minimal security framework draft
> suggests to have separate memory for joined nodes and for pledges
> respectively:
>
>
> https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-09#section-6


I see. I am not sure using a neighbor cache is able to avoid the DoS attack.
My intuitive thinking is the neighbor cache still has a fixed size.
If an attacker sends multiple join requests with fake eui64 address in the
packet, it can still fill up the neighbor cache, which blocks other pledges
to join.

This maybe need to discuss with minimal security scope as well.


>
> Again, my comment on Section 4.5 is just that, I think we need some
> text in "Security Considerations" section for this operation described
> in Step 4. And, it seems the term of "the neighbor table" in the Step
> 4 is ambiguous. Some may think it's IPv6 neighbor cache, some may
> think L2 neighbor table.
>

I agree!


>
>
> [Appendix-B, SAX configuration]
>
> tengfei> This is a pre-configured (offline) for interoperability
> tengfei> purpose only.
>
> It's better to mention how a pledge gets the SAX parameters used in
> the network where it is trying to join. There are always two options:
>
> - pre-configured
> - advertised in EBs
>

Agreed.


>
> Best,
> Yatch
>


-- 
Chang Tengfei,
Pre-Postdoctoral Research Engineer, Inria