Hello Pascal, Yes, it does. Thank you!
Best, Yatch > On Jun 21, 2019, at 18:00, Pascal Thubert (pthubert) <[email protected]> > wrote: > > Hello Yatch; > > In the security section is changed the text to: > > " > > An attacker can perform a Denial-of-Service (DoS) attack on a node > implementing VRB by generating a large number of bogus "fragment 1" fragments > without sending subsequent fragments. > This causes the VRB table to fill up. Note that the VRB does not need to > remember the full datagram as received so far but only possibly a few octets > from the last fragment that could not fit in it. > It is expected that an implementation protects itself to keep the number of > VRBs within capacity, and that old VRBs are protected by a timer of a > reasonable duration for the technology and destroyed upon timeout. > " > > Works? > > Pascal > >> -----Original Message----- >> From: 6lo <[email protected]> On Behalf Of Carsten Bormann >> Sent: jeudi 7 février 2019 12:42 >> To: Yasuyuki Tanaka <[email protected]> >> Cc: [email protected] >> Subject: Re: [6lo] draft-ietf-6lo-minimal-fragment-00: When to remove VRB >> entries? >> >> On Feb 7, 2019, at 12:36, Yasuyuki Tanaka <[email protected]> wrote: >>> >>> Since datagram_tag is expected to be incremented (by one) as RFC4944 >> specifies, holding the last datagram_tag per peer may be enough, although >> this >> kind of thing could be "implementation-specific": >> >> Right. We don’t want to blackhole datagrams after a reboot, and we want to >> allow the sending implementation to forget their neighbor state (which might >> include that counter, if it is not global) after a while. So I think some >> form of >> timeout may be needed. >> >> Grüße, Carsten >> >> _______________________________________________ >> 6lo mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/6lo _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
