Re: "Defensive" BGP hijacking?

[Doug Montgomery]

Ah, the global system I was referring to was the RPKI as distributed
repository of routing information.  With consistent properties (data
formats, security models, data validation techniques, etc) across all 5
RIRs.

What an ISP does with the RPKI data, interns of route filtering, is always
a local policy decision.Somehow "global enforcement system" sounded
like a vision where ISPs don't have a choice of how and where to use the
system.  Maybe I read too much into the phrasing.

In the end, I think the issues boils down to if the community has the
desire and will to address the route hijack issue.If the answer is no,
then no further discussion is needed.  If the answer is yes, then it is
best to discuss and compare real proposals / mechanisms to address the
issue at scale.

I am still interested in some detail on the "tyranny implications".  We
can't address them until we know what they are and how they compare to any
other solution that tries to address the same problem.

dougm

On Wed, Sep 14, 2016 at 6:04 PM, Mel Beckman <m...@beckman.org> wrote:

> Doug,
>
> I was basing my comments on your statement "If only there were a global
> system.."  However you slice or dice it, the tyranny implications have not
> yet been addressed. That certainly needs to be in front of any technical
> idea such as RPKI.
>
> Although I haven't participated in the OT, nothing I've read in RFC 6810
> talks about these issues. It talks about authentication and transport
> security, but doesn't talk about the potential for government interference.
>
>  -mel beckman
>
> On Sep 14, 2016, at 8:22 AM, Doug Montgomery <dougm.w...@gmail.com> wrote:
>
> Mel,
>
> If you are speaking of RPKI based origin validation, I am not sure
> "automated / global enforcement system" is a useful description.   It does
> provide a consistent means for address holders to declare AS's authorized
> to announce prefixes, and a means for remote ASs to compare received
> updates vs such declarations.   What the receiving AS does with the
> validation information is strictly a local policy matter.
>
> Frankly, this is no more a "new automated enforcement system" than
> IRR-based route filtering has been for 20 years.  The only difference is
> that there is a consistent security model across all 5 RIRs as to who can
> make such declarations and it is tightly tied to the address allocation
> business process.
>
> I have seen a lot of FUD about the specter of interference, but not a lot
> of serious thought / discussion.  Having a serious technical discussion of
> potential risks and mitigations in the system would be useful.
>
> dougm
>
> On Wed, Sep 14, 2016 at 10:51 AM, Mel Beckman <m...@beckman.org> wrote:
>
>> Scott and Doug,
>>
>> The problem with a new automated enforcement system is that it hobbles
>> both agility and innovation. ISPs have enjoyed simple BGP management,
>> entirely self-regulated, for decades. A global enforcement system, besides
>> being dang hard to do correctly, brings the specter of government
>> interference, since such a system could be overtaken by government entities
>> to manhandle free speech.
>>
>> In my opinion, the community hasn't spent nearly enough time discussing
>> the danger aspect. Being engineers, we focus on technical means, ignoring
>> the fact that we're designing our own guillotine.
>>
>>  -mel beckman
>>
>> > On Sep 14, 2016, at 12:10 AM, Scott Weeks <sur...@mauigateway.com>
>> wrote:
>> >
>> >
>> >
>> > --- dougm.w...@gmail.com wrote:
>> > From: Doug Montgomery <dougm.w...@gmail.com>
>> >
>> > If only there were a global system, with consistent and verifiable
>> security
>> > properties, to permit address holders to declare the set of AS's
>> authorized
>> > to announce their prefixes, and routers anywhere on the Internet to
>> > independently verify the corresponding validity of received
>> announcements.
>> >
>> > *cough  https://www.nanog.org/meetings/abstract?id=2846 cough*
>> > 
>> >
>> >
>> > Yes, RPKI.  That's what I was waiting for.  Now we can get to
>> > a real discussion... ;-)
>> >
>> > scott
>>
>
>
>
> --
> DougM at Work
>
>


-- 
DougM at Work

Re: "Defensive" BGP hijacking?

[Doug Montgomery]

Mel,

If you are speaking of RPKI based origin validation, I am not sure
"automated / global enforcement system" is a useful description.   It does
provide a consistent means for address holders to declare AS's authorized
to announce prefixes, and a means for remote ASs to compare received
updates vs such declarations.   What the receiving AS does with the
validation information is strictly a local policy matter.

Frankly, this is no more a "new automated enforcement system" than
IRR-based route filtering has been for 20 years.  The only difference is
that there is a consistent security model across all 5 RIRs as to who can
make such declarations and it is tightly tied to the address allocation
business process.

I have seen a lot of FUD about the specter of interference, but not a lot
of serious thought / discussion.  Having a serious technical discussion of
potential risks and mitigations in the system would be useful.

dougm

On Wed, Sep 14, 2016 at 10:51 AM, Mel Beckman <m...@beckman.org> wrote:

> Scott and Doug,
>
> The problem with a new automated enforcement system is that it hobbles
> both agility and innovation. ISPs have enjoyed simple BGP management,
> entirely self-regulated, for decades. A global enforcement system, besides
> being dang hard to do correctly, brings the specter of government
> interference, since such a system could be overtaken by government entities
> to manhandle free speech.
>
> In my opinion, the community hasn't spent nearly enough time discussing
> the danger aspect. Being engineers, we focus on technical means, ignoring
> the fact that we're designing our own guillotine.
>
>  -mel beckman
>
> > On Sep 14, 2016, at 12:10 AM, Scott Weeks <sur...@mauigateway.com>
> wrote:
> >
> >
> >
> > --- dougm.w...@gmail.com wrote:
> > From: Doug Montgomery <dougm.w...@gmail.com>
> >
> > If only there were a global system, with consistent and verifiable
> security
> > properties, to permit address holders to declare the set of AS's
> authorized
> > to announce their prefixes, and routers anywhere on the Internet to
> > independently verify the corresponding validity of received
> announcements.
> >
> > *cough  https://www.nanog.org/meetings/abstract?id=2846 cough*
> > 
> >
> >
> > Yes, RPKI.  That's what I was waiting for.  Now we can get to
> > a real discussion... ;-)
> >
> > scott
>



-- 
DougM at Work

Re: "Defensive" BGP hijacking?

[Doug Montgomery]

If only there were a global system, with consistent and verifiable security
properties, to permit address holders to declare the set of AS's authorized
to announce their prefixes, and routers anywhere on the Internet to
independently verify the corresponding validity of received announcements.

*cough  https://www.nanog.org/meetings/abstract?id=2846 cough*

I now return us to our discussion of network police, questionnaires for
network security, and the use of beer as a motivating force.

dougm

On Tue, Sep 13, 2016 at 2:51 PM, Mel Beckman  wrote:

> Blake,
>
> I concur that these are key questions. Probably _the_ key questions. The
> fabric of the Internet is today based on trust, and BGP's integrity is the
> core of that trust.
>
> I realize that BGP hijacking is not uncommon. However, this is the first
> time I've seen in it used defensively. I don't see a way to ever bless this
> kind of defensive use without compromising that core trust. If Internet
> reachability depends on individual providers believing that they are
> justified in violating that trust when they are attacked, how can the
> Internet stand?
>
> In addition to the question posed to Bryant about whether he would take
> this action again, I would like to add: what about the innocent parties
> impacted by your actions? Or do you take the position there were no
> innocent parties in the hijacked prefixes?
>
> -mel via cell
>
> > On Sep 13, 2016, at 11:40 AM, Blake Hudson  wrote:
> >
> >
> >
> > Bryant Townsend wrote on 9/13/2016 2:22 AM:
> >> This was the point where I decided
> >> I needed to go on the offensive to protect myself, my partner, visiting
> >> family, and my employees. The actions proved to be extremely effective,
> as
> >> all forms of harassment and threats from the attackers immediately
> stopped.
> >
> >
> > Bryant, what actions, exactly, did you take? This topic seems
> intentionally glossed over while you spend a much larger amount of time
> explaining the back story and your motivations rather than your actions.
> >
> > Questions I was left with:
> >
> > 1. What prefixes have you announced without permission (not just this
> >   event)?
> > 2. How did you identify these prefixes?
> > 3. Did you attempt to contact the owner of these prefixes?
> > 4. Did you attempt to contact the origin or transit AS of these prefixes?
> > 5. What was the process to get your upstream AS to accept these prefix
> >   announcements?
> > 6. Was your upstream AS complicit in allowing you to announce prefixes
> >   you did not have authorization to announce?
> >
>



-- 
DougM at Work

Re: ROVER routing security - its not enumeration

[Doug Montgomery]

On 6/10/12 5:53 PM, Paul Vixie vi...@isc.org wrote:

Doug Montgomery dougm.tl...@gmail.com writes:

  ...

 I think we debate the superficial here, and without sufficient
imagination.
 The enumerations vs query issue is a NOOP as far as I am concerned.
With
 a little imagination, one could envision building a box that takes a
feed
 of prefixes observed, builds an aged cache of prefixes of interest,
queries
 for their SRO records, re queries for those records before their TTLs
 expire, and maintains a white list of SRO valid prefix/origin pairs
that
 it downloads to the router.

this sounds like a steady state system. how would you initially populate
it,
given for example a newly installed core router having no routing table
yet?

if the answer is, rsync from somewhere, then i propose, rsync from RPKI.

if the answer is, turn off security during bootup, then i claim, bad idea.

Well, I should probably let the ROVER guys say what they have in mind.

The above started from my imagination that if you did not want routers
actually doing route-by-route queries, that it would be easy to build a
validating cache that behaves similar to a RPKI validating cache, but
pulling the info from rDNS as opposed to RPKI.

