Re: COVID-19 vs. our Networks

[Florian Weimer]

* Mike Hammett:

> Netflix recommends 25 megs for Ultra HD, while only 5 megs for
> HD. That's a 5x difference in something people likely won't notice
> and would make a big difference on the additional VPN, VoIP, video
> conferencing, etc.

4K isn't supported by all devices and plans.  I'm not sure what kind
of savings you can actually realize there.  It could be that 4K
content isn't worth caching near the edge.  Then ditching 4K could
still have a significant effect despite relatively low usage by
subscribers.  Similarly anything that reduces content diversity (like
serving only one category of 1080p streams).  Reportedly, the issue is
backhaul capacity for some CDN nodes in Europe, and not capacity from
the local cache to the subscriber, but I do not have any direct
knowledge of that.

Relaxing copyright and patent restrictions might also help, at least
in the medium term.

Re: power to the internet

[Florian Weimer]

* John Levine:

> In article <87y2up1vc4@mid.deneb.enyo.de> you write:
>>I found the connection rather puzzling (that is, how switching off
>>power distribution prevents wildfires or at least reduces their risk).
>>I found some explanations here (downed lines, vegetation contact,
>>conductor slap, repetitive faults, apparatus failures):
>>
>>
>
> Oh, you're in Europe.  You wouldn't believe how cruddy US power
> distribution systems are.  California is particularly bad becuase the
> populist state regulator has keep retail prices low at the cost of
> reliability, safety, and everything else.
>
> Also keep in mind that California has conditions seen nowhere in
> Europe: bone dry forests with 40C temperaturees and 100Kph winds,
> and a power company too underfunded to keep up with tree trimming.

I think Greece also suffered a major wildfire in the 2018 that was
initiated by a faulty power line.  In Germany, we have some vegetation
issues on train lines partially due to insufficient maintenance, but
they fortunately don't trigger wildfires, only train outages.

I guess most countries struggle to maintain basic infrastructure.

Re: power to the internet

[Florian Weimer]

* Jason Wilson:

> This is all in conjunction with the CPUC. I believe it is also a part of a
> court order. I’ll need to find that later
>
> https://www.cpuc.ca.gov/deenergization/

I found the connection rather puzzling (that is, how switching off
power distribution prevents wildfires or at least reduces their risk).
I found some explanations here (downed lines, vegetation contact,
conductor slap, repetitive faults, apparatus failures):

Re: Stupid Question maybe?

[Florian Weimer]

* Baldur Norddahl:

> Why do we still have network equipment, where half the configuration
> requires netmask notation, the other half requires CIDR and to throw you
> off, they also included inverse netmasks.

Some also drop the prefix length in diagnostic output if it matches
that of the address class.  So you still need to know about address
classes, unfortunately.

Re: It's been 20 years today (Oct 16, UTC). Hard to believe.

[Florian Weimer]

* Laszlo Hanyecz:

> On 2018-10-17 02:35, Michael Thomas wrote:
>> I believe that the IETF party line these days is that Postel was wrong 
>> on this point. Security is one consideration, but there are others.
>
> Postel's maxim also allowed extensibility.  If our network code rejects 
> (or crashes) on things we don't currently understand and use, it ensures 
> that they can't be used by apps that come along later either.  The 
> attitude of rejecting everything in the name of security is what has 
> forced app developers to tunnel APIs and everything else inside HTTP/DNS.

To be fair, a lot of these components that make extending protocols
hard are both receivers and senders.  If they are asked to forward
garbage, then something has to give.

Re: It's been 20 years today (Oct 16, UTC). Hard to believe.

[Florian Weimer]

* Scott Brim:

> On Tue, Oct 16, 2018, 22:37 Michael Thomas  wrote:
>
>> I believe that the IETF party line these days is that Postel was wrong
>> on this point. Security is one consideration, but there are others.
>>
>> Mike
>>
>
> I saw just a small swing of the pendulum toward the center, a nuanced
> meaning for "liberal". The adage wasn't tossed out. Operationally it can't
> be.

I think DMARC, as it is deployed right now, pretty much killed the
“liberal” part for many people.  It's sender policy, but it's
necessarily enforced at the recipient end, but many recipients aren't
given a choice to opt out when it is technically the wrong thing to
do.  You can switch email providers, but as the IETF never really
designed for email address portability, that's a theoretical option
only for many.

Re: Whois vs GDPR, latest news

[Florian Weimer]

* Mark Andrews:

> Domain whois is absolutely useful.  Try contacting a site to report
> that their nameservers are hosed without it.

A lot of WHOIS servers do not show who's running the name servers, or
who maintains the data served by them.  Those that do usually provide
information which is provably wrong.

> Remember that about 50% of zones have not RFC compliant name servers
> (the software is broken) and that newer resolver depend on default
> behaviour working correctly.

If WHOIS records were useful for contacting operators, you wouldn't
have to raise these issues on public lists periodically.

Re: Is WHOIS going to go away?

[Florian Weimer]

* Filip Hruska:

> On 04/14/2018 07:29 PM, Florian Weimer wrote:
>> * Filip Hruska:
>>
>>> EURID (.eu) WHOIS already works on a basis that no information about the
>>> registrant is available via standard WHOIS.
>>> In order to get any useful information you have to go to
>>> https://whois.eurid.eu and make a request there.
>>>
>>> Seems like a reasonable solution.
>> Why?  How does the protocol matter?
>>
>> Either you may publish individual personal information for use by the
>> general public, or you may not.  Adding a 4 to the port number doesn't
>> change that.
>>
>
> The EURID webwhois cannot be scraped, there are anti-bot measures in 
> place (captcha, throttling, all information displayed in images).
> Scraping WHOIS systems for thousands domains at once using the WHOIS 
> protocol is easy though. There are "WHOIS History" sites which scrape 
> all domains and then publish the data along with the date of retrieval.
>
> GDPR contains this in relation to the right to erasure:
>
>  1. Where the controller has made the personal data public and is
> obliged pursuant to paragraph 1 to erase the personal data, *the
> controller, taking account of available technology and the cost of
> implementation, shall take reasonable steps, including technical
> measures, to inform controllers which are processing the personal
> data that the data subject has requested the erasure* by such
> controllers of any links to, or*copy or replication of, those
> personal data*.

Wouldn't that require a channel to the recipient of WHOIS data, so
that the controller can notify those who have accessed it once erasure
is requested?

A simple webform doesn't achieve that because it's not much different
from the way traditional WHOIS works.

Re: Is WHOIS going to go away?

[Florian Weimer]

* Filip Hruska:

> EURID (.eu) WHOIS already works on a basis that no information about the 
> registrant is available via standard WHOIS.
> In order to get any useful information you have to go to 
> https://whois.eurid.eu and make a request there.
>
> Seems like a reasonable solution.

Why?  How does the protocol matter?

Either you may publish individual personal information for use by the
general public, or you may not.  Adding a 4 to the port number doesn't
change that.

Re: Cloudflare 1.1.1.1 public DNS broken w/ AT CPE

[Florian Weimer]

* Hank Nussbacher:

> Perhaps they are running all  this to shake out exactly these type of
> issues?  I think that is exactly why APNIC research is called for.

And return another 2**24 addresses to the global IPv4 pool eventually?
That would indeed be a loadable goal.

Re: association between ASN and company name in ARIN region

[Florian Weimer]

* Arnold Nipper:

> On 30.03.2017 17:50, Martin T wrote:
>
>> Is it possible to make a similar connection between AS number and
>> company name in ARIN region? In other words, how do you find out that
>> company is eligible to use AS number?
>> 
>
>
> This doesn't work for you?
>
> whois -h whois.arin.net as174 | egrep

Note that depending on the WHOIS client, this does not work.  The
correct AS number query syntax for whois.arin.net does not include an
“AS” prefix.  The difference is only visibile for AS numbers with in
an AS range object.  14745 is an example that shows the difference.

Re: Microsoft O365 labels nanog potential fraud?

[Florian Weimer]

* Grant Taylor via NANOG:

> On 03/29/2017 04:17 AM, Mel Beckman wrote:
>> Thanks for the very clear explanation. I use DKIM and SPF, but didn't
>> know about this corner case. I'm surprised the SPF, etc architects
>> missed it, or seem to have. In any event, I seem to be getting all
>> the messages.
>
> I don't think they did miss it per say.  SPF is specifically meant to 
> say where senders are allowed to send from.  Mailing lists (in some 
> configurations), forwarders, et. al. (inadvertently) violate this when 
> they re-send the message with the original sender from a 
> not-explicitly-allowed source.
>
> Sender Rewriting Scheme is a way that these forwarding services can 
> re-write the SMTP Envelope From address to not run afoul of SPF (et al).

SPF (in its specified form) is very compatible with the way people
have been running mailing lists since the mid-to-late 90s because the
mailing list specifies itself as the SMTP envelope from address.  This
has the added benefit of enabling bounce processing.

Unfortunately, the envelope from address is used for generating
bounces only.  Mail clients just show the header.  That's why some SPF
variants (like the one proposed by Microsoft) apply SPF rules to email
headers as well, although this wasn't part of the original SPF spec
(because it breaks too much).  DKIM was designed from the start to
(optionally) break mailing lists, and some mail providers now publish
sender domain policies which other mail providers enforce.  In effect,
this requires pervasive header rewriting (within the mailing list
software) before the message can be sent over the mailing list,
obfuscating the true sender.

