Thanks Malisa for the instant feedback. The draft specifies that neighbor entries are reserved and nodes during pre-auth phase can occupy only certain set of entries. There is a "reason" field in every entry which would identify such entries and thus it should take care of this. Having said that, we ll definitely look into making the text more explicit and clearer about this context.
Thanks, Rahul On 13 November 2017 at 18:45, Mališa Vučinić <[email protected]> wrote: > Hi Rahul, > > Thanks for the pointer. I skimmed through the draft but couldn’t find how > relay (JP) or new joinee (pledge) should handle each other before the > authentication procedure completes. You state: > > > Relay element does not hold any state information on behalf of the new > joinee node except for its neighbor cache entry. > > If one doesn’t differentiate between neighbor entries from > already-authenticated nodes and yet unauthenticated pledges, depending on > the policy by which new entries are added, there is a potential DoS attack > on relay (JP) where the attacker could flood it with spoofed entries. > > I think that you should explicitly stress what is the recommended way of > managing this in your draft. One could implement a separate cache for > untrusted entries or keep a common cache and add complexity in the policy > by which new entries are added. The latter would require an “untrusted” > flag in each entry based on which we could count untrusted neighbors and > decide whether to overwrite an existing neighbor with a new (untrusted) one. > > Let me know if I missed something :). > > Mališa > > > On 13 Nov 2017, at 10:46, Rahul Jadhav <[email protected]> wrote: > > > > Malisa mentioned recommendations about maintaining untrusted nbr cache > entries. There is another work-in-prg on lwig which takes into > considerations these aspects of maintaining nbr entries for network > access/auth protocol. > > > > https://datatracker.ietf.org/doc/draft-ietf-lwig-nbr-mgmt-policy/ > > Pls check if your considerations are handled. Thanks. > > > > Regards, > > Rahul > > _______________________________________________ > > 6tisch mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/6tisch > >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
