Subject: [6tisch] 6tisch minimal -- when can/should JP throw-away/blacklist pledges?

From: Michael Richardson <[email-masked]>
Date: Thu, 26 Jul 2018 18:04:22 -0400

(Listening to the youtube recording)

Tero clarified the slide 8, about when the JP could throw away the neighbour
state, and whether or not the JP could blacklist a pledge.

The JP is not entirely stateless: it benefits from maintaining a neighbour
state entry for the pledge.  However, depending upon how the stateless proxy
token is implemented by the JP, it could essentially store some of the
neighbour info for the pledge.

The fundamental mis-communication between Tero and Malisa in the audio
recording is because they are looking at the pledge from different points of
view.  Tero is considering more situations where the Pledge is either
malicious, or poorly configured, while Malisa is considering situations where
the join fails for (less) non-malicious reasons, but the pledge is otherwise well
behaved. 
   
a) the 6tisch-minimal draft is a one-round-trip process, but, the zero-touch process
   requires many round trips.

b) re: two-step process: this is how the 2014-era join process was going to
   work, with the pledge saying hello, and the JRC would then drive the
   process.  We left that process.

c) the stateless token that needs to be returned to the JP in order to route
   the packet to the pledge, *could* be defined to include a "LAST" (FIN) flag.
   That would let the JP immediately garbage collect the neighbor entity.
   Whether the JP would then accept the pledge again in another round, is
   another question to me.

I don't really want the JP to have that kind of history, but I think it would
be useful to have a communication from the edges to the root to indicate
if they are having resources issues with leaf nodes.  This might be a ROLL
level thing however, and could have a lot to do with balancing trees. 
In particular, DAOs  are only sent when a parent *accepts* a child, not
(AFAIK) when they reject the child due to resource constraints.

So in the spirit of ROLL's, when a tree-falls-and-nobody-hears-it, maybe we
only need to solve the resource constraint problem when we run out of resources?

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Mališa Vučinić <[email-masked]>
Date: Fri, 27 Jul 2018 10:51:46 +0200

Michael,

See inline.

Mališa

> the join fails for (less) non-malicious reasons, but the pledge is

I don't fully agree with this summary: this was discussed in more details
within the "My comments to the draft-ietf-6tisch-minimal-security-06"
thread on the ML. See in particular the last response.

>    requires many round trips.

Sure, we discussed this on the same thread.

>    process.  We left that process.

I don't understand this comment, is this related to Tero's comment on
having the signaling from JRC to JP on whether the join was successful?

>    Whether the JP would then accept the pledge again in another round, is

Yes, the main point here is that all of this does not by any means impact
interoperability and that JP may include in the stateless token whatever it
may need to operate fully statelessly. For example, if it has multiple
interfaces, uses non-default ports, ND entries, etc, etc.

> (AFAIK) when they reject the child due to resource constraints.

Agreed, I think this approach should be advanced within the enhanced-beacon
draft//

> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>