It's a very unfortunate situation.  The mailing list software could
put the original sender address into a new header, and if that header
is standardized, mail clients could just display that.  But then,
certain sender domains would just sign the absence of that header, and
we are back to square one.  Presumably, we could use a randomized
header, so that at least DKIM protocol changes are required, but it is
basically an arms race at this point.

Re: BCP 38 coverage if top x providers ...

[Florian Weimer]

* Laurent Dumont:

> Wouldn't you want BCP38 policies to be as close as possible to the 
> traffic sources? Instead of creating more "fake" traffic?

Maybe as close as possible, but still without sacrificing source
network attribution is sufficient.

> And at the same time, partial filtering doesn't seem as a very
> effective way to fight spoofed traffic on a large scale.

That depends on the problems caused by spoofed traffic.  My hunch is
that non-policing networks emit a constant trickle of spoofed traffic
which does not cause any problems, and that traffic can be used to
detect lack of policing even without actual abuse of the spoofing
capability.

Re: BCP 38 coverage if top x providers ...

[Florian Weimer]

* Jared Mauch:

>> On Nov 19, 2016, at 9:13 PM, Frank Bulk  wrote:
>> 
>> My google fu is failing me, but I believe there was a NANOG posting a year
>> or two ago that mentioned that if the top x providers would
>> implement BCP 38
>> then y% of the traffic (or Internet) would be de-spoofed.  The point was
>> that we don't even need everyone to implement BCP 38, but if the largest
>> (transit?) providers did it, then UDP reflection attacks could be
>> minimized.
>> 
>> If someone can recall the key words in that posting and dig it up, that
>> would be much appreciated.

> A double lookup of the packet is twice as expensive and perhaps
> impractical in some (or many) cases.

Do you actually have to filter all packets?

Or could you just sample a subset and police the offenders, on the
assumption that if you don't implement an anti-spoofing policy, you
end up with near-constant leakage?

Re: SHA1 collisions proven possisble

[Florian Weimer]

* valdis kletnieks:

> We negotiate a contract with terms favorable to you.  You sign it (or more
> correctly, sign the SHA-1 hash of the document).
>
> I then take your signed copy, take out the contract, splice in a different
> version with terms favorable to me.  Since the hash didn't change, your
> signature on the second document remains valid.
>
> I present it in court, and the judge says "you signed it, you're stuck with
> the terms you signed".
>
> I think that would count as "invalidates documents signed by SHA-1",
> don't you?

The more immediate problem isn't that you get framed, but that someone
is insinuating that you might be framing *them*, i.e. invalidation of
existing signatures etc.

Regarding your original scenario: You have both copies, and it is
possible to analyze them and notice that they were carefully crafted
to exhibit the SHA-1 collision.  So it should be clear that the party
who generated the document is up to to no good, and the question now
is which party is responsible for the doctored document.  This
scenario isn't much different from abusing complex file formats to
render the document differently in different contexts.  There is more
reliable evidence here than there is with your average disputed
pen-and-paper signature.

Automated processing of SHA-1-hashed data might be a problem, though.
For example, a web page generator might skip proper HTML encoding if
the hash of a document fragment has a known SHA-1 (assuming that this
exact fragment has been checked earlier).

Certification signatures (such as those found in X.509 and DNSSEC) are
particularly at risk.  For X.509, CAs can randomize the serial number
and avoid the shared prefix, which stops these attacks AFAIK.  For
DNSSEC, you probably should verify that the DS records are meaningful
before signing the DS RRset.  If I recall correctly, there is no good
way to inject randomness early into the signed data, maybe except
using invalid DS records which get sorted first.

Re: backbones filtering unsanctioned sites

[Florian Weimer]

* > On Friday, 17 February, 2017 08:29, "Florian Weimer" <f...@deneb.enyo.de> 
said:
>
>> Of course they do, see the arrest of Augusto Pinochet.
>
> Universal Jurisdiction is supposed to cover the likes of war crimes,
> torture, extrajudicial executions and genocide, that are generally
> agreed to be crimes against humanity as a whole, regardless of where
> they take place.  Much as the copyright cartel would like to put any
> (perceived) loss of revenue into the same bracket, are you *really*
> advocating that copyright infringement belongs in that list?

I think the Spanish prosecutor claimed at the time that crimes were
committed against Spaniards, too.  So it's not quite a case of
absolute universal jurisdiction.  Assuming that Spanish copyright
holders sought the court order, the situation isn't too different.

>> Due to the nature of mass copyright violation, it is likely that these
>> sites violate the rights of Spanish copyright holders, and if such a
>> violated party obtains a court order against an ISP, I see no reason
>> why the violations should go on everywhere except Spain.
>
> The action isn't against the people infringing copyright, the sites
> (arguably) aiding them in infringing copyright, or even the company
> providing hosting services to those sites.  It is, if the situation is
> being reported correctly, forcing a connectivity provider to block
> access to some elements of the hosting services *worldwide* based on
> the fact that it operates in one country.  In my view, both far too
> many steps removed from the offence, and, more importantly,
> overly-broad in impact.

There can be some debate whether a transit ISP should be subject to
such an injunction, rather than a party closer to the source.  But I
don't see why if a Spanish court determines that Spanish law requires
compliance by the ISP, the blocking order should be restricted to
Spain.  The rights are violated everywhere, after all.

Sometimes, global compliance is just a cost of doing business locally.

> Do you think the Chinese government should be able to force any voice
> provider operating in China to block any of their customers, anywhere
> in the world, from talking about Taiwan as an independent country?
>
> Do you think the Iranian government should be able to force any mobile
> phone company operating in Iran to implement a worldwide ban of
> Pokemon Go?
>
> If the answer to either of those questions is "no", can you explain
> why the jurisdiction should be limited in these cases, but not for
> Spanish copyright holders?

Iranian law appears to require permission for running nation-wide
games, not games around the globe.  Similarly, I doubt that Chinese
law has a legal basis for demanding filtering of voice calls, but it's
difficult to find confirmation for that.  (I believe that a lot of
service bans in China are enacted by the government upon encouragement
from would-be competitors, but that does not make such bans legal
according to Chinese law.)

So the difference is that your hypothetical scenarios violate local
laws.

Re: backbones filtering unsanctioned sites

[Florian Weimer]

* Todd Crane:

> I am not familiar with Cogent’s architecture but why couldn’t they
> just null route the IP address at their edge routers from within
> Spain? I am not a lawyer but from what I understand, since the Spanish
> government has zero say on what goes on outside of their borders,

Of course they do, see the arrest of Augusto Pinochet.

Due to the nature of mass copyright violation, it is likely that these
sites violate the rights of Spanish copyright holders, and if such a
violated party obtains a court order against an ISP, I see no reason
why the violations should go on everywhere except Spain.

Re: backbones filtering unsanctioned sites

[Florian Weimer]

* Jared Mauch:

> So risk avoidance on the part of the 100k other sites hosted by CF is
> now a conspiracy?

Conspiracy is perhaps a bit too strong, but I would be annoyed if
someone took my business, but then deliberately undermined the service
they provide.  Of course, if it's all part of the agreement, it's
fine, but if it is not, it certainly looks like a crass net neutrality
violation.

Re: backbones filtering unsanctioned sites

[Florian Weimer]

* Andrew Paolucci:

> Can anyone with a Cogent connection in Canada verify that they are
> impacted as well?

I think it's global.  I tried sites in Canada and Germany, and the
traces look like deliberate blocking of /32s.  I don't have a BGP view
for these sites, though.

Why wouldn't it be global?  If someone forces their hands, ISPs aren't
shipping companies and can pick and choose where they comply.

Re: pay.gov and IPv6

[Florian Weimer]

* Mark Andrews:

> The DNSSEC testing is also insufficient.  9-11commission.gov shows
> green for example but if you use DNS COOKIES (which BIND 9.10.4 and
> BIND 9.11.0 do) then servers barf and return BADVERS and validation
> fails.  QWEST you have been informed of this already.
>
> Why the hell should validating resolver have to work around the
> crap you guys are using?

The protocol doesn't have proper version negotation, and again and
again, implementers have tried to force backwards-incompatible
implementations on the Internet at large.

Re: OSPF vs ISIS - Which do you prefer & why?

[Florian Weimer]

* Mark Tinka:

> I've given a talk about this a couple of times since 2008. But our
> reasons are to choosing IS-IS are:

Has the name been a problem for you?  Asking vendors about support
must be a bit awkward these days.

Re: Death of the Internet, Film at 11

[Florian Weimer]

* Randy Bush:

>> What does BCP38 have to do with this?
>
> nothing technical, as these iot attacks are not spoofed.

How do you know?  Has anyone disclosed specifics?

I can understand that keeping details under wraps is sometimes
required for operational security, but if the attacks are clearly
succeeding, I would have expected those who posted “do something,
now!” messages at least some pointer to technical details of what was
going on.

Not that the underlying threat will go away until we find a way to
clean up almost all of the compromised devices (and without breaking
the Internet along the way, forever).

Re: Death of the Internet, Film at 11

[Florian Weimer]

* Keith Medcalf:

> On: Saturday, 22 October, 2016 17:41, Jean-Francois Mezei
>  wrote:
>
>> On 2016-10-22 19:03, Keith Medcalf wrote:
>  
>> > This does not follow and is not a natural consequence of sealing the
>> little buggers up so that they cannot affect the Internet
>  
>> Problem is that many of these gadgets want to be internet connected so
>> mother at work can check on her kids at home, start the cooking, raise
>> thermostat etc.
>
> This does not require that the devices be open to the Internet, nor
> does it require that they are under the control of an Internet based
> controller.

How would you know?

It is perfectly reasonable to send a notification to a device by
making a TCP connection to it.  This is the way the Internet was
built.  You are not expected to sign a contract with the network
operator for the target device before you can establish a connection
to the device.

The possibility of denial-of-service attacks is not a sufficient
reason to change that model.

Re: Death of the Internet, Film at 11

[Florian Weimer]

* David Conrad:

> Maybe (not sure) one way would be to examine your resolver query logs
> to look for queries for names that fit domain generation algorithm
> patterns, then tracking down the customers/devices that are issuing
> those queries and politely suggest they remove the malware on their
> systems?

Where would interested operators get that information?

Would this include information how to identify those devices which
participated in the CCTV-based botnet which allegedly took part in the
recent attacks?

Re: Dyn DDoS this AM?

[Florian Weimer]

* Randy Bush:

> anyone who relies on a single dns provider is just asking for stuff such
> as this.

Blaming the victim isn't helpful.  And without end-user-visible
changes, most of the victims would still depend on Verisign as a
single provider for a critical part of their DNS service.

Re: IoT security, was Krebs on Security booted off Akamai network

[Florian Weimer]

* John R. Levine:

> On Sun, 9 Oct 2016, Florian Weimer wrote:
>
>> If we want to make consumers to make informed decisions, they need to
>> learn how things work up to a certain level.  And then current
>> technology already works.
>
> I think it's fair to say that security through consumer education has
> been a failure every time anyone has tried it.  Why do you think this
> would be any different?

People start to care once they have to.  Currently, there is not much
reason to worry about which devices you connect to your home network.
Even the interaction with Internet banking appears to be benign these
days.

If your Internet connection goes down because something starts spewing
packets, you can probably find it by disconnecting everything until
you have found the culprit.  It's probably not much different from how
you find which device triggers the breaker.

Anything that's more proactive requires some level of knowledge, and
if we assume that it cannot be dispersed to consumers, then it means
someone else gets to manage their home networks.  And I'm not sure if
the ISPs should be doing this (or if they want any part in this, maybe
except if it enables them to charge per connected device and
function).

>> There is little interest in this, however.  There's a comparable
>> business case for providing managed PCs to consumers, and I'm not sure
>> if any such companies are still left.
>
> There's at least two large ones: Microsoft and Apple.  Try installing
> Windows 10 without letting Microsoft update and reconfigure the
> software any time they want, any way they want.

I don't think I can phone Microsoft if something goes wrong.  In most
countries, they even disclaim responsiblity for breakage introduced by
updates and point to the PC makers instead (from whom most consumers
baught their OEM version).

Apple may be different.

> Expecting consumers to evaluate the security behavior of their
> lightbulbs and their refrigerator is absurd.  We need to figure out
> how to have the devices and routers configure themselves so the
> devices can do what they need to do without doing what we really don't
> want them to do.

We already have UPnP.  Clearly, it does not work, but it's not obvious
to me why any different solution would end up as being just as
ineffective.

Re: Krebs on Security booted off Akamai network after DDoS attack proves pricey

[Florian Weimer]

* Eliot Lear:

> Not my end goal.  My end goal is that consumers have a means to limit
> risk in their home environments, and service providers have a means to
> deliver that to them.

They already have, with today's technology.  It's just not a
mass-market business.  Consumers either have to educate themselves
(which is not that hard), and service providers need to provide actual
service, instead charging a fee for access to a computer system.

There is little interest in this, however.  There's a comparable
business case for providing managed PCs to consumers, and I'm not sure
if any such companies are still left.

>> I'm not convinced that expected traffic profiles are the right answer.
>> We already have that in the server hosting market, and it does
>> constraint the types of services you can run on hosted servers (for
>> the hosting providers who does this).  I'm wary of the network putting
>> severe constraints on application architecture, way beyond what is
>> dictated by current technology.  NAT more or less killed servers on
>> consumer networks, and this kind of traffic profiling has begun to
>> kill clients on server networks.
>
> The whole point of MUD is to leave control in the hands of those who
> have developed and have to support Things.  It is not simply for the SP
> to decide what traffic is ok, or to charge more for it, but to respect
> the wishes of the developers.  That may be sufficient to stop a lot of
> bad things from happening to a lot of Things.

Nobody respects what developers want, otherwise we wouldn't have any
shipping products at all.

What I'm trying to say: Cutting corners is more often a
non-development decision.  If you can ship today without any security,
or at some unknowable date in the future, with additional security
features whose impact may not matter, things usually head for the
earlier shipping date.

I used to be frustrated by such decisions, but over the past few
years, I've come to realize that most of us have so little data on the
effectiveness of security features that mandates for them are
essentially arbitrary.

> And again, this is the wrong way to look at it.  The consumer should
> always get final say.  They're the customer.  This is a chance for the
> manufacturer of the device they're using to explain how the device is
> supposed to behave on the network.

If we want to make consumers to make informed decisions, they need to
learn how things work up to a certain level.  And then current
technology already works.

(Sorry that I'm not inclined to read upon the specs—I do wonder how
this an improvement over UPnP.)

Re: Questions re: VPN protocols globally

[Florian Weimer]

* Valdis Kletnieks:

> On Wed, 05 Oct 2016 12:06:07 -0400, Eric Germann said:
>
>> Customers will connect to their respective regional sites separately.
>> Any ITAR concerns there?
>
> If there are serious concerns there, I recommend spending the coin for
> an actual ITAR expert.

Right.  I *think* it is possible to pull this off, but I expect that
you have to file some paperwork, and doing that without proper
training and knowledge of the applicable guidelines seems way too
risky.

(There isn't just ITAR.  Local regulations apply as well.)

Re: nested prefixes in Internet

[Florian Weimer]

* Martin T.:

> Florian:
>
>> Are the autonomous systems for the /19 and /24 connected directly?
>
> Yes they are.

Then deaggregation really isn't necessary at all.

>> (1) can be better from B's perspective because it prevents certain
>> routing table optimizations (due to the lack of the covering prefix)
>
> What kind of routing table optimizations are possible if covering /19
> prefix is also present in global routing table?

The /24 prefix could arguably be dropped and ignored for routing
decisions.

Re: Legislative proposal sent to my Congressman

[Florian Weimer]

* Lyndon Nerenberg:

>> In thinking over the last DDos involving IoT devices, I think we
>> don't have a good technical solution to the problem.  Cutting off
>> people with defective devices they they don't understand, and have
>> little control over, is an action that makes sense, but hurts the
>> innocent.  "Hey, Grandma, did you know your TV set is hurting the
>> Internet?"
>
> The way this will get solved is for a couple of large ISPs and DDoS
> targets to sue a few of these IoT device manufacturers into oblivion.

But that does not remove those devices from the network.

Re: Request for comment -- BCP38

[Florian Weimer]

* Jay R. Ashworth:

> - Original Message -
>> From: "Florian Weimer" <f...@deneb.enyo.de>
>
>> * Jason Iannone:
>
>>> Are urpf and bcp38 interchangeable terms in this discussion?  It seems
>>> impractical and operationally risky to implement two unique ways to dos
>>> customers.  What are the lessons learned by operators doing static output
>>> filters, strict urpf, or loose/feasible urpf?
>> 
>> Historically (in 1998, when RFC 2267 was released), BCP 38 was an
>> egress filter applied at the AS boundary.
>
> You meant ingress, no?

It's a bit murky.  Section 4 suggests that it's not possible to apply
ingress filters on dialup access concnetrators.

> The control of the address space allocation resides with the upstream,
> as must control of the filtering.

That's not really true for customers who maintain their own routes and
IP assignments/allocations.

> You *can* do BCP38 egress filtering on your network, but that filter
> would *be in control of the Bad Guys* whom we're trying to kill off.

If you can't do ingress filtering (e.g. you do not give customers
dedicated physical ports, or the equipment does not allow tying ports
to specific IP addresses), egress filtering is surely better than
nothing at all.

In theory, it would not matter because the other side should have a
matching ingress filter.  In practice, egress filtering would make a
significant difference in traceability of attacks.  Any additional
filtering would do so.

Again, the goal should not be to deploy specific techonology in a
certain way, but to reduce spoofing and attacks which cannot be traced
back to the packet sources.

Re: Krebs on Security booted off Akamai network after DDoS attack proves pricey

[Florian Weimer]

* Roland Dobbins:

> On 27 Sep 2016, at 12:17, Sam Silvester wrote:
>
>> or call their electricity retailer/distributer
>
> This is the problematic case that is, unfortunately, the default.
>
> People tend to view anything related to 'the Internet' as a utility,
> and for consumers and SMBs, they typically have a single provider,
> just as they typically do for electricity and water.

Most people over here have at least two providers of water and
Internet (although the second one is perhaps sufficient for brushing
your teeth, but certainly not for a shower or a bath).

Re: nested prefixes in Internet

[Florian Weimer]

* Martin T.:

> let's assume that there is an ISP "A" operating in Europe region who
> has /19 IPv4 allocation from RIPE. From this /19 they have leased /24
> to ISP "B" who is multi-homed. This means that ISP "B" would like to
> announce this /24 prefix to ISP "A" and also to ISP "C". AFAIK this
> gives two possibilities:
>
> 1) Deaggregate /19 in ISP "A" network and create "inetnum" and "route"
> objects for all those networks to RIPE database. This means that ISP
> "A" announces around dozen IPv4 prefixes to Internet except this /24
> and ISP "B" announces this specific /24 to Internet.
>
> 2) ISP "A" continues to announce this /19 to Internet and at the same
> time ISP "B" starts to announce /24 to Internet. As this /24 is
> more-specific than /19, then traffic to hosts in this /24 will end up
> in ISP "B" network.
>
>
> Which approach is better?

Are the autonomous systems for the /19 and /24 connected directly?  If
they are, (2) is better from a global view (because it needs fewer
routing table entries).  (1) can be better from B's perspective
because it prevents certain routing table optimizations (due to the
lack of the covering prefix).  But (1) can also be worse for B and A's
other customers if /24s (and slightly shorter prefixes) in this part
of the IPv4 address space are commonly filtered.

Re: Request for comment -- BCP38

[Florian Weimer]

* Stephen Satchell:

> Given a single local inside network with:
>   * multiple uplink providers (typical multi-home situation)
>   * multiple edge routers, each connected to an upstream via a public
> routeable /30, and each further connected to the downstream inside
> network
>   * 50 subnets (to pick a number) of routeable IP address space
> downstream from the edge routers, with routing announcements to the
> world that direct packets back to the edge routers
>
> BCP38 demands that ANY packet leaving ANY edge router to the upstream
> MUST have a source address:
>   * within the 50 inside public route-able subnets, or
>   * within a list of "my" addresses in the public /30 subnets.
>
> True statement?

This depends on the agreements with the upstream providers.  They
might reasonably exclude their own /30 they provided to you and the
/30s from the other providers.

In general, packets from the /30s would not travel far anyway because
they would wail source address verification checks at the upstream
provider.  Some providers also use globally unique, but unrouted
addresses for transfer networks, for infrastructure protection
purposes.

Re: Request for comment -- BCP38

[Florian Weimer]

* Jason Iannone:

> I have a question regarding language. We've seen bcp38 described as a
> forwarding filter, preventing unallocated sources from leaving the AS.  I
> understand that unicast reverse path forwarding checks support bcp38, but
> urpf is an input check with significant technical differences from output
> filters.
>
> Are urpf and bcp38 interchangeable terms in this discussion?  It seems
> impractical and operationally risky to implement two unique ways to dos
> customers.  What are the lessons learned by operators doing static output
> filters, strict urpf, or loose/feasible urpf?

Historically (in 1998, when RFC 2267 was released), BCP 38 was an
egress filter applied at the AS boundary.  A complainant would be able
to identify the AS by looking at the IP address and contact the
relevant ISP.  Within the AS, that ISP could identify the actual
packet source by other means.

Reverse-path forwarding checks were explicitly ruled out as likely
infeasible even in RFC 2267, except for links which are essentially
dialups.

Current terminology is more complicated.  Personally, I think that
mandating specific approaches such as BCP 38 or uRPF does not work.
The goal should be to cut down spoofed traffic.  Whether this is done
by contracts (which are adhered to, obviously), monitoring or
immediate technical enforcement in the routers, does not matter at all.

> For a new implementation, I assume the safe bet is to start with loose
> urpf.  Even if it stops only some traffic it at least gives the network to
> dip its toes and expose some customer brokenness.

If loose uRPF is effective at all depends a lot on network architecture.

Re: Krebs on Security booted off Akamai network after DDoS attack proves pricey

[Florian Weimer]

* Eliot Lear:

> As some on this thread know, I've been working with the folks who make
> light bulbs and switches.  They fit a certain class of device that is
> not general purpose, but rather are specific in nature.  For those
> devices it is possible for the manufacturers to inform the network what
> the communication pattern of the device is designed to be.  This may be
> extraordinarily broad or quite narrow, depending on the device. 
> Conveniently, the technology for describing much of this dates back to
> the paleolithic era in the form of access lists.  That is what
> manufacturer usage descriptions are about.  (Yep- MUD.  There go my
> marketing credentials). They're slightly abstracted for adaptation to
> local deployments.   There's a draft and we authors are soliciting comments.

What's the end goal here?  Charge extra if I'm connecting a TV instead
of a light bulb?

I'm not convinced that expected traffic profiles are the right answer.
We already have that in the server hosting market, and it does
constraint the types of services you can run on hosted servers (for
the hosting providers who does this).  I'm wary of the network putting
severe constraints on application architecture, way beyond what is
dictated by current technology.  NAT more or less killed servers on
consumer networks, and this kind of traffic profiling has begun to
kill clients on server networks.

> The service providers has a strong role to play here, since they drive
> standards for connectivity.  Having some access to residential CPE in
> particular for this purpose, I believe, is very helpful because by doing
> so not only can SPs protect others, but can also provide lateral
> protection within the home.  As I wrote upthread, if consumers come to
> see smart lightbulbs not just as useful, but also as a concern, they may
> wish their SPs to help them.  That's the internalizing of an externality
> that I see possible, and maybe even probable over time.

Most service providers appear to be struggling to maintain up-to-date
software on their CPEs (and their infrastructure), and following
recommended configuration practices as they evolve.  This does not
give me confidence that they could perform device management at
consumer scale.

Do we know how much the average consumer trusts their ISP?  Would they
want their ISP to control the digital (and increasingly, physical)
doors in their home?  My own outlook is rather biased, unfortunately.

Re: Krebs on Security booted off Akamai network after DDoS attack proves pricey

[Florian Weimer]

* Mark Andrews:

> Dear customer,
>we are seeing  traffic coming from your network.
>
> If you need help isolating the source of the traffic here are a few
> companies in your city that can help you.
>
>   
>
> This is not a exhaustive list.
>
> Support

We already had the problem in the past that customer notifications for
compromised machines (with confirmed loss of user data, not just
sourcing unexpected packets) looked like advertisements for antivirus
products.  To most customers, this looks like just another scam.

Re: Request for comment -- BCP38

[Florian Weimer]

* Baldur Norddahl:

> This means we can receive some packet on transit port A and then route out
>>> a ICMP response on port B using the interface address from port A. But
>>> transit B filters this ICMP packet because it has a source address
>>> belonging to transit A.
>> Interesting.  But this looks like a feature request for the router
>> vendor, and not like an issue with BCP 38 filtering as such.
>
> Can you quote an RFC for anything that the router is doing wrong? Is
> there a requirement that a router must support source routing?

It's not an RFC conformance issue (several implementations of source
address selection are possible).  But it appears to make it rather
difficult to configure it in such a way it does what you need, and it
looks like a reasonable enhancement request.

> In our case we actually did contact the vendor. Turns out that it will
> do source routing but not for packets from the control plane. There is
> no way to resolve the issue with the current software available to
> us. The vendor is not priotizing fixing this as I am also unable to
> point to any RFC that is being violated.

Source routing is not required to fix this.  Other options are using a
globally routed IP address for the source address (this can also be
used to conserve address space because the interface addresses will
not matter anymore), or chosing the interface address based on the
outgoing interface.

Re: Request for comment -- BCP38

[Florian Weimer]

* Baldur Norddahl:

> Den 26. sep. 2016 18.02 skrev "Mike Hammett" :
>>
>> The only asymmetric routing broken is when the source isn't in public
> Internet route-able space. That just leaves those multi-ISP WAN routers
> that NAT it.
>
> Some of our IP transits implement filtering. All of our transits assigned
> /30 subnets on the transit ports from their own range (the alternate would
> have be to ask us to supply the /30 from our pool).
>
> Our provider edge router will send back ICMP packets using the interface
> address from the interface that received the original packet. It will then
> route the packet using our normal routing table.
>
> This means we can receive some packet on transit port A and then route out
> a ICMP response on port B using the interface address from port A. But
> transit B filters this ICMP packet because it has a source address
> belonging to transit A.

Interesting.  But this looks like a feature request for the router
vendor, and not like an issue with BCP 38 filtering as such.

> From this follows that BCP38 can break things like traceroute and path MTU
> discovery in what is a very common setup.

That doesn't follow.  In order to break PMTUD, you also need an MTU
drop.  Is that a common configuration for routers in points in the
network where this would matter?

Re: CDN Overload?

[Florian Weimer]

* Jon Lewis:

> This is kind of a funny problem though, because CDNs get paid to
> deliver data, and they get compared/graded according to who can
> deliver the bits the fastest...and here you are complaining that
> they're delivering the bits too fast (or at least faster than you'd
> like them to).

Surely CDNs bill packets which are subsequently dropped by the
network. :)

Re: PlayStationNetwork blocking of CGNAT public addresses

[Florian Weimer]

* Rich Kulawiec:

> On Sun, Sep 18, 2016 at 03:56:30PM +0200, Florian Weimer wrote:
>> * Rich Kulawiec:
>> 
>> > For example: if the average number of outbound SSH connections
>> > established per hour per host across all hosts behind CGNAT is 3.2,
>> > and you see a host making 1100/hour: that's a problem.  It might be
>> > someone who botched a Perl script; or it might be a botted host
>> > trying to brute-force its way into something.
>> 
>> If you do this, you break Github.
>
> 1. I didn't know that: *how* does this break Github?

