Re: rpki vs. secure dns?

[Phil Regnauld]

Rubens Kuhl (rubensk) writes:
> > In case you feel a BGP announcement should not be "RPKI Invalid" but 
> > something else, you do what's described on slide 15-17:
> >
> > https://ripe64.ripe.net/presentations/77-RIPE64-Plenery-RPKI.pdf
> 
> The same currently happens with DNSSEC, doing what Comcast calls
> "negative trust anchors":
> http://tools.ietf.org/html/draft-livingood-negative-trust-anchors-01

Yes, NTAs was the comparison that came to my mind as well. Or even
in classic DNS, overriding with stubs. You will get bitten by a bogus/
flawed ROA, but you'll have to the chance to mitigate it. Any kind of
centralized mechanism like this is subject to these risks, no matter
what the distribution mechanism is.

Re: rpki vs. secure dns?

[Rubens Kuhl]

> In case you feel a BGP announcement should not be "RPKI Invalid" but 
> something else, you do what's described on slide 15-17:
>
> https://ripe64.ripe.net/presentations/77-RIPE64-Plenery-RPKI.pdf

The same currently happens with DNSSEC, doing what Comcast calls
"negative trust anchors":
http://tools.ietf.org/html/draft-livingood-negative-trust-anchors-01




Rubens

Re: rpki vs. secure dns?

[Alex Band]

On 28 Apr 2012, at 19:45, Nick Hilliard wrote:

> On 28/04/2012 18:27, Phil Regnauld wrote:
>>  To me that seems like the most obvious problem, but as Alex put it,
>>  "Everyone has the ability to apply an override on data they do not 
>> trust,
>>  or have a specific local policy for."
> 
> So what do you suggest to do with a roa lookup which returns "Invalid"?

In case you feel a BGP announcement should not be "RPKI Invalid" but something 
else, you do what's described on slide 15-17:

https://ripe64.ripe.net/presentations/77-RIPE64-Plenery-RPKI.pdf

-Alex

Re: rpki vs. secure dns?

[Nick Hilliard]

On 28/04/2012 18:27, Phil Regnauld wrote:
>   To me that seems like the most obvious problem, but as Alex put it,
>   "Everyone has the ability to apply an override on data they do not 
> trust,
>   or have a specific local policy for."

So what do you suggest to do with a roa lookup which returns "Invalid"?

Nick

Re: rpki vs. secure dns?

[Phil Regnauld]

Nick Hilliard (nick) writes:
> 
> Leaving aside technical matters, this is one of the more contentious
> political issues with RPKI.  RPKI is a tool which can be used to locally
> influence routing decisions, but allows centralised control of prefix
> authenticity.  If this central point is influenced to invalidate a specific
> prefix, then that will cause serious reachability problems for that prefix
> on the Internet.

To me that seems like the most obvious problem, but as Alex put it,
"Everyone has the ability to apply an override on data they do not 
trust,
or have a specific local policy for."

> It will be difficult for politicians / legislators / LEAs to look at a
> technology like this and not see its potential for implementing wide-area
> Internet blocking.

> For sure, the LEAs currently looking at it are extremely interested.

Or the ITU ? :)

Cheers,
Phil

Re: rpki vs. secure dns?

[Nick Hilliard]

On 28/04/2012 14:04, Alex Band wrote:
> they do not trust, or have a specific local policy for. In the toolsets
> for using the RPKI data set for routing decisions, such as the RIPE NCC
> RPKI Validator, every possible step is taken is taken to ensure that the
> operator is in the driver's seat.

Leaving aside technical matters, this is one of the more contentious
political issues with RPKI.  RPKI is a tool which can be used to locally
influence routing decisions, but allows centralised control of prefix
authenticity.  If this central point is influenced to invalidate a specific
prefix, then that will cause serious reachability problems for that prefix
on the Internet.

It will be difficult for politicians / legislators / LEAs to look at a
technology like this and not see its potential for implementing wide-area
Internet blocking.  For sure, the LEAs currently looking at it are
extremely interested.

Nick

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: Need spamcop/ironport security contact

[Alex Brooks]

Hello,

On Sat, Apr 28, 2012 at 3:29 AM, Mike  wrote:
>
>        I have a security incident to report and need to make contact with a
> senior level contact responsible for spamcop/ironport immediately.
>

