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