Maybe the ROVER guys have something else in mind (e.g., routers doing the
queries themselves, some other model of how the info ... Or its impacts
... Is effected on the router).

IFF you do imagine that there is a SRO validating cache box - you can
decompose the question of how one solves state skew between (1) rtr and
cache, (2) cache and info authoritative source, and (3) how new
authoritative information gets globally distributed/effected in the system.

Looking at just (1) (your question I think), we have a couple of different
questions to look at.

a. How does a router with no origin info (new router, router reboot),
synchronize with the cache (assuming the cache has state).

The current machinery of rtr-to-cache would work fine here.  Might need to
add a bit or two, but the basic problem is the same.

b. How does a cache with no state, build a list of prefix-origin pairs?
Clearly if one builds a SRO validating cache box, the usual techniques of
checkpointing state, having redundant cache's etc could be used ... But at
some level the question of having to get initial state, and what the
router does during that period (assuming that the stateless cache is his
only source) must be answered.

One way of thinking about these questions, is to ask how would it work in
RPKI?

If for origin validation we have a strict don't fail open during resets
requirement, then there are a lot of initialization questions we must
address in any system.  I.e., what does the router do, if its only RPKI
cache has to rebuild state from zero?  What does such a router do if it
looses contact with its cache?
 
At this point, I could propose more ideas, but probably going further with
my imagination is not important. The ROVER guys should tell us what they
have in mind, or someone interested in building a ROVER validating cache
should design one and tell us.

But maybe stepping back one level of abstraction, you can think of things
this way.

We have a top-down-enumeration vs query model.  One could put a cache in
the the query model to make it approximate an enumeration model, but only
to the point that one has, or can build a reasonably complete, list of
prefixes of interest.

If one admits that sometimes there will be cache misses (in the
query/cache model) and one might have to query in those cases, then the
trade off seems to be how often that occurs vs the responsiveness one
would get out of such a system for situations when the authoritative
information itself changes (case 3 above).  I.e., how fast could you turn
up a new prefix in each system?

Maybe the ROVER guys don't believe in caches at all.  In which case I
return you to the original OMG! Enumeration vs Query thread.

I just don't think that is the most significant difference between the two
approaches.  

dougm



 ...

 Point being, with a little imagination I think one could build
components
 with either approach with similar  black box behavior.

i don't think so. and i'm still waiting for a network operator to say what
they think the merits of ROVER might be in comparison to the RPKI
approach.
(noting, arguments from non-operators should and do carry less weight.)

-- 
Paul Vixie
KI6YSY

Re: ROVER routing security - its not enumeration

[Doug Montgomery]

On 6/5/12 3:40 PM, Randy Bush wrote:

There are number of operational models that provide the needed
routing protection without enumeration.

I can see a use-case for something like:
   Build me a prefix list from the RIR data

this requires a full data fetch, not doable in dns.

and, at the other end of the spectrum, for any dynamic lookup on
receiving a bgp announcement, the data had best be already in the
router.  a full data set on an in-rack cache will go nuts on any
significant bgp load.  beyond that, you are in non-op space.

randy



I think we debate the superficial here, and without sufficient 
imagination.   The enumerations vs query issue is a NOOP as far as I am 
concerned.With a little imagination, one could envision building a 
box that takes a feed of prefixes observed, builds an aged cache of 
prefixes of interest, queries for their SRO records, re queries for 
those records before their TTLs expire, and maintains a white list of 
SRO valid prefix/origin pairs that it downloads to the router.


Lets call that box a SRO validating cache.

Where do you get the feed of prefixes of interest?From your own RIBs 
if you are only interested in white lists proportional to the routes you 
actually see,  e.g., feed the box iBGP.   From other sources (monitors, 
etc) if you would like a white list of every known prefix that anyone 
has seen.


What about a completely new prefix being turned up?   ... we could talk 
through those scenarios in each approach.


How does the cache down load the white list to the router ... we already 
have one approach for that.  Add a bit to the protocol to distinguish 
semantics of SRO from ROA semantics if necessary.


Point being, with a little imagination I think one could build 
components with either approach with similar  black box behavior.


If there are real differences in these approaches it will be in their 
inherent trust models, the processes that maintain those trust models, 
the system's level behavior of the info creation and distribution 
systems, and the expressiveness of their validation frameworks.


dougm

Re: YES I'VE TRIED MANY VENUES looking for mail admin @, nist.gov

[Doug Montgomery]

I suggested the telephone to another a few weeks ago and that wasn't well
received. Let me elaborate. Today is Friday. It's July. It's about 2PM.
Probably lunchtime where NIST is.  Calling the IT help desk at NIST is
likely to get you further faster. NANOG is not really real time.


Contact me off list and I will link you up.

Not all out to lunch ...
dougm