Re: RFC6598 100.64/10: to bogon or not to bogon (team-cymru et all)

2023-03-07 Thread Grant Taylor via NANOG

On 3/7/23 4:34 PM, Lukas Tribus wrote:
I'm trying to educate people that bogon lists do not belong on hosts, 
firewalls or intermediate routers, despite Team-cymru's aggressive 
marketing of the opposite, quote:


I don't have any problem with bogon lists being on hosts or intermediate 
routers.


The think that you have to remember to do is to exclude locally 
significant (100.64/10, RFC 1918, et al.) from those filters /or/ 
account for them in another way.


I have bogons on some hosts /and/ locally significant / more specific 
routes to 100.64/16 without any problem.


Bogons is just a list of IPs that shouldn't be on the open Internet. 
But that same list can be re-used ~> abused elsewhere without.  How that 
list is used is installation specific.  If you're running default free, 
make sure that you remove the bogon prefixes from your routing tables 
/and/ /then/ (re)add any locally significant prefixes.


The Team Cymru bogon's list is a tool and like all tools, it can be 
mis-used and become a foot gun.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature


Re: RFC6598 100.64/10: to bogon or not to bogon (team-cymru et all)

2023-03-07 Thread Rabbi Rob Thomas
Dear team,

I’ve already reached out to Lukas directly, but I’ll kibitz a bit:

> They talk about bogon prefixes "for hosts", provide configuration
> examples for Cisco ASA firewalls,
> 
> Which are perfectly valid use cases for some networks / situations.

Indeed!  There was a time early in the life of the bogon lists where folks 
requested host-based and firewall-based filter examples.  This was because 
these were their AS-border devices, e.g. host-based routers and firewalls, and 
hardware firewalls.  I don’t remember writing a Cisco ASA example, but that was 
a long time ago.  :)

Be well,
Rabbi Rob.


> 
> 
> On Tue, Mar 7, 2023 at 6:35 PM Lukas Tribus  wrote:
> On Wed, 8 Mar 2023 at 00:05, William Herrin  wrote:
> > Hi Lukas,
> >
> > If you're using the team cymru bogon list at your customer border,
> > you're doing it wrong.
> 
> I'm not.
> 
> I'm trying to educate people that bogon lists do not belong on hosts,
> firewalls or intermediate routers, despite Team-cymru's aggressive
> marketing of the opposite, quote:
> 
> > THE BOGON REFERENCE
> >
> > *A bogon prefix should never appear in the Internet routing table*.
> > Team Cymru’s Bogon Reference provides several resources for
> > the filtering of bogon prefixes from your routers *and hosts*.
> 
> 
> > A bogon prefix is a route that should never appear in the Internet
> > routing table. A packet routed over the public Internet (not including
> > over VPNs or other tunnels) *should never have an address in a
> > bogon range.* These are commonly found as the source addresses
> > of DDoS attacks.
> 
> They either have to make it clear what their bogon list can actually
> be used for or they need to drop RFC6598 from the list.
> 
> They talk about bogon prefixes "for hosts", provide configuration
> examples for Cisco ASA firewalls, at the same time they include
> RFC6598 in the list and it's marketing material suggests it can be
> used for everything.
> 
> 
> You can't have it both ways. Either you provide a list of prefixes to
> be dropped on autonomous system borders *and make that clear* or you
> provide a list of prefixes that can be dropped in all systems.
> 
> 
> 
> Lukas

—
Rabbi Rob Thomas  Team Cymru
 "It is easy to believe in freedom of speech for those with whom we
  agree.”  - Leo McKern



signature.asc
Description: Message signed with OpenPGP


Re: RFC6598 100.64/10: to bogon or not to bogon (team-cymru et all)

2023-03-07 Thread William Herrin
On Tue, Mar 7, 2023 at 3:34 PM Lukas Tribus  wrote:
> > A bogon prefix is a route that should never appear in the Internet
> > routing table. A packet routed over the public Internet (not including
> > over VPNs or other tunnels) *should never have an address in a
> > bogon range.* These are commonly found as the source addresses
> > of DDoS attacks.
>
> They either have to make it clear what their bogon list can actually
> be used for or they need to drop RFC6598 from the list.

You'll have to connect the dots for me here, I'm not seeing the
problem. The ISP's local network is not "the public Internet." They
can use RFC6598 and even RFC1918 at their leisure. If they choose to
place services on those addresses and you want to use them, you'll
have to exclude them from your local filtering and/or your own
internal use. For everybody else, they're bogons.

Is someone out there defaulting consumption of the bogon list who
shouldn't be? What leads you to the strong objection about 100.64/10's
inclusion?

Regards,
Bill Herrin

-- 
For hire. https://bill.herrin.us/resume/


