Jürgen Schönwälder via Datatracker wrote:
> Let me start with a disclaimer: I am not familiar with BRSKI and ANIMA
...
Maybe reading RFC9030 and RFC9031 is really needed, and maybe we need more
references to that kind of architecture.
Note that RFC9031 uses OSCORE with PSKs, while this document uses DTLS with
full RFC8995 IDevIDs. It is unclear to what extent stronger references would
confuse more than they help.
I think that we regularly have the problem in the IETF where we make a small
extension in a small document to a larger situation, and then it is
surprising when external reviewers are unable to see the big picture.
(I've been there with many routing area extensions to OSPF or BGP as well)
> - Third, as an ops-dir reviewer, I am lacking information how this
> will be operationally deployed, i.e., how a shared link will be
> properly configured that may have multiple mechanisms to bootstrap
> routable IP addresses. How do I force pledges to go through this
> procedure before I hand out or let them discover a routable IP
> address?
... the short is that they can't see any shared link, it is encrypted.
> I also wonder whether alternatives been considered. Is it really
> necessary to introduce proxies that rewrite IP addresses? Could it be
> easier to let Pledges discover special temporary addresses that can be
There isn't a a shared link.
There is a mesh over (RPL, RFC6550) or equivalent system.
There is no broadcast domain.
The mesh links are encrypted.
The join proxies exists on both the encrypted and unencrypted sides.
The existing RFC8995 mechanism is basically stateful NAT66, and this is a
version that is stateless.
> used to reach (without going through a Join Proxy) the Registrar and
> once a Pledge gets enrolled, it can pick up a more general address? Or
> is the stateful solution not simply the more robust solution?
The stateful solution is subject to exhaustion of state by attackers.
> I skimmed through draft-richardson-anima-state-for-joinrouter-03,
> which has more alternatives. While properties of various solutions are
> discussed, no clear conclusions are drawn.
Yes, because different situations calls for different engineering tradeoffs.
> Back to this document,
> perhaps I am missing also an applicability statement for the Join
> Proxy solution.
more later.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] mcr@xxxxxxxxxxxx http://www.sandelman.ca/ | ruby on rails [
--
Michael Richardson <mcr+IETF@xxxxxxxxxxxx> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
Attachment:
signature.asc
Description: PGP signature
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