Github users create several orders of magnitude more SSH connections
than average users because the most convenient way to set up
read/write access is to use SSH.  Depending on how you use Github, you
might update lots and lots of local repositories from Github at
certain times of the day.

> 2. This is just an *example* of how to use the technique.  It's not
> meant to be literal.  The general approach of determining the statistical
> characteristics of "normal" and then flagging things that are "way
> outside normal" works -- but of course it requires sufficient knowledge
> to account for things like Github usage and/or infrequent events and/or
> usage spikes triggered by real-world events, etc.

Sure, and people already do this, and are not very flexible about it.
Support staff isn't briefed, and claim they do such stochastic
behavior adjustment across all (server) products, which I find
difficult to believe.

I'm worried that this leads to a future where tunnelling everything
over HTTP(S) is no longer sufficient.  You have to make it look like a
web server or browser, too.  Everything else risks triggering
automated countermeasures.

That's the anti-thesis of good protocol design.

Re: PlayStationNetwork blocking of CGNAT public addresses

[Florian Weimer]

* Simon Lockhart:

> On Sun Sep 18, 2016 at 03:58:57PM +0200, Florian Weimer wrote:
>> * Tom Beecher:
>> > Simon's getting screwed because he's not being given any information to try
>> > and solve the problem, and because his customers are likely blaming him
>> > because he's their ISP.
>> 
>> We don't know that for sure.  Another potential issue is that the ISP
>> just cannot afford to notify its compromised customers, even if they
>> were able to detect them.
>
> I'd like to think that we're pretty responsive to taking our users offline
> when they're compromised and we're made aware of it - either through our own
> tools, or through 3rd party notifications.

Okay, then perhaps my guess of the ISP involved is wrong.

> The process with Sony goes something like:
>
> - User reports they can't reach PSN
> - We report the Sony/PSN, they say "Yes, it's blocked because that IP attacked
>   us"
> - We say "Okay, that's a CGNAT public IP, can you help us identify the which
>   inside user that is - (timestamp,ip,port) logs, or some way to identify the
>   bad traffic so we can look for it ourselves"
> - Sony say no, either through silence, or explicitly.
> - We have unhappy user(s), who blame us.

Yes, that's not very constructive.

Out of curiosity, how common is end-to-end reporting of
source/destination port information (in addition to source IP
addresses and destination IP addresses)?  Have the anti-abuse
mechanisms finalyl caught on with CGNAT, or is it possible that the
PSN operator themselves do not have such detailed data?

Re: PlayStationNetwork blocking of CGNAT public addresses

[Florian Weimer]

* Tom Beecher:

> An email to a user notifying them they're likely compromised costs
> basically nothing.

If this increases the probability that the customer contacts customer
support, in some markets, there is a risk that the account will never
turn profitable during the current contract period.  (Granted, my
information may be woefully out of date, but my impression is that
price-based competition is still pretty much cut-throat over here.)

> If you find me an ISP that can't afford to notify users, I'll show
> you one that shouldn't be in business anyways.

I'm not blaming the ISP.  (I may have done so in the past.)  If we end
up in such a situation, it's hardly the fault of one single ISP.

> There's this presumption of guilt here, that Sony is right, and Simon's
> subscribers are doing something malicious, yet they won't provide any
> evidence of that. Even if they didn't know what it was, come back with
> 'We're seeing weird bursts of [traffic characteristics] aimed at PSN during
> these times. We're not quite sure what it is, but it's causing [problem
> X].' It would still be a question of maliciousness or not, but it would be
> something to work with. Providing nothing just perpetuates this finger
> pointing game, and nothing gets solved.

Yes, indeed.  Resolving most networking problems needs cooperation,
because at the most basic level, the Internet is still about
connecting otherwise unrelated networks.

Re: PlayStationNetwork blocking of CGNAT public addresses

[Florian Weimer]

* Tom Beecher:

> Simon's getting screwed because he's not being given any information to try
> and solve the problem, and because his customers are likely blaming him
> because he's their ISP.

We don't know that for sure.  Another potential issue is that the ISP
just cannot afford to notify its compromised customers, even if they
were able to detect them.

Re: PlayStationNetwork blocking of CGNAT public addresses

[Florian Weimer]

* Rich Kulawiec:

> For example: if the average number of outbound SSH connections
> established per hour per host across all hosts behind CGNAT is 3.2,
> and you see a host making 1100/hour: that's a problem.  It might be
> someone who botched a Perl script; or it might be a botted host
> trying to brute-force its way into something.

If you do this, you break Github.

(If I guess Simon's network correctly, then I've seen reports which
suggest that they might already be doing this.)

Re: "Defensive" BGP hijacking?

[Florian Weimer]

* Mel Beckman:

> If we can't police ourselves, someone we don't like will do it for us. 

That hasn't happened with with IP spoofing, has it?  As far as I
understand it, it is still a major contributing factor in
denial-of-service attacks.  Self-regulation has been mostly
unsuccessful, and yet nothing has happened on the political level.

Re: Zayo Extortion

[Florian Weimer]

* Chris Knipe:

> Although a company that can't manage their book keeping properly, is IMHO
> enough reason to not use them... :-)

Ther used to be a saying that you could choose between carries with
functional billing and carriers with a functional network.

Re: NIST NTP servers

[Florian Weimer]

* Chris Adams:

> First, out of the box, if you use the public pool servers (default
> config), you'll typically get 4 random (more or less) servers from the
> pool.  There are a bunch, so Joe Random Hacker isn't going to have a
> high chance of guessing the servers your system is using.

A determined attacker will just run servers in the official pool.

Re: Why the US Government has so many data centers

[Florian Weimer]

* Sean Donelan:

> When you say "data center" to an ordinary, average person or reporter;
> they think of big buildings filled with racks of computers.  Not a
> lonely server sitting in a test lab or under someone's desk.

I suspect part of the initiative is to get rid of that mindset, which
leads to such gems as “we don't have any servers, so we only need to
secure our clients”.

Re: Why the US Government has so many data centers

[Florian Weimer]

* Mark T. Ganzer:

> Note that I an not answering in any sort of "official" capacitybut
> I will instead ask this for your consideration:  Do servers in "test,
> stage, development, or any other environment" really need to have the
> same environmental, power and connectivity requirements that
> "production" servers have?

Depends on the process.  If you can push to production without pushing
to stage first, then stage and production need the same service level.

Re: Is it normal for your provider to withhold BGP peering info until the night of the cut?

[Florian Weimer]

* William Herrin:

> On Thu, Jan 21, 2016 at 4:26 PM, c b  wrote:
>> We have 4 full-peering providers between two data centers. Our
>> accounting people did some shopping and found that there was
>> a competitor who came in substantially lower this year and
>> leadership decided to swap our most expensive circuit to the new carrier.
>
> That's the first mistake. Internet w/ BGP is not a mass-market
> service. Accounting people have no business searching out highly
> technical custom products and services.

I guess that's why so many customers keep paying for circuits that
have long been shut down. :)

Re: Android (lack of) support for DHCPv6

[Florian Weimer]

* Lorenzo Colitti:

 I think what I said is that supporting DHCPv6-only networks will eventually
 force OS manufacturers to implement IPv6 NAT. This is because there are
 many features inside a mobile OS that require multiple IP addresses.

On many networks, there will be fairly tight limits on the number of
usable addresses per “port” even with SLAAC, similar to the evolution
of Ethernet switching, which led to configurable limits of MAC
addresses per port.  So you'll likely need IPv6 NAT in the future
anyway.

Re: Anyone from Cloudflare ? (IPv6 issue)

[Florian Weimer]

* Brandon Applegate:

 Otherwise - if anyone could share a way to get to clue @Cloudflare I
 would greatly appreciate it.  I put a request in through the web
 support front door, but I got back about what I expected.

Did you receive a reply?

I tried to notify security@ about some issue, but never heard back
from them.

Re: How our young colleagues are being educated....

[Florian Weimer]

* Valdis Kletnieks:

 On Mon, 22 Dec 2014 04:13:42 -0500, Javier J said:

 student graduates. They are teaching classful routing and skimming over
 CIDR. Is this indicative of the state of our education system as a whole?

 Did the standard packaged Cisco curriculum finally drop mention of
 Class A/B/C and go CIDR?

Has the output format been changed so that you do not know about
address classes anymore?

Re: Marriott wifi blocking

[Florian Weimer]

* Jay Ashworth:

 It is OK for an enterprise wifi system to make this sort of attack
 *on rogue APs which are trying to pretend to be part of it (same
 ESSID).

What if the ESSID is Free Internet, or if the network is completely
open?  Does it change things if you have data that shows your
customers can be duped even by networks with a non-colliding ESSID?

Re: DMARC - CERT?

[Florian Weimer]

* Christopher Morrow:

 I sort of wonder if this is really just yahoo trying to use a stick to
 motivate people to do the right thing?

But what is the right thing here?

Do we really want that *all* mailing lists must not provider reply to
sender option to all their users?  Will this list make the change?
Probably not.

Re: Requirements for IPv6 Firewalls

[Florian Weimer]