Re: RFC6598 100.64/10: to bogon or not to bogon (team-cymru et all)

2023-03-07 Thread Tom Beecher
>
> They talk about bogon prefixes "for hosts", provide configuration
> examples for Cisco ASA firewalls,
>

Which are perfectly valid use cases for some networks / situations.

On Tue, Mar 7, 2023 at 6:35 PM Lukas Tribus  wrote:

> On Wed, 8 Mar 2023 at 00:05, William Herrin  wrote:
> > Hi Lukas,
> >
> > If you're using the team cymru bogon list at your customer border,
> > you're doing it wrong.
>
> I'm not.
>
> I'm trying to educate people that bogon lists do not belong on hosts,
> firewalls or intermediate routers, despite Team-cymru's aggressive
> marketing of the opposite, quote:
>
> > THE BOGON REFERENCE
> >
> > *A bogon prefix should never appear in the Internet routing table*.
> > Team Cymru’s Bogon Reference provides several resources for
> > the filtering of bogon prefixes from your routers *and hosts*.
>
>
> > A bogon prefix is a route that should never appear in the Internet
> > routing table. A packet routed over the public Internet (not including
> > over VPNs or other tunnels) *should never have an address in a
> > bogon range.* These are commonly found as the source addresses
> > of DDoS attacks.
>
> They either have to make it clear what their bogon list can actually
> be used for or they need to drop RFC6598 from the list.
>
> They talk about bogon prefixes "for hosts", provide configuration
> examples for Cisco ASA firewalls, at the same time they include
> RFC6598 in the list and it's marketing material suggests it can be
> used for everything.
>
>
> You can't have it both ways. Either you provide a list of prefixes to
> be dropped on autonomous system borders *and make that clear* or you
> provide a list of prefixes that can be dropped in all systems.
>
>
>
> Lukas
>


Re: RFC6598 100.64/10: to bogon or not to bogon (team-cymru et all)

2023-03-07 Thread Lukas Tribus
On Wed, 8 Mar 2023 at 00:05, William Herrin  wrote:
> Hi Lukas,
>
> If you're using the team cymru bogon list at your customer border,
> you're doing it wrong.

I'm not.

I'm trying to educate people that bogon lists do not belong on hosts,
firewalls or intermediate routers, despite Team-cymru's aggressive
marketing of the opposite, quote:

> THE BOGON REFERENCE
>
> *A bogon prefix should never appear in the Internet routing table*.
> Team Cymru’s Bogon Reference provides several resources for
> the filtering of bogon prefixes from your routers *and hosts*.


> A bogon prefix is a route that should never appear in the Internet
> routing table. A packet routed over the public Internet (not including
> over VPNs or other tunnels) *should never have an address in a
> bogon range.* These are commonly found as the source addresses
> of DDoS attacks.

They either have to make it clear what their bogon list can actually
be used for or they need to drop RFC6598 from the list.

They talk about bogon prefixes "for hosts", provide configuration
examples for Cisco ASA firewalls, at the same time they include
RFC6598 in the list and it's marketing material suggests it can be
used for everything.


You can't have it both ways. Either you provide a list of prefixes to
be dropped on autonomous system borders *and make that clear* or you
provide a list of prefixes that can be dropped in all systems.



Lukas


Re: RFC6598 100.64/10: to bogon or not to bogon (team-cymru et all)

2023-03-07 Thread William Herrin
On Tue, Mar 7, 2023 at 2:09 PM Lukas Tribus  wrote:
> At the same time folks like team-cymru are picking up this prefix for
> their bogon lists with the following description [2]:
>
> > A packet routed over the public Internet (not including
> > over VPNs or other tunnels) should never have an address
> > in a bogon range.
>
> It would be quite a bad idea to drop 100.64/10 on a firewall or
> servers, when legitimate traffic can very well hit your infrastructure
> with those source IPs.
>
> Thoughts?

Hi Lukas,

If you're using the team cymru bogon list at your customer border,
you're doing it wrong. You should be using BCP38 there, which calls
for filtering source addresses not assigned to your customer.

At the Internet and peering borders, there is no legitimate traffic
which still has 100.64/10 as a source IP address.

There may be accidental traffic which has 100.64/10 (or 10/8 or
192.168/16) as a source address but it's not "legitimate." Of
particular concern, there may be ICMP type 3 (destination unreachable)
packets with these source addresses. It continues to irritate me that
vendors haven't addressed this discrepancy with tech that statelessly
translates these escapees to a public address that's legitimate for
your organization.

Regards,
Bill Herrin

-- 
For hire. https://bill.herrin.us/resume/


Re: RFC6598 100.64/10: to bogon or not to bogon (team-cymru et all)

