dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
4021

dennismurphy
Put me on hold? I'll put YOU on hold
Premium Member
join:2002-11-19
Parsippany, NJ

dennismurphy to Shady Bimmer

Premium Member

to Shady Bimmer

Re: [Networking] Is 10.0.0.0/8 not blackholed?

said by Shady Bimmer:

, rather than simply blaming someone else (Verizon) because you found behavior you did not expect. I remember the days when a situation like that posted by the OP would have instead been a "Aaaahhh. That's interesting. I did not expect that but let me see what I can do to properly fix it" rather than some of the sentiments expressed in this thread.

I didn't say anything was Verizon's fault but was curious about what was responding, and mildly surprised that the routes aren't blackholed by default on the BHR's. I think of each FiOS customers' network as an autonomous entity from each other.

Indeed, as I said, I found it interesting and of course resolved my issue, but wanted to dig into what's going on.

That's it. I had a discussion with one of the VZ architects who designed the network and he expressed surprise and concern about packet spoofing as I did.

Hence, the new blackholes.

None of this is earth shattering but a curiosity item and one that was validated and resolved.

Thanks all for the lively discussion, but given the network changes VZ has made after my discussion with them, it's clear they agree it is not optimal.

Really that simple.
Shady Bimmer
Premium Member
join:2001-12-03

Shady Bimmer

Premium Member

said by dennismurphy:

I didn't say anything was Verizon's fault but was curious about what was responding,

Several others did, however.

That's it. I had a discussion with one of the VZ architects who designed the network and he expressed surprise and concern about packet spoofing as I did.

Hence my question. What exactly is the issue with spoofing and the reachability of RFC1918 address space from a residential home broadband router? I don't see there is anything unique.

An address is an address. Whether it is part of a specific range of addresses specifically identified in an RFC or not should not make any difference, but it has been noted several times (including by you) that it does.

If a highly regarded architect believes it is an issue then perhaps this could be identified?

Hence, the new blackholes.

Have you received positive authoritative confirmation these routes are now "blackholed" or have those specific addresses been otherwise protected by ACLs (or similar), or perhaps have those addresses actually been retired/removed?

rebus9
join:2002-03-26
Tampa Bay

rebus9 to Shady Bimmer

Member

to Shady Bimmer
said by Shady Bimmer:

I'm not sure how this is relevant to the discussion of whether or not RFC1918 address space is reachable from a residential home router. It was posted a few times that this is a security risk and a hacking risk and that is the part that I fail to understand. How is reachability of RFC1918 address space any more of a risk than with any other address range(s)?

It's not that 1918 space is more hackable in and of itself. It's what's addressed within that space-- for example, equipment customers shouldn't be able to "see".
said by Shady Bimmer:

This won't work if the carrier is using RFC1918 space for its private usage (as is intended) such as in management and usage of its CPE.

Management interfaces on CPE (and on critical infrastructure) should be in a separate VLAN that customer traffic can't reach. I shouldn't be able to ping the management interface on the OLT at the C/O... or even my neighbor's ONT, for example.

Keep customer traffic away, regardless if it's addressed with publicaly routable or RFC1918 addresses. I believe THAT is what all the "hackable" talk is about.

The IP addresses themselves are irrelevant. What matters is, who can reach what equipment. Make sense?
Shady Bimmer
Premium Member
join:2001-12-03

Shady Bimmer

Premium Member

said by rebus9:

It's not that 1918 space is more hackable in and of itself. It's what's addressed within that space-- for example, equipment customers shouldn't be able to "see".

Why not? IE: Where is it written that services at these addresses shouldn't be reachable by other systems on the same network? Why would systems using addresses in RFC1918 ranges necessarily be any more sensitive than any other? That really isn't relevant, however.

What if the ISP had chosen to use alternate addresses from its publicly routable space - how would that change this at all (IE: what difference does the actual address used make?) There are plenty of servers on non RFC1918 address ranges that would fall in the same category.

If a server needs to be so protected, it should have a proper firewall or other suitable protections in front of it. The use of "private" address space has nothing to do with this.

RFC1918 addresses are meant to provide pre-defined ranges that may be used within a network by a single entity for use only within that entity, anywhere within that entity. This was intended for uses such as by those without public internet connectivity or those that otherwise did not have a registered network assignment. It was also useful for those entities that did not want to burn their public (routable) address space for devices that would never need to reach the public internet. It is not meant for security purposes.

Management interfaces on CPE (and on critical infrastructure) should be in a separate VLAN that customer traffic can't reach.

Where is this written as a requirement? It is Verizon's network and they can choose to manage and use addresses on their network as they so choose. Regardless, why does the address used matter? For instance, what does the use of RFC1918 addresses have to do with VLANs? That is the whole point.

Again - if there are services that should not be generally reachable and need to be protected, there should be a proper firewall in place. Choice of specific address ranges is not relevant.

Keep customer traffic away, regardless if it's addressed with publicaly routable or RFC1918 addresses. I believe THAT is what all the "hackable" talk is about.

Again - this has nothing to do with the address space and has everything to do with the use of a proper firewall.

The IP addresses themselves are irrelevant. What matters is, who can reach what equipment. Make sense?

Yes - but please read this thread and you will see references specifically that RFC1918 space reachability by home broadband routers is a security risk and a "hacking" risk. There was even reference that it is susceptible to spoofing. I'm not sure why you keep replying to me with points that aren't related to that specific point even though that is specifically what I am asking about.

