> On 20210917, at 21:20, Bjørn Mork wrote:
> [..]
>> Leaking packets from addresse that do not belong to you does.
>
> Yes. And the point is that you cannot tell if there is a leakage unless
> you are able to detect the network borders. Which you can't by counting
> traceroute hops.
In the
Gert Doering writes:
> "What happens inside your network happens inside your network" (and
> the RFC explicitly permits that, of course), but we do not want to
> see it on someone else's network.
Exactly my point. My traceroute example is all in "my" network if you
include the mobile access en
Hi,
On Fri, Sep 17, 2021 at 04:17:47PM +0200, Bjørn Mork wrote:
> > Section 5:
> >
> >It is strongly recommended that routers which connect enterprises to
> >external networks are set up with appropriate packet and routing
> >filters at both ends of the link in order to prevent packet
Gert Doering writes:
> On Fri, Sep 17, 2021 at 03:43:29PM +0200, Bjørn Mork wrote:
>> Gert Doering writes:
>> > On Fri, Sep 17, 2021 at 03:23:24PM +0200, Bjørn Mork wrote:
>> >> Using RFC1918 on links in your own network is fine. And having
>> >> them show up in traceroutes is a feature.
>> >
>>
HBi,
On Fri, Sep 17, 2021 at 03:43:29PM +0200, Bjørn Mork wrote:
> Gert Doering writes:
> > On Fri, Sep 17, 2021 at 03:23:24PM +0200, Bjørn Mork wrote:
> >> Using RFC1918 on links in your own network is fine. And having
> >> them show up in traceroutes is a feature.
> >
> > s/feature/sign of slop
Gert Doering writes:
> On Fri, Sep 17, 2021 at 03:23:24PM +0200, Bjørn Mork wrote:
>> Using RFC1918 on links in your own network is fine. And having
>> them show up in traceroutes is a feature.
>
> s/feature/sign of sloppy network design, and a RFC1918 violation/
Sorry for being slow. but I need
Hi,
On Fri, Sep 17, 2021 at 03:23:24PM +0200, Bjørn Mork wrote:
> Using RFC1918 on links in your own network is fine. And having
> them show up in traceroutes is a feature.
s/feature/sign of sloppy network design, and a RFC1918 violation/
Gert Doering
-- NetMaster
--
have you enabled IP
Jeroen Massar via ripe-atlas writes:
> If one sees RFC1918 in a traceroute (especially >5 hops away, thus
> just not the client->CPE hops), it indicates that every hop in the
> middle is not filtering at least RFC1918; more likely they are thus
> just doing any kind of reverse prefix filtering ak
> On 20210916, at 16:28, Max Grobecker wrote:
>
> Hi Jeroen,
>
>
>> We got CAIDAs spoofer project, but that primarily afaik checks that by doing
>> connections, not by checking ICMP returns.
>>
>> I just saw towards 213.244.71.2 :
>> [...]
>> Which means the whole path till that IP was not
Hi Jeroen,
> We got CAIDAs spoofer project, but that primarily afaik checks that by doing
> connections, not by checking ICMP returns.
>
> I just saw towards 213.244.71.2 :
> [...]
> Which means the whole path till that IP was not doing any kind of RPF
> thus spoofing anything else would b
Philip Homburg writes:
> On 2021/09/15 21:59 , Bjørn Mork wrote:
>> I believe it's better to ignore the formalities here and forward those
>> packets. It's certainly harmless. At least as harmless as forwarding
>> any other ICMP error messages.
>
> In my opinion this is the wrong approach. If th
On 2021/09/15 21:59 , Bjørn Mork wrote:
I believe it's better to ignore the formalities here and forward those
packets. It's certainly harmless. At least as harmless as forwarding
any other ICMP error messages.
In my opinion this is the wrong approach. If there is a good reason to
violate th
Jeroen Massar writes:
> If you can't verify the source, which with LL you cannot as they are
> on every interface around the world, it is spoofable.
Yes.
> Do you really want to receive a fe80::/10 at your recursive DNS
> service as a request (which could be valid, locally).
If you allow fe80:
> On 20210915, at 19:25, Stephen Strowes wrote:
>
>
> On 9/15/21 11:32 AM, Jeroen Massar via ripe-atlas wrote:
>> Hi Folks,
>>
>> Has anybody ever run a all-probe traceroute and then to detect any RFC1918
>> addresses in there? (though many probes will have locally some RFC1918)
>
>
> Sin
> On 20210915, at 21:59, Bjørn Mork wrote:
>
> Philip Homburg writes:
>
>> As far as I know, this a well known Juniper bug where their routers
>> forward errors ICMPs without checking whether the source address is
>> link local.
>
> Thinking about this...
If you can't verify the source, wh
Philip Homburg writes:
> As far as I know, this a well known Juniper bug where their routers
> forward errors ICMPs without checking whether the source address is
> link local.
Thinking about this... Is there any reason except formalities why you
shouldn't forward those packets? The won't gener
On 2021/09/15 19:06 , Gert Doering wrote:
On Wed, Sep 15, 2021 at 06:58:50PM +0200, Philip Homburg wrote:
My router at home gets a lot of error icmps with link local source, from
quite a few hops away...
*wake up* IPv4 "link local" (169.254.*) or IPv6 LLA (fe80::)?
IPv6 link local
The lat
On 9/15/21 11:32 AM, Jeroen Massar via ripe-atlas wrote:
Hi Folks,
Has anybody ever run a all-probe traceroute and then to detect any RFC1918
addresses in there? (though many probes will have locally some RFC1918)
Since probes are running measurements to many targets already, the full
dat
Hi,
On Wed, Sep 15, 2021 at 06:58:50PM +0200, Philip Homburg wrote:
> My router at home gets a lot of error icmps with link local source, from
> quite a few hops away...
*wake up* IPv4 "link local" (169.254.*) or IPv6 LLA (fe80::)?
The latter would make me very curious what sort of intermediat
On 2021/09/15 17:32 , Jeroen Massar via ripe-atlas wrote:
Has anybody ever run a all-probe traceroute and then to detect any RFC1918
addresses in there? (though many probes will have locally some RFC1918)
Atlas performs quite a few traceroutes on all probes. For example,
https://atlas.ripe.ne
20 matches
Mail list logo