2023-03-07 Thread Tom Beecher
>
> It would be quite a bad idea to drop 100.64/10 on a firewall or
> servers, when legitimate traffic can very well hit your infrastructure
> with those source IPs.
>
>
> Thoughts?
>

Don't use bogon lists in places you shouldn't use bogon lists.




On Tue, Mar 7, 2023 at 5:10 PM Lukas Tribus  wrote:

> Hello,
>
>
> so 100.64/10 is used in CGNAT deployments requiring service providers
> (that is AS operators) to drop 100.64/10 on the border to other AS in
> BGP and in the dataplane, as per RFC6598 section #6 Security
> Considerations [1].
>
> Within an AS though traffic from 100.64/10 can very well bypass CGNAT
> for AS local traffic to reduce state/logging. This appears to be quite
> common and it makes a lot of sense to me.
>
> At the same time folks like team-cymru are picking up this prefix for
> their bogon lists with the following description [2]:
>
> > A packet routed over the public Internet (not including
> > over VPNs or other tunnels) should never have an address
> > in a bogon range.
>
> It would be quite a bad idea to drop 100.64/10 on a firewall or
> servers, when legitimate traffic can very well hit your infrastructure
> with those source IPs.
>
>
> Thoughts?
>
>
> Lukas
>
>
> [1] https://www.rfc-editor.org/rfc/rfc6598#section-6
> [2] https://www.team-cymru.com/bogon-networks
>


RFC6598 100.64/10: to bogon or not to bogon (team-cymru et all)

2023-03-07 Thread Lukas Tribus
Hello,


so 100.64/10 is used in CGNAT deployments requiring service providers
(that is AS operators) to drop 100.64/10 on the border to other AS in
BGP and in the dataplane, as per RFC6598 section #6 Security
Considerations [1].

Within an AS though traffic from 100.64/10 can very well bypass CGNAT
for AS local traffic to reduce state/logging. This appears to be quite
common and it makes a lot of sense to me.

At the same time folks like team-cymru are picking up this prefix for
their bogon lists with the following description [2]:

> A packet routed over the public Internet (not including
> over VPNs or other tunnels) should never have an address
> in a bogon range.

It would be quite a bad idea to drop 100.64/10 on a firewall or
servers, when legitimate traffic can very well hit your infrastructure
with those source IPs.


Thoughts?


Lukas


[1] https://www.rfc-editor.org/rfc/rfc6598#section-6
[2] https://www.team-cymru.com/bogon-networks


Re: Request for comments

2023-03-07 Thread Etienne-Victor Depasquale via NANOG
The picture changes significantly when an operator's choice is weighted by
his current subscriber base.
Evidently, incumbents have lots of copper media, while smaller operators
(more agile?) are laying fibre and mostly growing GPON on it.

Rebuttals are welcome !

Unweighted data


Weighted data

(weighted by number of subscribers)

Cheers,

Etienne


On Fri, Mar 3, 2023 at 5:32 PM Etienne-Victor Depasquale 
wrote:

> I've updated the graphic
> 
> with one other data point and increased the graphic's size (following
> feedback).
>
> In particular, I'd like to understand why there are so many operators who
> consider Active Ethernet (p2p)
> to be their largest and/or fastest growing access technology.
>
> Would anyone care to give an opinion / interpretation / perspective /
> other ?
>
> Cheers,
>
> Etienne
>
> On Wed, Mar 1, 2023 at 9:24 AM Etienne-Victor Depasquale 
> wrote:
>
>> Good people of NANOG,
>>
>> Please find here
>> 
>> a snapshot of two datasets concerning access technologies in the metro area.
>>
>> The bar chart on the right summarizes data I collected last year from
>> *NOGs;
>> the bar chart on the left summarizes data received last year from Tier 1
>> and/or regional operators (incumbents).
>> The y-axis shows cumulative responses for an option; the x-axis shows
>> (hopefully unambiguous) monikers for the access technologies.
>>
>> Would anyone care to comment on how well this matches his/her perception
>> of the current state of deployments?
>>
>> Cheers,
>>
>> Etienne
>>
>> --
>> Ing. Etienne-Victor Depasquale
>> Assistant Lecturer
>> Department of Communications & Computer Engineering
>> Faculty of Information & Communication Technology
>> University of Malta
>> Web. https://www.um.edu.mt/profile/etiennedepasquale
>>
>
>
> --
> Ing. Etienne-Victor Depasquale
> Assistant Lecturer
> Department of Communications & Computer Engineering
> Faculty of Information & Communication Technology
> University of Malta
> Web. https://www.um.edu.mt/profile/etiennedepasquale
>


-- 
Ing. Etienne-Victor Depasquale
Assistant Lecturer
Department of Communications & Computer Engineering
Faculty of Information & Communication Technology
University of Malta
Web. https://www.um.edu.mt/profile/etiennedepasquale