What does any of that have to do with the address space? All of the same issues exist equally regardless. The reachability of RFC1918 address ranges is no more a risk than any other address ranges. I am looking specifically for supporting detail for the claims in this thread to the contrary.

dennismurphy
Put me on hold? I'll put YOU on hold
Premium Member
join:2002-11-19
Parsippany, NJ

dennismurphy to Shady Bimmer

Premium Member

to Shady Bimmer
said by Shady Bimmer:

Hence my question. What exactly is the issue with spoofing and the reachability of RFC1918 address space from a residential home broadband router? I don't see there is anything unique.

An address is an address. Whether it is part of a specific range of addresses specifically identified in an RFC or not should not make any difference, but it has been noted several times (including by you) that it does.

From *my* perspective, the concern is primarily overlapping addresses. As an example, using the 10.10.10.x block for my OpenVPN addresses should be acceptable; however, I was unknowingly sending my packets to some destination inside FiOS-space until I figured out what was going on. A default config on the Actiontec BHR's to prevent egress of rfc1918 addresses without NAT, or ingress of any packets from an rfc1918 source would prevent such.

From VZ's perspective, their concern is DDoS attacks using spoofed addresses; when you can't distinguish between spoofed 10.x/8 packets and real 10.x/8 packets, it's very hard to stop. Makes DDoS prevention more difficult.

Have you received positive authoritative confirmation these routes are now "blackholed" or have those specific addresses been otherwise protected by ACLs (or similar), or perhaps have those addresses actually been retired/removed?

The behavior I'm seeing tells me they've blackholed the network at least from a customer-facing perspective. I'm getting UDP traceroute and ICMP ping are returning "destination net unreachable" explicitly - that's definitely a change. I've been too lazy, frankly, to do any further digging.

rebus9
join:2002-03-26
Tampa Bay

rebus9 to Shady Bimmer

Member

to Shady Bimmer
said by Shady Bimmer:

Yes - but please read this thread and you will see references specifically that RFC1918 space reachability by home broadband routers is a security risk and a "hacking" risk. (...snip...)

Where is this written as a requirement? It is Verizon's network and they can choose to manage and use addresses on their network as they so choose.

Final answer-- RFC1918 space IS NOT less secure than other space. The "security risk" is NOT the IP addresses.

The seucrity risk is not protecting key assets with VLANs and ACLs.

There is a HUGE difference between IP addresses (in and of themselves) and the ability for a customer to reach non-public interfaces on infrastructure.
Shady Bimmer
Premium Member
join:2001-12-03

Shady Bimmer to dennismurphy

Premium Member

to dennismurphy
said by dennismurphy:

From *my* perspective, the concern is primarily overlapping addresses. As an example, using the 10.10.10.x block for my OpenVPN addresses should be acceptable; however, I was unknowingly sending my packets to some destination inside FiOS-space until I figured out what was going on. A default config on the Actiontec BHR's to prevent egress of rfc1918 addresses without NAT, or ingress of any packets from an rfc1918 source would prevent such.

This is covered by my comment that with the default config this would not be an issue. If you choose to diverge from the default then you need to ensure you take the proper steps to go with those changes.

From VZ's perspective, their concern is DDoS attacks using spoofed addresses; when you can't distinguish between spoofed 10.x/8 packets and real 10.x/8 packets, it's very hard to stop. Makes DDoS prevention more difficult.

This would be the same with any address and has nothing to do with RFC1918 ranges.

Further, if you tried to spoof such an address from your home connection it would do no good anyway. The protections against this have already been noted in this thread previously as well and apply equally to any address range (IE: they have nothing to do with RFC1918 ranges).
Shady Bimmer

Shady Bimmer to rebus9

Premium Member

to rebus9
said by rebus9:

Final answer-- RFC1918 space IS NOT less secure than other space. The "security risk" is NOT the IP addresses.

I agree with you and this is the point I have been making (please read my posts) so I don't know why you are arguing with me.

To clarify for you again - OTHERS have made these statements and I am asking them to provide the details on why they believe this is to be true. Why do you keep arguing back at me?

Again - please read my posts before responding.
propcgamer
join:2001-10-10
011010101

propcgamer to dennismurphy

Member

to dennismurphy
Looks like the blackhole rule is no longer in effect.

I can ping 10.10.10.1 again.
Same goes for 10.9.0.1.
tembit
join:2008-09-03

1 recommendation

tembit

Member

It looks like VZ is accidentally exposing an internal management network, or portions of one. Based on the traceroute path, I would venture a guess that we're looking at a management loopback interface, or perhaps a forwarding interface that's being redistributed into the global routing table without the appropriate management plane ACLs in place.

If you Telnet to 10.10.10.1, you'll see that it's clearly a Cisco device (could be a router or a switch), based on the prompts.

FiOS users aren't advertised routes by VZ, so technically speaking, I'm not convinced that RFC 1918 is being violated. As a FiOS user, one is essentially just an end node on VZ's access network within their Autonomous System, so they are free to inject any routes they want, as long as they don't advertise them to other Autonomous Systems.

If people don't like what VZ is doing, one can always black hole 10.0.0.0/8 on their home router by creating a static route that points to a null interface or a non-existent next hop.

rebus9
join:2002-03-26
Tampa Bay

1 recommendation

rebus9

Member

said by tembit:

If people don't like what VZ is doing, one can always black hole 10.0.0.0/8 on their home router by creating a static route that points to a null interface or a non-existent next hop.

Agreed.

At the same time, I think all the noise is from lack of understanding. From a technical standpoint, this is a total non-issue.