* Simon Perreault:

 Le 2014-04-18 13:25, Mike Hale a écrit :
 I agree with Bill.  You can poopoo NAT all you want, but it's a fact
 of most networks and will continue to remain so until you can make a
 compelling case to move away from it.

 Does that mean all IPv6 firewalls should support NAT?

In the sense that they MUST be able to provide email filtering
features: yes.

 Remember, we're aiming for a base set of requirements applying to
 all IPv6 firewalls.

The document has more than just base requirements.

Re: US to relinquish control of Internet

[Florian Weimer]

* John R. Levine:

 Let's hope you're right, but I note that the ITU isn't an
 inter-governmental organization,

It was able to obtain a delegation for ITU.INT, so it's
inter-governmental enough in DNS terms.

Re: best practice for advertising peering fabric routes

[Florian Weimer]

* Patrick W. Gilmore:

 NEVER EVER EVER put an IX prefix into BGP, IGP, or even static
 route. An IXP LAN should not be reachable from any device not
 directly attached to that LAN. Period.

 Doing so endangers your peers  the IX itself. It is on the order of
 not implementing BCP38, except no one has the (lame, ridiculous,
 idiotic, and pure cost-shifting BS) excuse that they can't do
 this.

Any ideas why DE-CIX doesn't enforce this?

One advantage is that IXP participants can perform emergency
maintenance if they have isolated their IXP router from their own
network.

Re: NSA able to compromise Cisco, Juniper, Huawei switches

[Florian Weimer]

* Randy Bush:

 Clay Kossmeyer here from the Cisco PSIRT.

 shoveling kitty litter as fast as you can, eh?

 http://tools.cisco.com/security/center/content/CiscoSecurityResponse/cisco-sr-20131229-der-spiegel

 The article does not discuss or disclose any Cisco product vulnerabilities.

 this is disengenuous at best.  from the nsa document copied in der
 spiegel and now many other places:

   JETPLOW is a firmware persistence implant for Cisco PIX series and
ASA firewalls ...

There's a limit to what can reasonably be called a *product*
vulnerability.  If you physically plant a bug in a phone, does it
exploit a vulnerability in the phone?  I don't think so.
Theoretically, the manufacturer could have filled it completely with
glue.  But the next step up is drilling out some of that to place the
bug, and then you're looking at tamper evidence, and that's an
extremely difficult matter.

Routers are expected to be modular, so it's difficult to avoid that
they have exposed buses with something that approaches DMA capability.
On-site debugging hooks through JTAG ports or similar might be
essential to reduce downtime in case of severe problems, so I doubt
one can get rid of them.  Same for firmware downgrade and recovery
options.

In the end, the defense has to be political, not technical.  We don't
want to do this because it's wrong, and not we can't do this because
it's impossible.  After all, what's possible can change very quickly.
Appeasement in the form of lawful intercept turned out to be failure:
even if you comply, it's likely that your own, domestic intelligence
agencies consider your infrastructure, you and your colleagues
legitimate targets.

Re: NSA able to compromise Cisco, Juniper, Huawei switches

[Florian Weimer]

* Randy Bush:

 There's a limit to what can reasonably be called a *product*
 vulnerability.

 right.  if the product was wearing a low-cut blouse and a short skirt,
 it's not.

Uh-oh, is this an attempt at an argument based on a blame the victim
rape analogy?

Re: NSA able to compromise Cisco, Juniper, Huawei switches

[Florian Weimer]

* Warren Bailey:

 Explaining, not a denial written by their legal department. I find it
 insanely difficult to believe cisco systems has a backdoor into some of
 their product lines with no knowledge or participation.

As far as I understand it, these are firmware tweaks or implants
sitting on a privileged bus (think PCI with busmaster DMA).  Such
things can be added after the device has left the factory by a
sufficiently knowledgeable third party.

Re: Spoofing ASNs (Re: SNMP DDoS: the vulnerability you might not know you have)

[Florian Weimer]

* Jared Mauch:

 Number of unique IPs that spoofed a packet to me. (eg: I sent a
 packet to 1.2.3.4 and 5.6.7.8 responded).

That's not necessarily proof of spoofing, isn't it?  The system in
question might legitimately own IP addresses from very different
networks.  If the system is a router and the service you're pinging is
not correctly implemented and it picks up the IP address of the
outgoing interface instead of the source address of the request,
that's totally expected.

I'm not saying that BCP 38 is widely implement (it's not, unless
operators have configured exceptions for ICMP traffic from private
address, which I very much doubt).  I just think you aren't actually
measuring spoofing capabilities.

Re: Spoofing ASNs (Re: SNMP DDoS: the vulnerability you might not know you have)

[Florian Weimer]

* Jared Mauch:

 The incidence rate is too high for it to be multihomed hosts.

 Let me know if you want to look at the raw data. Very interesting stuff.

 Or just look for 8.8.8.8 in the openresolverproject page.

Indeed, I could verify that 5.61.0.0 can indeed spoof one of my IP
addresses to the 8.8.8.8 DNS resolver.  For a cache miss, I get a
query from a Google IP address and the 8.8.8.8 reply has a plausible
TTL, so I don't think it's spoofing the response.

Apparently, they're implementing DNS proxy by destination-NATting, and
because they listen also on the WAN interface, they get the source
address wrong.

This is quite scary.

Re: Spoofing ASNs (Re: SNMP DDoS: the vulnerability you might not know you have)

[Florian Weimer]

* Christopher Morrow:

 On Sun, Aug 11, 2013 at 11:40 AM, Florian Weimer f...@deneb.enyo.de wrote:

 Apparently, they're implementing DNS proxy by destination-NATting, and
 because they listen also on the WAN interface, they get the source
 address wrong.

 This is quite scary.

 which part? the fact that most NAT implementations on CPE are crap? or
 the spoofing bit?

The spoofing bit.  Among other things, it makes the impact of CPE
crappiness non-localized.

Re: Illegal usage of AS51888 (and PI 91.220.85.0/24) from AS42989 and AS57954 (in ukraine)

[Florian Weimer]

* Nick Hilliard:

 ripe policy 2007-01 will help with this problem by ensuring that anyone who
 has got PI address space will be traceable and will be paying for it (i.e.
 it will appear on the holder's payment radar).

I don't think there are plans to publish this information in the WHOIS
database, though.

Re: Cloudflare is down

[Florian Weimer]

* Constantine A. Murenin:

 And how exactly do they expect end-users clearing the DNS cache?  Do
 I call ATT, and ask them to clear their cache?

Sure, and also tell them to clear their BGP cache (aka route flap
dampening). 8-)

Re: Level3 worldwide emergency upgrade?

[Florian Weimer]

* Andrew Sullivan:

 My impression is mostly that people are left feeling uncomfortable
 by a massive upgrade of this sort with so little communication about
 why and so on.

That's a side effect of Juniper's notification policy.  Perhaps
someone should them take them by their word (Security patches and
advisories are freely available from our web site.) and post this
stuff publicly, so that everybody feels rightly scared and complains
less about these disruptions.

Re: GeekTools Whois Proxy and RIPE/RIPE-NCC

[Florian Weimer]

* Job Snijders:

 In the meantime you could consider setting up an irrd[1], redirect
 queries to that instance instead of whois.ripe.net, and keep it kind
 of fresh by feeding it ftp://ftp.ripe.net/ripe/dbase/ripe.db.gz on a
 daily basis.

RIPE NCC strips all contact information from the bulk exports, so this
isn't a replacement.  But RIPE NCC promised that the bulk exports will
include data related to the (new, mandatory) abuse-c field, so that
data might be more useful again in the future.

Internet-wide port scans

[Florian Weimer]

Are there somewhat reputable service providers for Internet-wide TCP
port scans?  What's the typical rate per TCP port?  (I'm interested in
rather obscure services whose identification may need additional
probing, and this data is unlikely on file already.)

A full scan needs just 0.5 TB of data per TCP port, so roll your own
is definitely an option.  But I expect that any halfway decent hosting
provider will start asking questions after the first billion packets
or so, and at least over here, broadband access without abuse
management lacks sufficient upload bandwidth, making the results
difficult to interpret because the measurements would span several
days.

Re: DNS caches that support partitioning ?

[Florian Weimer]

* John Levine:

 Are there DNS caches that allow you to partition the cache for
 subtrees of DNS names?  That is, you can say that all entries from
 say, in-addr.arpa, are limited to 20% of the cache.

You can build something like that using forwarders and most DNS
caches.  But it won't result in an exact split because cross-subtree
CNAMEs and DNS delegations will cause caching outside the subtree.
However, for in-addr.arpa, that's probably what you want anyway.

Re: DNSChanger Prefixes are re-allocated and advertised ...

[Florian Weimer]

* Barry Greene:

 FYI - Two prefixes from the DNS Changer/Rover Digital take down have
 been re-allocated. One of the prefixes - 85.255.112.0/20 - was
 advertised Friday morning. There is a blog post with some of the
 details here:

Wow, that was fast.  So the police order actually made sense and was
probably necessary.

Re: Vixie warns: DNS Changer ‘blackouts’ inevitable

[Florian Weimer]

[Dnschanger substitute server operations]

 One thing is clear, Paul is able to tell a great story.

PR for ISC is somewhat limited, it's often attributed to the FBI:

| The effort, scheduled to begin this afternoon, is designed to let
| those people know that their Internet connections will stop working
| on July 9, when temporary servers set up by the FBI to help
| DNSChanger victims are due to be disconnected.