Although I'm pretty sure the OP will have got in touch with someone by
now, for reference for the rest of the list, if you need to get in
touch with someone senior at SpamCop, service [at] admin.spamcop.net
is the address for you.  For actual usage issues (about reporting spam
or dealing with spam reports, it's deputies [at] spamcop.net.  Both
these addresses are publicly listed on SpamCop's website so should be
OK to release here.

+1 to SpamCop being good guys.  If anyone hasn't already, go make sure
you receive SpamCop reports to the address you want in the format you
want (they do ARF if you prefer for example).  Go to
http://www.spamcop.net/w3m?action=ispsignupform or
http://www.spamcop.net/fom-serve/cache/75.html if you have time to
learn all about how they work.

Alex

Re: rpki vs. secure dns?

[Randy Bush]

> first thing that sprung to mind was this:
> http://www.cafepress.com.au/nxdomain

geoff wore one at ripe64.  i was soo green with envy that he has
graciously sent one to meet me when i get home from travails.

see http://archive.psg.com/001213.ietf-dns.pdf for my comments on the
subject at an ietf plenary a dozen years ago.

randy

Re: rpki vs. secure dns?

[Randy Bush]

[ sorry cameron, trying to keep things down to one message ]

> http://tech.slashdot.org/story/12/04/27/2039237/engineers-ponder-easier-fix-to-internet-problem
> http://www.itworld.com/security/272320/engineers-ponder-easier-fix-dangerous-internet-problem

and don't miss

http://www.theregister.co.uk/2012/04/23/ip_hijack_prevention/

free dinner at nanog/van for anyone who can explain how the dnssec
approach meets the defcon attack.  hint: it is a path attack, not an
origin attack, and the dns pidgeon has no hooks to path attack
prevention.  at ripe, joe gersh asked me for an example of a path attack
and i told him of the defcon demo.  seems he also did not bother to do
his homework.  but it makes good pr.

someone selling dnssec appliances flew a press release that a few
reporters bought without doing their homework.  end of net predicted,
news at eleven.

> Taking what seriously ? The commitments to rpki you speak off ?

a thousand LIRs in the ripe region, 500 elsewhere?  cisco code shipping
on a number of platforms, juniper soon.  some of us have actually
started validating route origins in the real network using rpki and
cisco and juniper (test) code.



Saku Ytti  wrote:
> If two fails don't make win, then I think ROVER is better solution,
> doesn't need any changes to BGP just little software magic when
> accepting routes.

you are right, you have not done your homework.  rpki-based origin
validation asks no changes to bgp.

> People might scared to rely on DNS on accepting routes, but is this
> really an issue?

yes.  rpki can also have that issue as the certs can have urls that use
domain names.  i believe they could use ip address urls instead.  but
the gathering operation differs greatly between the rpki and the dnssec
based proposal.  with the latter, you can't even tell you have the full
set.



the worry in the ripe region and elsewhere is what i call the 'virginia
court attack', also called the 'dutch court attack'.  some rights holder
claims their movie is being hosted in your datacenter and they get the
RIR to jerk the attestation to your ownership of the prefix or your ROA.

this problem is inherent in any system which uses the address allocation
administrative hierarchy to attest to address space ownership, whether
rpki, dns-based, or hollerith cards.

i do not like it either.  but it is a trade you make for security.  and,
at ripe ljubljana, i think alex started to discuss some schemes to
ameliorate it.  more later on this.



randy

Re: Need spamcop/ironport security contact

[Suresh Ramasubramanian]

On Sat, Apr 28, 2012 at 6:49 PM, Stephane Bortzmeyer  wrote:
>> And you need a *senior* level contact, why?
>
> He probably meant "someone who has seen an IP address before", not
> level1-support.

spamcop being largely volunteer run has people on it that have a few
years more spam filtering experience than I do - and I've only been
around antispam from like the mid 90s.  Good people.

-- 
Suresh Ramasubramanian (ops.li...@gmail.com)

Re: rpki vs. secure dns?

[Stephane Bortzmeyer]

On Sat, Apr 28, 2012 at 01:17:10PM +0300,
 Saku Ytti  wrote 
 a message of 27 lines which said:

> I think ROVER is better solution, doesn't need any changes to BGP
> just little software magic when accepting routes.

I like Rover but RPKI+ROA does not change BGP either (it will be a
different story with BGPsec).

> People might scared to rely on DNS on accepting routes, but is this
> really an issue?

RPKI+ROA depends on DNS too, since rsync://rpki.ripe.net/repository
will work only if DNS works. Not a problem in practice, since route
origins do not change every minute and the validating ROA cache can
work even if it can no longer update its data. Same thing with Rover:
temporary glitches in the DNS are not a practical problem (the router
keeps the old info).

> routes which fail authorization are logged but accepted if there
> wasn't pre-existing covering route. Only drop routes if they fail
> authorization _AND_ there is pre-existing covering route.

It is a bit more complicated: more-specific attacks, and so on. But,
yes, you're right. As Alex Band says, Rover, RPKI and the IRR make
(authenticated) statements about route origins. You then do what you
want (what your boss wants? what the FBI wants?) with these statements
(route-map, etc).

Re: Need spamcop/ironport security contact

[Stephane Bortzmeyer]

On Fri, Apr 27, 2012 at 11:41:57PM -0400,
 valdis.kletni...@vt.edu  wrote 
 a message of 33 lines which said:

> > I have a security incident to report and need to make contact with
> > a senior level contact responsible for spamcop/ironport
> > immediately.
> 
> And you need a *senior* level contact, why?

He probably meant "someone who has seen an IP address before", not
level1-support.

Re: rpki vs. secure dns?

[Alex Band]

On 28 Apr 2012, at 14:57, Stephane Bortzmeyer wrote:

> On Sat, Apr 28, 2012 at 12:34:52PM +0200,
> Alex Band  wrote 
> a message of 41 lines which said:
> 
>> In reality, since the RIRs launched an RPKI production service on 1
>> Jan 2011, adoption has been incredibly good (for example compared to
>> IPv6 and DNSSEC). More than 1500 ISPs and large organizations
>> world-wide have opted-in to the system and requested a resource
>> certificate using the hosted service, or running an open source
>> package with their own CA. 
> 
> I have an experience with the deployment of DNSSEC and the problem
> with DNSSEC was not to have signed zones (many are, now) but to have
> people *using* these signatures to check the data (i.e. validating in
> a resolver).
> 
> RPKI has many ROA (signed objects) but how many operators validate
> routes on their production routers? Zero?

First you need a robust system and reliable data. Native router support is 
coming along. We could be getting to a stage where people will use the data in 
production. Time will tell...

>> But it's not just that, these ISPs didn't just blindly get
>> certificate and walk away.
> 
> Most of the ROAs are very recent. Again, the experience with DNSSEC
> shows that starting is easy ("DNSSEC in siw minutes"). It's long term
> management which is *the* problem. Wait until people start to change
> the routing data and watch the ROAs becoming less and less correct...
> 
>> Data quality is really good. 
> 
> It's not what you said:
> 
> "It is safe to say that overall data quality is pretty bad"
> 
>  
> (good paper, by the way, thanks)

A lot has changed since I wrote that. :)

