netdev - Re: [PATCH 5/5] ipv4: Add FIB nexthop exceptions.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20120717.072534.1265804777758072167.davem@davemloft.net>
Date:	Tue, 17 Jul 2012 07:25:34 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	eric.dumazet@...il.com
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH 5/5] ipv4: Add FIB nexthop exceptions.

From: Eric Dumazet <eric.dumazet@...il.com>
Date: Tue, 17 Jul 2012 16:00:05 +0200

> On Tue, 2012-07-17 at 06:14 -0700, David Miller wrote:
>> In a regime where we have subnetted route entries, we need a way to
>> store persistent storage about destination specific learned values
>> such as redirects and PMTU values.
>> 
>> This is implemented here via nexthop exceptions.
>> 
>> The initial implementation is a simple linked list, and can be
>> expanded to a hash table when it is shown to be justified.
> 
> Say a typical host uses a single default route, I am trying to convince
> myself it can really use a simple linked list ?
> 
> Arent PMTU entries added by messages coming from untrusted sources ?

They are trusted when we validate them at the socket layer, at least
as is done for TCP.

I totally agree that we'll need to adjust the list into something more
sophisticated, but that's an implementation detail rather than
something that requires the actual infrastructure to be redone.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html