http://news.cnet.com/8301-1009_3-57439407-83/google-will-alert-users-to-dnschanger-malware-infection/

| The FBI has now seized control of the malicious DNS servers, but
| countless computers are still infected with the malware.

http://www.h-online.com/security/news/item/Google-warns-DNSChanger-victims-1583037.html

| The malware is so vicious — it can interfere with users' Web
| browsing, steer them to fraudulent websites and make their computers
| vulnerable to other malicious software — that the FBI has put a
| safety net of sorts in place, using government computers to prevent
| any Internet disruptions for users whose computers may be infected.

http://www.technolog.msnbc.msn.com/technology/technolog/infected-users-get-legit-warning-about-july-9-internet-doomsday-751078

(I'm justing quoting what I found.  Some of the linked articles
contain bogus information.)

In any case, this isn't what bugs me about the whole process.  I don't
like the way this is implemented—mainly the use of RPZ, but there are
other concerns.  The notification process has some issues as well, but
it's certainly a great learning exercise for all folks involved with
this.  To me, it doesn't really matter that Dnschanger is fairly minor
as far as such things go.  Hopefully, the knowledge and the contacts
established can be applied to other cases as well.

Re: rpki vs. secure dns?

[Florian Weimer]

* Alex Band:

 All in all, for an RPKI-specific court order to be effective in
 taking a network offline, the RIR would have to tamper with the
 registry, inject false data and try to make sure it's not detected
 so nobody applies a local override.

Please keep in mind that this is what's happening with DNS: registries
are not only forced by the courts to remove delegations, but to
delegate names to specific parties.

On the other hand, it's not entirely clear whether this is such a bad
thing.

Re: rpki vs. secure dns?

[Florian Weimer]

* Paul Vixie:

 this seems late, compared to the various commitments made to rpki in
 recent years. is anybody taking it seriously?

The idea as such isn't new, this has been floating around for four
years or more, including at least one Internet draft,
draft-donnerhacke-sidr-bgp-verification-dnssec.

I don't know if we can get RPKI to deployment because RIPE and RIPE
NCC have rather serious issues with it.  On the other hand, there
doesn't seem to be anything else which keeps RIRs relevant in the
post-scarcity world, so we'll see what happens.

Re: Operation Ghost Click

[Florian Weimer]

* Jeff Kell:

 And what about the millions of users unknowingly infected with
 something else ??

You have to start somewhere.  I received a warning letter, and four or
five very organizations had to cooperate in new ways to make this
happen.  This is certainly a welcome development, and hopefully, this
experience can be used for other mitigation efforts.

Re: rpki vs. secure dns?

[Florian Weimer]

* Alex Band:

 I don't know if we can get RPKI to deployment because RIPE and RIPE
 NCC have rather serious issues with it.  On the other hand, there
 doesn't seem to be anything else which keeps RIRs relevant in the
 post-scarcity world, so we'll see what happens.

 Could you elaborate on what those issues are? 

A year ago, RIPE NCC received legal advice that RPKI-based takedowns
would not happen under Dutch law because Dutch law lacked any
provisions for that.  This was used to deflect criticism that RPKI
deployment would result in too much concentration of power:

http://www.ripe.net/ripe/mail/archives/address-policy-wg/2011-May/005858.html

The legal analysis turned out to be incomplete and the results
incorrect---legal counsel failed to consider public order legislation.
The validaty of such an order (issued in the Dnschanger context) is
currently being challenged in a Dutch court.

From the comments on these events, I infer that RIPE NCC still does
not want to exercise this level of control over routing, and the RIPE
community does not want RIPE to have such control.  But assuming that
the order stands, RPKI will provide RIPE NCC with a tool that nobody
wants it to have, and RIPE NCC can be forced to use it.  Depending on
the seriousness of those concerns, that's the end of RPKI deployment.

(However, the most likely outcome of the current court case is that
this particular police order will be found invalid on a formality,
such as lack of effectiveness, providing little insight on the
validity of future orders which are more carefully crafted.)

Regarding the post-scarcity future, if most address holders never have
to come back to the RIR to request more addresses, the number of
address-related RIR/LIR transactions will decrease.  Organizations
have a tendency to resist decreases in business (even non-profits),
and RPKI is an obvious source of future business.

Re: rpki vs. secure dns?

[Florian Weimer]

* Alex Band:

 At RIPE 63, six months ago, the RIPE NCC membership got a chance to
 vote on RPKI at the general meeting. The result was that the RIPE
 NCC has the green light to continue offering the Resource
 Certification service, including all BGP Origin Validation related
 functionality.

But this was done outside the Policy Development Process, which is
supposed to handle such things.

 It's correct that concerns were raised in the area of
 security, resilience and operator autonomy, as you mention. These
 concerns are continuously being evaluated and addressed.

I don't think so.  Ultimately, it does not seem to be possible to get
this through the PDP.

The whole discussion is a bit odd: Even without RPKI, RIPE NCC already
has the power to directly influence global routing because it's
unreasonable to expect that the majority of their BGP peers employ
strict filtering.  So they could inject more specifics as they see
fit, and thus blackhole pretty arbitrary chunks of address space.
However, so can most folks who of those who control routers in the
DFZ, and RPKI (or something similar) would change that at least.

Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?

[Florian Weimer]

* Valdis Kletnieks:

 According to the end to end argument, the only possible solution
 to the problem, with no complete or correct alternatives, is to
 let hosts directly participate in IGP activities.

 If it's the only possible spolution, how come 99.8% of the end nodes
 do just fine without it? Oh yeah..

Because there's a CPE which acts as a mediator, or the host uses some
dial-up-type protocol which takes care of the IGP interaction.

-- 
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

Re: 128.0.0.0/16 configured as martians in some routers

[Florian Weimer]

* Alex Le Heux:

 The RIPE NCC is aware that 128.0.0.0/16 is configured as a martian by
 default in (some) Juniper OS, even though RFC 5735 and RFC3330 outline
 that this /16 should no longer be reserved as specialised address
 space.

Would someone please clarify the impact?  Will it result in a blackhole,
or will the entire announcement be suppressed?  I suspect the latter,
given what we see and what Chris Adams has reported.

-- 
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

Re: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?

[Florian Weimer]

* Dmitry Cherkasov:

 It is commonly agreed that /64 is maximal length for LANs because if
 we use longer prefix we introduce conflict with stateless address
 autoconfiguration (SLAAC) based on EUI-64 spec. But  SLAAC is not used
 in DOCSIS networks. So there seems to be no objections to use smaller
 networks per cable interfaces of CMTS.

As far as I understan the IPv6 address architecture, if the network
prefix is longer than /64, you're not running Unicast IPv6.

-- 
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

Re: Botnets buying up IPv4 address space

[Florian Weimer]

* Christopher Morrow:

 On Fri, Oct 7, 2011 at 3:10 PM, Arturo Servin arturo.ser...@gmail.com wrote:

        I agree with Benson.

        In fact, for this problem I find irrelevant that IPv4 is running 
 out. They are just looking for good reputation IP nodes.

 isn't this a short-lived problem then?

IPv4 addresses will never run out in a strict sense of the word, it
will just become increasingly more difficult to reassign IPv4 address
space to those who need it.

Re: Nxdomain redirect revenue

[Florian Weimer]

* Cameron Byrne:

 It is very important to ask the redirect partners about yields... meaning,
 you may find that less than 5% of nxdomain redirects can be actually served
 an ad page because 95%+ of nxd are printer lookups and such that cannot be
 served an ad page.  Then from that less than 5% pool, the click through
 rates are around 1%

Is this with strict NXDOMAIN rewriting, or were existing names
redirected as well?  (AFAIK, most platforms do the latter, hijacking
bfk.de, for example.)

-- 
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

Re: Question on 95th percentile and Over-usage transit pricing

[Florian Weimer]

* Pradeep Bangera:

 Question: Does this over-usage bandwidth charge a linear cost function
 or is it sub-linear like the committed bandwidth pricing?

Percentile-based pricing is never linear.  It's not even a continuous
function of bandwidth usage.  This is inherent to the percentile
functional, so it doesn't matter how the quantity that comes out of that
is priced.

-- 
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

Re: Disappointing ARIN - A great advertisement for the USA ?

[Florian Weimer]

* Jon Lewis:

 No he's not.  He's complaining that sometime in the past few weeks (or
 is it months now?) ARIN changed the behavior of their whois server.

Ahem, ARIN's WHOIS server has been sending such responses for ages.
Maybe the change is that more addresses trigger this behavior, but you
could get the handle list before.  Even sending the + flag has been
requested before:

| Date: Fri, 27 Dec 2002 22:19:09 +0100
| 
| Package: whois
| Version: 4.6.1
| Severity: normal
| Tags: patch
| 
| Please include the + flag when querying information for IP addresses
| from whois.arin.net.  This way, whois(1) will print useful information
| and not just the useless overview.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=174497

-- 
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

Re: iCloud - Is it going to hurt access providers?

[Florian Weimer]

* Wayne E. Bouchard:

 the users will screw themselves by flooding their uplinks in which
 case they will know what they've done to themselves and will largely
 accept the problems for the durration

With shared media networks (or insufficient backhaul capacities),
congestion affects more than just the customer causing it.

Re: high performance open source DHCP solution?

[Florian Weimer]