-Alex

smime.p7s
Description: S/MIME cryptographic signature

Re: New IETF I-D: Security Implications of IPv6 on IPv4 networks

[Fernando Gont]

FYI, I posted a rev of this I-D a couple of days ago, and hence the
previous document was automatically removed (thus resulting in a broken
link).

The latest version of this document is always available at the magic
URL:


Apologies for the possible inconvenience.

Thanks,
Fernando




On 04/24/2012 07:20 AM, Fernando Gont wrote:
> Folks,
> 
> We've published a new IETF I-D entitled "Security Implications of IPv6
> on IPv4 networks".
> 
> The I-D is available at:
> 
> 
> The Abstract of the I-D is:
>  cut here 
>This document discusses the security implications of native IPv6
>support and IPv6 transition/co-existence technologies on "IPv4-only"
>networks, and describes possible mitigations for the aforementioned
>issues.
>  cut here 
> 
> Any feedback will be very welcome.
> 
> Thanks!
> 
> Best regards,


-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Re: rpki vs. secure dns?

[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. 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. The 
response to the update that was given at RIPE 64 two weeks ago indicated that 
the membership and Community are happy with the approach the RIPE NCC is taking 
in this regard. Of course I realize that some people will never be convinced, 
no matter which steps are taken… 

Looking at the bigger picture though, we shouldn't forget that what RPKI, ROVER 
and the IRR facilitate is merely the ability make a *statement* about routing 
(with varying degrees of reliability) and doesn't have a direct impact on BGP 
routing itself. Ultimately, it is up to the network operator to interpret the 
data that is entered in the system, allow them to make an informed decision and 
take action they deem appropriate. Everyone has the ability to apply an 
override on data they do not trust, or have a specific local policy for. In the 
toolsets for using the RPKI data set for routing decisions, such as the RIPE 
NCC RPKI Validator, every possible step is taken is taken to ensure that the 
operator is in the driver's seat. 

Have a look here for a public example: http://rpki.netsign.net:8080/
Or install and try it yourself: 
http://www.ripe.net/certification/tools-and-resources

Cheers,

Alex

On 28 Apr 2012, at 13:35, Florian Weimer wrote:

> * 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:
> 
> 
> 
> 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.
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: Vendor IPv6 RA Guard Support

[Fernando Gont]

On 04/28/2012 09:11 AM, Christopher J. Pilkington wrote:
> Does there exist a multi-vendor list showing whether a particular
> switch hardware/software supports or does not support RA Guard?

Last time (a couple of months ago, or so) this was discussed on the
ipv6hackers mailing-list
(http://lists.si6networks.com/listinfo/ipv6hackers/), comments were that
no vendor had addressed this, yet.

Thanks,
-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Re: rpki vs. secure dns?

[Stephane Bortzmeyer]

On Sat, Apr 28, 2012 at 12:34:52PM +0200,
 Alex Band  wrote 
 a message of 41 lines which said:

> In reality, since the RIRs launched an RPKI production service on 1
> Jan 2011, adoption has been incredibly good (for example compared to
> IPv6 and DNSSEC). More than 1500 ISPs and large organizations
> world-wide have opted-in to the system and requested a resource
> certificate using the hosted service, or running an open source
> package with their own CA. 

I have an experience with the deployment of DNSSEC and the problem
with DNSSEC was not to have signed zones (many are, now) but to have
people *using* these signatures to check the data (i.e. validating in
a resolver).

RPKI has many ROA (signed objects) but how many operators validate
routes on their production routers? Zero?

> But it's not just that, these ISPs didn't just blindly get
> certificate and walk away.

Most of the ROAs are very recent. Again, the experience with DNSSEC
shows that starting is easy ("DNSSEC in siw minutes"). It's long term
management which is *the* problem. Wait until people start to change
the routing data and watch the ROAs becoming less and less correct...

> Data quality is really good. 

It's not what you said:

"It is safe to say that overall data quality is pretty bad"

 
(good paper, by the way, thanks)

Re: Vendor IPv6 RA Guard Support

[Michael Muller]

That would be kind of interesting. I do not know any promoted "RA guard" 
function that defends against http://thc.org/thc-ipv6/ ,yet.
Perhaps the guys from http://tools.ietf.org/wg/savi/ do know more about 
specific switch vendors.

Vendor IPv6 RA Guard Support

[Christopher J. Pilkington]

Does there exist a multi-vendor list showing whether a particular
switch hardware/software supports or does not support RA Guard?

-cjp

Re: rpki vs. secure dns?

[Stephane Bortzmeyer]

On Sat, Apr 28, 2012 at 03:04:07AM -0700,
 Randy Bush  wrote 
 a message of 9 lines which said:

> draft-bates-bgp4-nlri-orig-verif-00.txt was '98
> 
> and we dropped it for good reasons

Unfortunately, we have RFCs for good ideas but bad ideas never get
documented by the IETF (one of the few exceptions is RFC 3197). So,
bad ideas keep coming back and back again.

Would you explain in a few words why this was a bad idea? I personally
find Rover a very interesting idea, and which seems realistic.

Re: Operation Ghost Click

[Rich Kulawiec]

On Thu, Apr 26, 2012 at 10:03:44PM -0400, Jeff Kell wrote:
> And what about the millions of users unknowingly infected with
> "something else" ??

s/millions/hundreds of millions/

We passed the 100M zombie/bot mark years ago and nothing has happened
in the interim that should/would cause the trend to reverse.  (Based on
what I've seen, the curve continues to monotonically increase.)  Worse,
even the most sophisticated measurement techniques we have are guaranteed
to miss some unknown/unknowable fraction of the total population, since
botmasters are known to keep reserves.  And worse yet, we're now seeing
infestations of portable devices/phones, systems running MacOS, etc.,
so while it's been, to this point, a Windows problem to about five to
seven 9's, it's not anymore, and it's not going to be.

> Does anyone have a plan?

No.  Well, that's a bit unfair: lots of people have ideas, proposals,
and such, but until/unless there's a massive, coordinated, focused effort
-- which will cost a LOT of money -- those ideas and proposals can have
(at best) temporary, localized effects.  I would like to think that the
software vendors whose products are involved would step up, but if that
was going to happen, it probably would have happened by now.

The most likely outcomes are: (1) that the status quo will continue:
massive amounts of attention, effort, and money will be focused on
mitigating the consequences (e.g., anti-spam, anti-phish, anti-DDoS,
anti-malware, anti-anti-anti defenses) and almost none will be focused
on addressing the root causes.  (2) Those running networks which are
infested on a systemic and chronic basis will continue to do so and
will not be held accountable (by anyone) for their incompetence.
(3) More sophisticated bot-creating software will be developed and thoroughly
tested against anti-malware products before being deployed.
(4) Botnet command and control mechanisms will become more resilient in the
face of attacks.  (5) Every now and then, some vendor and/or some government
agency will have a press conference and engage in self-congratulatory
chest-beating about how they've taken down a 5-million member botnet,
while botmasters are busy recruiting all 5 million still-compromised
systems into new botnets.  (6) Once in a while, some poor unsuspecting
person sitting in front of one of these systems will be stuck holding the
bag when clueless prosecutors, assisted by thoroughly ignorant judges and
stunningly inept "experts", decide to score some election-year points by
destroying an innocent person's life: see "Julie Amero" for a canonical
example.  (7) Data harvested from all these systems will continue to be
collated and sold to spammers, phishers, identity thieves, blackmailers,
and anyone else with a passing interest in the usable contents of large
numbers of systems.  (8) Legislators and politicians who cannot even
use computers will propose and likely pass bill after bill after bill
which not only makes the situation worse, but uses it as an excuse to
destroy the few remaining protections that citizens have against wholesale
government snooping into their private lives.  As a bonus, they'll
ensure that much of this information is passed along to any private
contractors who've made sufficient campaign contributions, and they
in turn will be hacked by the first bored 17-year-old with an attitude
that takes note of their existence.

Oh.  Almost forgot.  At each step, the favorite phrases of people who've
failed to learn from history, failed to heed warnings, failed to educate
themselves, failed to listen to experts and now wish to distance themselves
as far as they possibly can from the direct consequences of their own
choices and actions will be used:

"nobody could have predicted"
and
"we take this matter seriously" 

---rsk

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:



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?

[Alex Band]

On 28 Apr 2012, at 11:56, Florian Weimer wrote:

> * 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.

Could you elaborate on what those issues are? 

I can't speak for ROVER, but judging from Gersh's talk at RIPE64 and the 
discussion afterwards, it looks like it's just an old idea that was brought to 
the table again, with a few early adopters experimenting. 

In the linked article Gersh says that RPKI is complex and deployment has been 
slow. In reality, since the RIRs launched an RPKI production service on 1 Jan 
2011, adoption has been incredibly good (for example compared to IPv6 and 
DNSSEC). More than 1500 ISPs and large organizations world-wide have opted-in 
to the system and requested a resource certificate using the hosted service, or 
running an open source package with their own CA. 

But it's not just that, these ISPs didn't just blindly get certificate and walk 
away. There are over 800 ROAs in the global system, describing more than 2000 
prefixes ranging from /24s to /10s, totaling to almost 80 million IPv4 
addresses worth of BGP announcements. Data quality is really good. All in all, 
RPKI has really good traction and with native router support in Cisco, Juniper 
and Quagga, this is only getting better. 

Global deployment statistics can be found here: 
http://certification-stats.ripe.net/

Re: rpki vs. secure dns?

[Saku Ytti]

On (2012-04-27 22:05 +), Paul Vixie wrote:

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

(disclaimer I'm almost completely clueless on RPKI).

If two fails don't make win, then I think ROVER is better solution, doesn't
need any changes to BGP just little software magic when accepting routes.

People might scared to rely on DNS on accepting routes, but is this really
an issue? I'd anyhow prefer to run verification in 'relaxed' mode, where
routes which fail authorization are logged but accepted if there wasn't
pre-existing covering route. Only drop routes if they fail authorization
_AND_ there is pre-existing covering route.
Maybe after several more years of experience and working out kinks, I could
dare to try to run verification in 'strict' more. But 'relaxed' more
already would stop the real-life problems we've seen of route-hijackings. I
don't care much about unannounced net used for spamming really.

Nick Hilliard mentioned in other forum to me bootstrapping problem. DNS
would then be inherently part of your NMS, so install DNS in your NMS, and
NMS already exists in IGP. So infra for verification should be up, before
BGP is up.

-- 
  ++ytti

Re: rpki vs. secure dns?

[Randy Bush]

> 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.

draft-bates-bgp4-nlri-orig-verif-00.txt was '98

and we dropped it for good reasons

randy

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]

* 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: rpki vs. secure dns?

[Matthias Waehlisch]

  line 408 ff. in the IETF 83 SIDR minutes

  * http://www.ietf.org/proceedings/83/minutes/minutes-83-sidr.txt



Cheers
  matthias

-- 
Matthias Waehlisch
.  Freie Universitaet Berlin, Inst. fuer Informatik, AG CST
.  Takustr. 9, D-14195 Berlin, Germany
.. mailto:waehli...@ieee.org .. http://www.inf.fu-berlin.de/~waehl
:. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net

On Fri, 27 Apr 2012, Paul Vixie wrote:

> http://tech.slashdot.org/story/12/04/27/2039237/engineers-ponder-easier-fix-to-internet-problem
> 
> > "The problem: Border Gateway Protocol (BGP) enables routers to
> > communicate about the best path to other networks, but routers don't
> > verify the route 'announcements.' When routing problems erupt, 'it's
> > very difficult to tell if this is fat fingering on a router or
> > malicious
> > ,'
> > said Joe Gersch, chief operating officer for Secure64, a company that
> > makes Domain Name System (DNS) server software. In a well-known
> > incident, Pakistan Telecom made an error with BGP after Pakistan's
> > government ordered in 2008 that ISPs block YouTube, which ended up
> > knocking Google's service offline
> > .
> > A solution exists, but it's complex, and deployment has been slow. Now
> > experts have found an easier way."
> 
> this seems late, compared to the various commitments made to rpki in
> recent years. is anybody taking it seriously?
> 
> 

Re: JUNOS forwards IPv6 link-local packets

[Owen DeLong]

We kind of needed them in IPv4, though not universally.

At least in IPv6, we have them.

Owen

On Apr 27, 2012, at 12:16 PM, Christopher Morrow wrote:

> you know what I love? address selection rules, or rather the fact that
> we have to have them in this new ip protocol :(
> 
> bugs and code problems and operational headaches and filters and ... :(
> 
> On Fri, Apr 27, 2012 at 12:31 PM, Jack Bates  wrote:
>> On 4/27/2012 11:20 AM, Chris Adams wrote:
>>> 
>>> Once upon a time, Jack Bates  said:
 
 fe80::/65 discard
 fe80:0:0:0:8000::/65 discard
 
 More specifics rule out over connected any day.
>>> 
>>> That would also kill any legitimate link-local traffic though.
>> 
>> 
>> Perhaps. I'm actually curious on that, as the rules for routing to
>> link-local are very specialized. It might flag on uRPF for local traffic,
>> but that can be overcome with a fail filter. Sending out from the RE could
>> likely ignore the route, as it has to send to specific interfaces. Receiving
>> on interfaces that don't have uRPF should still work as well.
>> 
>> It's a theory and would have to be tested.
>> 
>> Jack
>> 

Re: Squeezing IPs out of ARIN

[Luke S. Crawford]

On Tue, Apr 24, 2012 at 01:32:17PM -0400, ad...@thecpaneladmin.com wrote:
> Anyone have any tips for getting IPs from ARIN? For an end-user 
> allocation they are requesting that we provide customer names for 
> existing allocations, which is information that will take a while to 
> obtain. They are insisting that this is standard process and something 
> that everyone does when requesting IPs.  Has anyone actually had to do 
> this?

I have.  

clearly, I should have asked, or looked closer, but  when I started
this mess? it was not at all clear to me that ARIN saw things that went
into a home as 'residential' and everything else as 'business'  - but
from my reading and their reactions to my questions, that's how they see 
it.  If it's in a data center and not in a residence, you need to 
give them a name (human or business) for every reassigned IP, 
even if the reassignment is a /32.

Probably the majority of my VPSs?  personal use, but not residential.

I started with changing the privacy policy, and blogged about it, asking
for at least 80% of the people to opt-in.  Maybe 2% did.   I gave it 
months, then I emailed everyone, asking them to opt-out.   I gave them
two weeks, maybe 2% did.   

So yeah; eh, nobody got mad at me for it, and I think some people were
impressed that I emailed them when I made such a large change to 
the privacy policy (that isn't expected?)  so I guess it all turned out
okay, but yeah.  ARIN wants a name of some sort for every 
/32.  (Now, I just did a query against my billing database and returned
the business name and only returned the human name if there was no 
business name.)