Toerless Eckert <t...@cs.fau.de> wrote:
> For the stateful proxy, the pull request from my review i sent last
friday suggests the
> following text:
> To protect itself and the Registrar against malfunctioning Pledges
> and or denial of service attacks, the join proxy SHOULD limit the
> number of simultaneous mapping states for each IP_p%IF to 2 and the
> number of simultaneous mapping states per interface to 10. When
> mapping state can not be built, the proxy SHOULD return an ICMP error
> (1), "Destination Port Unreachable" message with code (1),
> "Communication with destination administratively prohibited".
I've adapted this text and inserted it into the ed-review-comments branch.
> Do you think these are useful numbers ?
They seem reasonable.
> from the proxy and only have it on the registrar. The best DoS protection
i could
> think of on the proxy is therefore just a total packet rate limiter. Is
> it possible
I agree, that limiting total packets/bytes that can be (ab)used is the best
way. This may mean that attackers can keep legimate pleges from joining, but
if we knew who was legitimate a-priori, we wouldn't need to do this at all.
> to come up with good recommendations on such packet rate limiters ? For
example
> 1% of the "uplink" bitrate ? Can you think of mesh networks where this
would not
> be a good enough number ? If this (or another number) makes sense we
could suggest
> to add it to the stateless proxy section.
In RFC9031, we used used DSCP to mark upward join traffic as distinct, in
order to avoid having 6tisch think it was legitimate traffic and allocate
additional bandwidth for it.
A different DSCP marks downward traffic, because if the Registrar considers
it worth responding, then the response really needs to get there.
> I can already see a BRSKI scenario in the USA, where the manager of the
> east-coast NOC went home at 5PM and some IT folks on the west coast
> still want enroll new equipment in an installation and wonder what
> happens.
I can see the same thing.
I think that this is a layer 8 issue.
What we need is to be able to more clearly signal it.
https://datatracker.ietf.org/doc/draft-ietf-roll-enrollment-priority/
is about this kind of control being expressed down to the leafs.
But, turning the Registrar on/off also helps.
> Instead of stopping service announcements (registrar and proxy), i
> would then love to see the service
> announcements witth some "service status" flag/field. For example "off
> hours" or the like. Workflow:
> Device to be enrolled has single color LED. You connect it (west coast)
> to the network, and it would indicate "off hours" through eg.:
> repeating three short blinks. This validates that network connectivity
> works, and that enrolment will proceed once someone switches "BRSKI on"
> (next morning).
> Does that make sense ?
yes, it does.
How do you signal the device in an authentic way that can't be spoofed?
It seems that you have to actually do the onboarding process (including
voucher return) in order to establish trust, and then you can say, "off
hours", which certainly doesn't help the DoS problem.
That's one reason why EST/RFC7030 has this 202 status process.
The enrollment that started at 5:06pm on Friday is waiting for a human to
come in on Monday morning and click the "ok" box.
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
