Subject: [6tisch] nbr cache recommendation

From: Rahul Jadhav <[email-masked]>
Date: Mon, 13 Nov 2017 17:46:05 +0800

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

---

From: Mališa Vučinić <[email-masked]>
Date: Mon, 13 Nov 2017 11:45:50 +0100

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-masked]> 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.
> 
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

---

From: Rahul Jadhav <[email-masked]>
Date: Mon, 13 Nov 2017 23:49:31 +0800

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-masked]>
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.
>