On Tue, 2 Apr 2013, Måns Nilsson wrote:
What percentage of the SOHO NAT boxes actually are full-service
resolvers? I was under the impression that most were mere forwarders;
just pushing queries on toward the DHCP'd full service resolvers of the
ISP.
What does that help? They can still be am
On Apr 2, 2013, at 9:48 AM, Paul Ferguson wrote:
> In any event, depending on where you are in the U.S., many consumers have a
> choice between bad and worse. :-)
I certainly do agree with that general sentiment. Living abroad, I have more
choices in terms of both wired broadband and wireless
On Mon, Apr 1, 2013 at 7:38 PM, Dobbins, Roland wrote:
>
> On Apr 2, 2013, at 9:09 AM, Owen DeLong wrote:
>
>> Even in such populous areas as San Jose, there is a limited selection to a
>> majority of the customers, especially if they want more than 1.5Mbps.
>
> I lived in San Jose for several y
On Apr 2, 2013, at 9:09 AM, Owen DeLong wrote:
> In the majority of the US where it is rural, there is even less choice.
Largest in geography <> largest in population.
> Even where there are multiple providers, they often all provide the same
> limitations in their AUP unless you go to higher
On Apr 2, 2013, at 9:09 AM, Owen DeLong wrote:
> With all due respect, sir, you are mistaken.
>
> Even in such populous areas as San Jose, there is a limited selection to a
> majority of the customers, especially if they want more than 1.5Mbps.
I lived in San Jose for several years, and had se
Packets, shmackets. I'm just upset that my BGP over Semaphore Towers
routing protocol extension hasn't been experimentally validated yet.
Whoever you are who keeps flying pigeons between my test towers, you can't
deliver packets without proper routing updates! Knock it off long enough
for me to
On 4/1/2013 10:15 PM, Eric Adler wrote:
> Make sure you don't miss the QoS implementation of RFC 2549 (and make sure
> that you're ready to implement RFC 6214). You'll be highly satisfied with
> the results (presuming you and your packets end up in one of the higher
> quality classes).
> I'd also
Make sure you don't miss the QoS implementation of RFC 2549 (and make sure
that you're ready to implement RFC 6214). You'll be highly satisfied with
the results (presuming you and your packets end up in one of the higher
quality classes).
I'd also suggest a RFC 2322 compliant DHCP server for devic
On Apr 1, 2013, at 6:54 PM, "Dobbins, Roland" wrote:
>
> On Apr 2, 2013, at 8:45 AM, Owen DeLong wrote:
>
>> In an oligopoly situation, that's hardly a valid set of choices
>
> There's enough choice in most US markets (not all) to provide for a variety
> of services offered, AUPs, and price
> Yeah, I thought so, too, but apparently the FCC and the SEC hasn't
> seen it that way for the past 20 years. Go figure. :-)
>
The FCC doesn't understand that 4Mbps customer-facing speed on the tail circuit
alone does NOT define broadband in a meaningful way.
The SEC does not understand that
--- esch...@comcast.net wrote:
From: "Ed Schweitzer"
Given we are moving into the hurricanes season in a few months, I was
wondering if this is now an accepted standard. I haven't seen many updates -
it appears to be complete as is.
Itty bitty rocket
On Apr 2, 2013, at 8:52 AM, Paul Ferguson wrote:
> Yeah, I thought so, too, but apparently the FCC and the SEC hasn't seen it
> that way for the past 20 years. Go figure. :-)
The situation is gradually getting better, not worse - and that's progress,
even if it isn't as fast as we'd all like.
On Apr 2, 2013, at 8:45 AM, Owen DeLong wrote:
> In an oligopoly situation, that's hardly a valid set of choices
There's enough choice in most US markets (not all) to provide for a variety of
services offered, AUPs, and price points. Wireless has brought an additional
option to many previous
On Mon, Apr 1, 2013 at 6:45 PM, Owen DeLong wrote:
>
> On Apr 1, 2013, at 6:38 PM, "Dobbins, Roland" wrote:
>
>>
>> On Apr 2, 2013, at 8:21 AM, Mark Andrews wrote:
>>
>>> I know and I would still argue that they are tantamount to extortion.
>>
>> There is no coercion involved, so, by definition,
On Apr 1, 2013, at 6:38 PM, "Dobbins, Roland" wrote:
>
> On Apr 2, 2013, at 8:21 AM, Mark Andrews wrote:
>
>> I know and I would still argue that they are tantamount to extortion.
>
> There is no coercion involved, so, by definition, it can't be called
> 'extortion'. If you don't like the A
On Apr 2, 2013, at 8:21 AM, Mark Andrews wrote:
> I know and I would still argue that they are tantamount to extortion.
There is no coercion involved, so, by definition, it can't be called
'extortion'. If you don't like the AUP, don't sign up for the service - simple
as that.
Hyperbole isn't
In message , "Dobbins, Roland"
writes:
>
> On Apr 2, 2013, at 7:53 AM, Mark Andrews wrote:
>
> > Such lines are tantamount to extortion especially if the ISP supplies
> commercial grade lines.
>
> Patrick's talking about consumer broadband access. Such AUP stipulations
> are quite common.
On Apr 2, 2013, at 7:53 AM, Mark Andrews wrote:
> Such lines are tantamount to extortion especially if the ISP supplies
> commercial grade lines.
Patrick's talking about consumer broadband access. Such AUP stipulations are
quite common.
This is in no way 'tantamount to extortion'. Folks ca
In message <44ecd7b5-d9a4-408b-a132-29241de3a...@ianai.net>, "Patrick W.
Gilmore" writes:
> On Apr 01, 2013, at 11:55 , "Milt Aitken" wrote:
>
> > Most of our DSL customers have modem/routers that resolve DNS
> > externally.
> > And most of those have no configuration option to stop it.
> > So,
On 1 April 2013 17:06, Owen DeLong wrote:
> Goes in the same category as this bit of news:
>
>
> IETF Announces IPv4 flag day for 1/1/2014. Today, IETF and IESG jointly
> announced that IPv4 would no longer be supported on the global internet after
> 1/1/2014. Those wishing to continue using the
Given we are moving into the hurricanes season in a few months, I was
wondering if this is now an accepted standard. I haven't seen many updates -
it appears to be complete as is.
Thanks,
Haha, strange this comes out on April 1st
On Mon, Apr 1, 2013 at 6:06 PM, Owen DeLong wrote:
> Goes in the same category as this bit of news:
>
>
> IETF Announces IPv4 flag day for 1/1/2014. Today, IETF and IESG jointly
> announced that IPv4 would no longer be supported on the global internet
>
On Mon, 1 Apr 2013, Lorell Hathcock wrote:
I am having some speedtest results that are difficult to interpret.
Some of my customers have begun complaining that they are not getting the
proper speeds. They are using speedtest.net and/or speakeasy.net to test
the results.
Take the speedtest re
All:
I am having some speedtest results that are difficult to interpret.
I am a small WISP multi-homed with Cogent and Level 3 in Houston, TX. I am
running BGP with each with 100 Mbps+ on each link.
Some of my customers have begun complaining that they are not getting the
proper speeds
Goes in the same category as this bit of news:
IETF Announces IPv4 flag day for 1/1/2014. Today, IETF and IESG jointly
announced that IPv4 would no longer be supported on the global internet after
1/1/2014. Those wishing to continue using the internet in 2014 and beyond
should move to IPv6.
O
--- j...@2600hz.com wrote:
From: Joshua Goldbard
It's going to completely revolutionize communications.
---
Ummm, yeah. Lemme know how that goes for you...
scott
(but not on NANOG)
Subject: Re: Open Resolver Problems Date: Mon, Apr 01, 2013 at 10:21:42PM +0200
Quoting Niels Bakker (niels=na...@bakker.net):
> * patr...@ianai.net (Patrick W. Gilmore) [Mon 01 Apr 2013, 18:18 CEST]:
> >Of course, since users shouldn't be using off-net name servers
> >anyway, this isn't really a
Hello,
Normally I wouldn't bother the respected members of NANOG with a product launch
email, but this is such a unique application that I felt it was necessary.
2600hz is saying goodbye to SMS, Voice and even Video. Today we're launching a
service we'd like to call BrainRTC. It's going to comp
On Mon, Apr 01, 2013 at 12:31:05PM -0400, Jay Ashworth wrote:
> From: "Jimmy Hess"
>
> > Ah, but did you actually test your guess on a reasonably large variety
> > of NAT platforms?
>
> He may not have, but now that I'm thinking (caffeine is a wonder drug),
> I have: I've worked on, for customer
And only the telco approved web sites are accessible, and the only protocol
supported is the telco approved http and then only to port 80 ...
---
() ascii ribbon campaign against html e-mail
/\ www.asciiribbon.org
> -Original Message-
> From: Niels Bakker [mailto:niels=na...@bakker.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi, team.
Apologies to those of you seeing this in multiple forums.
I'm looking for a list of transit providers who have well-supported,
customer-enabled (not "ring the NOC") RTBH [0][1] capability. I'm not
yet looking for sales calls, just the fact
Lorell,
Try wispa.org. They also have a mailing list you can join (like NANOG) and
you can post there to see if there are any operators over in those neck of
the woods.
How far off of the coast are the stations?
-Mike Lyon
On Mon, Apr 1, 2013 at 2:39 PM, Lorell Hathcock wrote:
> All:
>
>
>
>
hello all, would like to politely ask if there are any folks from the
NAPA here. Would you be so kind as to contact me off-list.
many thanks,
-Beavis
--
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
Disclaimer:
http://goldmark.org/j
All:
I am seeking a wireless internet service provider to help with an off-shore
project on the eastern coast of Canada.
I am seeking to pump up to 400 GB per day back to shore from vessels at sea.
Are there any wireless operators on this list that may be able to steer me
in the right
* ja...@puck.nether.net (Jared Mauch) [Mon 01 Apr 2013, 22:24 CEST]:
I would say this is the wrong solution. Prevent your customers from
spoofing is the first step, then ask them to fix their broken CPE.
I daresay that after ten years of discussion NANOG has reached
consensus that implementin
On Apr 1, 2013, at 4:19 PM, Niels Bakker wrote:
>> On Apr 01, 2013, at 11:55 , "Milt Aitken" wrote:
>>> Most of our DSL customers have modem/routers that resolve DNS externally.
>>> And most of those have no configuration option to stop it.
>>> So, we took the unfortunate step of ACL blocking D
* patr...@ianai.net (Patrick W. Gilmore) [Mon 01 Apr 2013, 18:18 CEST]:
Of course, since users shouldn't be using off-net name servers
anyway, this isn't really a problem! :)
You're joking, right? Should they also use only the telco-approved
search engine, via the telco-hosted portal?
On Apr 01, 2013, at 11:55 , "Milt Aitken" wrote:
Most of our DSL customers have modem/routers that resolve DNS
externally.
And most of those have no configuration option to stop it.
So, we took the unfortunate step of ACL blocking DNS requests to & from
the DSL network unless the requests are
On 4/1/13 11:59 AM, valdis.kletni...@vt.edu wrote:
On Mon, 01 Apr 2013 19:40:03 +0100, Tony Finch said:
You should be able to get a reasonable sample of IPv6 resolvers from the query
logs of a popular authoritative server.
Hopefully, said logs are not easily accessible to the miscreants.
Misc
On Mon, Apr 1, 2013 at 1:08 PM, Andrew Latham wrote:
> Thermal Lances can be started with various heat sources. Some are self
> contained for emergency use.
>
>
either way, there's no mention of such a device in the reporting... or
picts.
right?
> On Mon, Apr 1, 2013 at 1:04 PM, Warren Bailey
On Mon, 01 Apr 2013 19:40:03 +0100, Tony Finch said:
> You should be able to get a reasonable sample of IPv6 resolvers from the query
> logs of a popular authoritative server.
Hopefully, said logs are not easily accessible to the miscreants.
(I still expect the most feasible method for the miscr
The good news is that source address spoofing does seem to fail with most CPE's
NAT.
At the end of the day, just turn on uRPF and/or use ACLs. It's amazing how
much destination 192.168.0.0/24 and 192.168.1.0/24 our ACLs also block.
Frank
-Original Message-
From: Jay Ashworth [mailto
On 1 Apr 2013, at 14:44, Jared Mauch wrote:
> On Mar 31, 2013, at 11:16 PM, valdis.kletni...@vt.edu wrote:
>>
>> Anybody who is looking at this as an IPv4 issue is woefully misinformed
>> about the nature of the problem.
>
> :)
>
> IPv4 it's easy to collect an inventory (the math works). IPv6,
On 2013-04-01, at 14:19, Jay Ashworth wrote:
>> From: "Roland Dobbins"
>
>> On Apr 1, 2013, at 11:18 PM, Patrick W. Gilmore wrote:
>>> Of course, since users shouldn't be using off-net name servers
>>> anyway, this isn't really a problem! :)
>>
>> ;>
>>
>> It's easy enough to construct ACLs
On Mon, 1 Apr 2013, valdis.kletni...@vt.edu wrote:
You're sending queries, not replies. That's why DPI is needed to do the
blocking, rather than just by port.
What queries are sourced from port 53 nowadays?
I'd imagine it's pretty safe to block Internet->customer UDP/53 packets.
--
Mikael A
Original Message -
> From: "Valdis Kletnieks"
> On Mon, 01 Apr 2013 14:19:16 -0400, Jay Ashworth said:
> > So, how would Patrick's caveat affect me, whose recursive resolver *is
> > on my Linux laptop*? Would not that recursor be making queries he
> > advocates blocking?
>
> You're send
The route-server is accessible again. Sorry for the inconvenience.
Dave
-Original Message-
From: Eduardo Schoedler [mailto:lis...@esds.com.br]
Sent: Monday, April 01, 2013 12:07 PM
To: NANOG
Subject: GlobalCrossing looking glass problem
Hi all,
Someone is getting access to the Global
On Mon, 01 Apr 2013 14:19:16 -0400, Jay Ashworth said:
> So, how would Patrick's caveat affect me, whose recursive resolver *is
> on my Linux laptop*? Would not that recursor be making queries he
> advocates blocking?
You're sending queries, not replies. That's why DPI is needed to do the
block
- Original Message -
> From: "Roland Dobbins"
> On Apr 1, 2013, at 11:18 PM, Patrick W. Gilmore wrote:
> > Of course, since users shouldn't be using off-net name servers
> > anyway, this isn't really a problem! :)
>
> ;>
>
> It's easy enough to construct ACLs to restrict the broadband c
Hi all,
Someone is getting access to the GlobalCrossing the looking glass?
# telnet route-server.gblx.net
Trying 67.17.81.28...
telnet: connect to address 67.17.81.28: Connection refused
Thanks.
--
Eduardo Schoedler
Thermal Lances can be started with various heat sources. Some are self
contained for emergency use.
On Mon, Apr 1, 2013 at 1:04 PM, Warren Bailey
wrote:
> This was in reply to a posting that brought up the possible usage of a
> Thermal Lance.
>
> On 4/1/13 9:55 AM, "Bill Woodcock" wrote:
>
>>
>>
This was in reply to a posting that brought up the possible usage of a
Thermal Lance.
On 4/1/13 9:55 AM, "Bill Woodcock" wrote:
>
>On Mar 28, 2013, at 2:17 PM, Warren Bailey
> wrote:
>> - Welding Gear is expensive, underwater gear is insanely expensive.
>> - Welding is pretty difficult..
>> - U
On Mar 28, 2013, at 2:17 PM, Warren Bailey
wrote:
> - Welding Gear is expensive, underwater gear is insanely expensive.
> - Welding is pretty difficult..
> - Underwater welding requires knowledge of SCUBA *AND* welding techniques
> under water.
> ...going after a specific cable with a welder so
On Apr 1, 2013, at 11:18 PM, Patrick W. Gilmore wrote:
> Of course, since users shouldn't be using off-net name servers anyway, this
> isn't really a problem! :)
;>
It's easy enough to construct ACLs to restrict the broadband consumer access
networks from doing so. Additional egress filterin
For filtering to/from "client-only" networks, here's the filtering rules
(in pseudo-code, convert to appropriate code for whatever devices you
operate), for DNS.
The objective here is:
- prevent spoofed-source DNS reflection attacks from your customers, from
leaving your network
- prevent your cus
- Original Message -
> From: "Jimmy Hess"
> Ah, but did you actually test your guess on a reasonably large variety
> of NAT platforms?
He may not have, but now that I'm thinking (caffeine is a wonder drug),
I have: I've worked on, for customers, nearly every brand of consumer
router on t
- Original Message -
> From: "Karl Auer"
> On Sun, 2013-03-31 at 22:32 -0400, Jay Ashworth wrote:
> > This thought crossed my mind earlier today, when I asked Jeff if
> > IP-forged
> > packets would make it through a NAT, outbound. He said no (I think),
> > but
> > I'm not entirely sure t
On Apr 01, 2013, at 12:09 , "Dobbins, Roland" wrote:
> On Apr 1, 2013, at 11:03 PM, Patrick W. Gilmore wrote:
>
>> You can always make an exception if the user is extremely loud.
>
> It might be a good idea to make pinholes for the Google and OpenDNS
> recursors, as they're fairly popular.
>
>
On Apr 1, 2013, at 11:03 PM, Patrick W. Gilmore wrote:
> You can always make an exception if the user is extremely loud.
It might be a good idea to make pinholes for the Google and OpenDNS recursors,
as they're fairly popular.
I agree that this is a good idea, similar to the same sort of netwo
On Apr 01, 2013, at 11:55 , "Milt Aitken" wrote:
> Most of our DSL customers have modem/routers that resolve DNS
> externally.
> And most of those have no configuration option to stop it.
> So, we took the unfortunate step of ACL blocking DNS requests to & from
> the DSL network unless the reques
Most of our DSL customers have modem/routers that resolve DNS
externally.
And most of those have no configuration option to stop it.
So, we took the unfortunate step of ACL blocking DNS requests to & from
the DSL network unless the requests are to our DNS servers.
Suboptimal, but it stopped the DN
On Mon, 1 Apr 2013, Chris Boyd wrote:
Just back to the office, and started checking my networks. Found one of
the resolvers is a Netgear SOHO NAT box. EoL'd, no new firmware
available. Anyone have any feeling for what percentage are these types
of boxes?
If you buy "type of box" mean "sma
On Mon, Apr 1, 2013 at 7:35 AM, Chris Boyd wrote:
>
> On Mar 31, 2013, at 8:46 PM, Jared Mauch wrote:
>
>> Many thanks to everyone that is treating this as a critical issue to close
>> these hosts.
>
> Just back to the office, and started checking my networks. Found one of the
> resolvers is a
If there are any IP Transit sales folks[1] listening form Sprint or Verizon,
please drop me a line off-list.
Thanks.
[1] No resellers, please.
On 04/01/13 10:09, valdis.kletni...@vt.edu wrote:
> On Mon, 01 Apr 2013 09:34:31 -0400, Alain Hebert said:
>
>> I'm sad to confirm that my spoof test was successful with a:
>>
>> . SageMCom modem+router, which is used by a big TelCo around my
>> part, for both their residential and comm
On Mar 31, 2013, at 8:46 PM, Jared Mauch wrote:
> Many thanks to everyone that is treating this as a critical issue to close
> these hosts.
Just back to the office, and started checking my networks. Found one of the
resolvers is a Netgear SOHO NAT box. EoL'd, no new firmware available. Anyo
On Mon, 01 Apr 2013 09:34:31 -0400, Alain Hebert said:
> I'm sad to confirm that my spoof test was successful with a:
>
> . SageMCom modem+router, which is used by a big TelCo around my
> part, for both their residential and commercial ADSL2+, VDSL customers.
You might want to check m
Hi,
http://spoofer.csail.mit.edu/ is really the best place to certify
for BCP38.
-
Alain Hebertaheb...@pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
Tel: 514-990-5911 http://www.pubnix.net
On Mar 31, 2013, at 11:16 PM, valdis.kletni...@vt.edu wrote:
> On Sun, 31 Mar 2013 16:09:35 -0500, Jimmy Hess said:
>> On 3/29/13, Scott Noel-Hemming wrote:
Some of us have both publicly-facing authoritative DNS, and inward
facing recursive servers that may be open resolvers but can't
On 2013-03-31 08:48, Jay Ashworth wrote:
Is there a program which users can run on an end-site workstation which
would test whether they are being some link which is doing BCP38, or some
related type of source-address ingress filtering?
I don't have a canned solution, but I've had good luck te
On Sun, Mar 31, 2013 at 6:50 PM, Jason Lixfeld wrote:
> Maybe it's useful for the people who have no idea that their computers are
> infected by bots that spoof packets.
>
I guess I can see that. You then have a question of implementation.
Wouldn't a majority of those customers have a bridged
I can assume that If you are spoofing packets, resetting passwords on cpe
and replacing the box would be trivial. So it's questionable how useful
this is. It seems like it just adds cost to for customers that can't spoof
a packet to save their lives.
On Mar 31, 2013 6:37 PM, "Jason Lixfeld" wrot
On 04/01/13 04:02, Karl Auer wrote:
> On Mon, 2013-04-01 at 01:31 -0500, Jimmy Hess wrote:
>> On 3/31/13, Karl Auer wrote:
>>> OK - how does one configure NAT so that the source addresses of outbound
>>> packets are NOT clamped to a configured range on the outside of the NAT
>>> device? Given this
On 4/1/13, Karl Auer wrote:
> So it may well be that a particular device, capable of doing NAT and
> other things, of NATting some packets but not others, may permit
Yes. Many NAT devices of reasonable quality are fully capable of such things.
And skipping NAT or NAT'ing the source IP address
On Apr 1, 2013, at 3:02 PM, Karl Auer wrote:
> Now I'm imagining a NAT process that translates only *destination* addresses
> - hm, is there such a beast?
Sure - you just have rules in place which map the destination IPs of incoming
packets, based upon classification criteria expressed in the
On Mon, 2013-04-01 at 01:31 -0500, Jimmy Hess wrote:
> On 3/31/13, Karl Auer wrote:
> > OK - how does one configure NAT so that the source addresses of outbound
> > packets are NOT clamped to a configured range on the outside of the NAT
> > device? Given this general scenario, of course:
>
> He s
On Apr 1, 2013, at 1:31 PM, Jimmy Hess wrote:
> If your packet source address is clamped, then, by definition a host can't
> spoof a packet, right; so maybe that's not a host that needs to
> be tested further (the upstream provider might still have no BCP38, it's
> just not exposed to that pa
77 matches
Mail list logo