* PC:

 If you're just fighting IOPS, another compromise might be using a ramdisk,
 and then committing that data to storage every x seconds.

In this case, it's more straightforward to remove the fsync call from
dhcpd.

-- 
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

_
NANOG mailing list
NANOG@nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog

Re: high performance open source DHCP solution?

[Florian Weimer]

* Jimmy Hess:

 On Wed, Jul 20, 2011 at 9:31 AM, Nick Colton ncol...@allophone.net wrote:
 We were seeing similar issues with low leases, moved the dhcpd.leases file
 to a ramdisk and went from ~200 leases per second to something like 8,000
 leases per second.

 Yes, blame RFC2131's requirement that a DHCP server is to ensure that
 any lease is committed to persistent storage, strictly before a DHCP
 server is allowed to send the response to the request; a fully
 compliant DHCP server with sufficient traffic is bound by the disk I/O
 rate of underlying storage backing its database.

Come on, group commits are not that difficult to implement.  With them,
you should be able to obtain 8 kHZ leases on a single spindle (assuming
the per-client data is just a few hundred bytes), without violating the
RFC requirement.

-- 
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

_
NANOG mailing list
NANOG@nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog

Re: NDP DoS attack

[Florian Weimer]

* Jared Mauch:

 Solving a local attack is something I consider different in scope
 than the current draft being discussed in 6man, v6ops, ipv6@ etc...

That's not going to happen because it's a layering violation between
the IETF and IEEE.  It has not been solved during thirty years of IPv4
over Ethernet.  Why would be IPv6 be different?

In practice, the IPv4 vs IPv6 difference is that some vendors provide
DHCP snooping, private VLANs and unicast flood protection in IPv4
land, which seems to provide a scalable way to build Ethernet networks
with address validation---but there is nothing comparable for IPv6
right now, from any vendor.

_
NANOG mailing list
NANOG@nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog

Re: OT: Given what you know now, if you were 21 again...

[Florian Weimer]

* Larry Stites:

 Given what you know now, if you were 21 and just starting into
 networking / communications industry which areas of study or
 specialty would you prioritize?

Law.

_
NANOG mailing list
NANOG@nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog

Re: NDP DoS attack

[Florian Weimer]

* Mikael Abrahamsson:

 On Sun, 17 Jul 2011, Florian Weimer wrote:

 In practice, the IPv4 vs IPv6 difference is that some vendors
 provide DHCP snooping, private VLANs and unicast flood protection in
 IPv4 land, which seems to provide a scalable way to build Ethernet
 networks with address validation---but there is nothing comparable
 for IPv6 right now, from any vendor.

 That is not true. Check out work and reports from the IETF SAVI
 WG. There are actually quite a few implementations out there, being
 used in production.

Others use tunnels, PPPoE or lots of scripting, so certainly something
can be done about it.  To my knowledge, SAVI SEND is still at a
similar stage.  Pointers to vendor documentation would be appreciated
if this is not the case.

And SAVI SEND is not the full story---it's still missing unicast flood
protection.

_
NANOG mailing list
NANOG@nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog

Re: NDP DoS attack

[Florian Weimer]

* Mikael Abrahamsson:

 On Sun, 17 Jul 2011, Florian Weimer wrote:

 Others use tunnels, PPPoE or lots of scripting, so certainly
 something can be done about it.  To my knowledge, SAVI SEND is still
 at a similar stage.  Pointers to vendor documentation would be
 appreciated if this is not the case.

 www.ietf.org/proceedings/79/slides/savi-6.pdf

Interesting, thnaks.  It's not the vendors I would expect, and it's
not based on SEND (which is not surprising at all and actually a good
thing).

Is this actually secure in the sense that it ties addresses to
specific ports for both sending and receiving?  I'm asking because
folks have built similar systems for IPv4 which weren't.  The CLI
screenshots look good, better than what most folks achieve with IPv4.

_
NANOG mailing list
NANOG@nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog

Re: NDP DoS attack

[Florian Weimer]

* Mikael Abrahamsson:

 On Sun, 17 Jul 2011, Florian Weimer wrote:

 Interesting, thnaks.  It's not the vendors I would expect, and it's
 not based on SEND (which is not surprising at all and actually a
 good thing).

 Personally I think SEND is never going to get any traction.

Last time, I was told that SEND was the way to go, despite not
actually fixing anything.  This mess is even worse than SCTP.

 Is this actually secure in the sense that it ties addresses to
 specific ports for both sending and receiving?  I'm asking because
 folks have built similar systems for IPv4 which weren't.  The CLI
 screenshots look good, better than what most folks achieve with
 IPv4.

 As far as I know, it's designed to work securely in an ETTH scenario,
 which implies both sending and receiving (if I understood you
 correctly).

And it would also plug the NDP DOS vector because you've got a small
set of addresses you need to process.  Let's hope this gets buy-in
from more vendors (and across the whole switch product lines, please),
with full interoperability.

_
NANOG mailing list
NANOG@nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog

Re: How long is reasonable to fix a routing issue in IPv6?

[Florian Weimer]

 On Fri, Jul 08, 2011 at 10:21:13PM +0200, Florian Weimer wrote:
 * Jared Mauch:
 
  2) is a mapped-v4 address a valid *source* address on the wire
  even if it's not a valid dest?
 
 By the way, has the analogous issue involving v4 addresses from
 RFC 1918 space ever been settled?

 define valid?

Exempt from BCP 38 filters.  I thought that was clear enough, sorry. 8-)

Re: How long is reasonable to fix a routing issue in IPv6?

[Florian Weimer]

* Jared Mauch:

 2) is a mapped-v4 address a valid *source* address on the wire even if it's 
 not a valid dest?

By the way, has the analogous issue involving v4 addresses from
RFC 1918 space ever been settled?

Re: unqualified domains, was ICANN to allow commercial gTLDs

[Florian Weimer]

* Adam Atkinson:

 It was a very long time ago, but I seem to recall being shown
 http://dk, the home page of Denmark, some time in the mid 90s.

 Must I be recalling incorrectly?

It must have been before 1996.  Windows environments cannot resolve
A/ records for single-label domain names.

-- 
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

Re: reporting Swiss Money Report?

[Florian Weimer]

* Eugen Leitl:

 The notorious fax spammer (Swiss Money Report,
 European Money Report, etc; Altanus Ltd.) is
 currently residing in 91.223.119/24
 (91.223.119.174), which is registered to
 Traian Zoran Tariceanu, First Media Service Ltd.

 The contacts at @fmsss.info bounce. What is the
 proper channel for reporting these people? Thanks!

Ask RIPE NCC, they have the RIPE member who requested the PI space on
record.

-- 
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

Re: trouble with .gov dns?

[Florian Weimer]

* David Conrad:

 On May 2, 2011, at 10:19 PM, Florian Weimer wrote:
 I would go even further---the DO bit is not about DNSSEC at all.

 Err, yes it is.

I know you think it is, but you're wrong if you look at the overall
protocol.

 If DO were about DNSSEC, a new flag would have been
 introduced along with DNSSECbis, where the record types changed so
 that for resolvers implementing the older protocol, the DNSSECbis
 records just looked like garbage.

 You're suggesting RFC 3225 should have predicted DNSSECbis?

Not quite.  If DO was about DNSSEC in the strictest possible sense,
then it would not have been possible to reuse the flag for DNSSECbis,
which hasn't got anything in common with DNSSEC as far as the wire
types are concerned.  For a original-DNSSEC-supporting resolver, they
look like garbage, just as the original DNSSEC records for some of the
resolvers back then.  So if DO referred to a specific set of record
types (the original DNSSEC ones), you'd need a new flag for DNSSECbis.
But this wasn't done, so DO does not cover a specific set of record
types, and it is therefore not tied to a particular DNS protocol
extension, including DNSSEC.

Re: trouble with .gov dns?

[Florian Weimer]

* William Herrin:

 Anyone else having trouble with .gov DNS failing with edns-udp-size
 set to 512?

You need an UDP size of at least 1220 for DNSSEC, see RFC 3226,
section 3.  A query that advertises a smaller buffer size is
non-compliant.  BIND will send such queries, but this is a
controversial feature.

This has been noted before, for example:

From: Mark Andrews ma...@isc.org
Subject: [dnsext] Failure to add glue MUST cause TC to be set.
To: dns...@ietf.org
Date: Sun, 20 Feb 2011 08:07:15 +1100
Message-Id: 20110219210716.72943a56...@drugs.dv.isc.org

Re: trouble with .gov dns?

[Florian Weimer]

* William Herrin:

 On Mon, May 2, 2011 at 1:13 PM, Florian Weimer f...@deneb.enyo.de wrote:
 * William Herrin:
 Anyone else having trouble with .gov DNS failing with edns-udp-size
 set to 512?

 You need an UDP size of at least 1220 for DNSSEC, see RFC 3226,
 section 3.  A query that advertises a smaller buffer size is
 non-compliant.  BIND will send such queries, but this is a
 controversial feature.

 I have dnssec-enable no; in my bind config.

It does not seem to have the intended effect.

 Were you able to determine from the tcpdump output that DNSSEC was
 being requested?

[udp sum ok] 10320 [1au] A? www.nsf.gov. ar: . OPT UDPsize=512 OK (40)
11:53:01.690414 IP (tos 0x0, ttl 249, id 28744, offset 0, flags

OK means that DO=1 was set.