Re: [sidr] Current document status && directionz

[Heasley]

Am 08.09.2016 um 00:42 schrieb Randy Bush :

>> Or maybe there's pushback that says: "Hey, I hear what you all in the
>> rir want, but it's not cool, please please let's dive back into the
>> politics stream and see how we get movement on what we all (probably?)
>> want: a single root for this system."

Or can the RIRs be removed from the equation? Why must we care what the RiRs 
want (fitting of many questions surrounding the RIRs)? Theyre essentially just 
agents of the IANA, its not inconceivable to replace them or separate duties. 

> 
> the iab did that and got a written agreement that the rirs would do so.
> nothing more is needed other than action.
> 
> randy


> 
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] WGLC for draft-ietf-sidr-origin-validation-signaling-04

[heasley]

Mon, May 05, 2014 at 07:03:46PM +0200, Randy Bush:
> > And lets not forget: Running Code: Last but not least???the draft has
> > been delayed more than what it should and several implementations
> > (including two from Cisco) has running code + documentation +
> > training. As we are pushing to improve adoption of RPKI, I rather
> > spend time adding the missing pieces that removing what is not
> > broken???although the need may not be obvious for everyone.
> 
> actually, code removal is not an evil, quite the opposite.

esp. when 1 company has 2 (two, zwei, dos!) implementations.

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] NotFound vs Uninitialized

[heasley]

Thu, Mar 14, 2013 at 02:02:13PM -0400, Montgomery, Douglas:
> Not an ops person - so take with a grain of salt - but imagine a world N 
> years from now where I only accept routes that have VALID origins.  All 
> others routes are dropped.
> 
> Imagine a net/power/nature event that both reboots my routers and all of the 
> caches that I speak too.   If may prefer to reboot the routing system without 
> validation, until enough infrastructure is up to begin validation. 

or your validation server is remote - within a prefix that will not be
accepted because it is NotFound/Undefined?

> dougm
> --
> Doug Montgomery - Manager Internet and Scalable Systems Research Group  / ITL 
> / NIST
> 
> From: sidr-boun...@ietf.org [sidr-boun...@ietf.org] On Behalf Of Andrew Chi 
> [a...@bbn.com]
> Sent: Thursday, March 14, 2013 1:16 PM
> To: sidr@ietf.org
> Subject: Re: [sidr] NotFound vs Uninitialized
> 
> On 3/14/13 6:55 AM, Randy Bush wrote:
> > what will an operator do differently for these two shades of grey?
> 
> Good question.  *Operators*, would you ever treat these differently?
> 
> > what is the trust difference?
> 
> NotFound: The global RPKI doesn't know this route, i.e., *nobody* knows.
> Undefined: *I* don't know what the RPKI says about this route.
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] ORIGINs

[heasley]

Mon, Mar 11, 2013 at 03:45:17PM -0700, Randy Bush:
> heas,
> 
> > Whether anyone likes it, it has become a TE knob of sorts, in a protocol
> > with few such knobs, and many smaller transit providers rely upon it to
> > affect route selection for non-malicious reasons, such as to balance their
> > own transit links.  Without providing an alternative, it will be crippling
> > to many to inhibit its use as such.
> 
> that is not exactly the qestion, thought i gives a hint.  by "smaller
> transit providers rely on it" do you mean that the value is legitimately
> set or altered by other than the originating AS?  if so, then signing it
> would be bad.  if not, it could be good.  so could you please clarify?

that is exactly what I am implying/saying.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] ORIGINs

[heasley]

Sun, Mar 10, 2013 at 10:00:53AM -0600, Danny McPherson:
> The origin AS sets the value of the attribute to whatever THEY desire 
> -- the concern was that upstream ASes can manipulate this to launch 
> "traffic attraction attacks".  This happens today with some of our 
> transit providers, and we'd like the option to be able to mitigate that 
> attack if we're going to put a bunch of stuff in place to secure 
> inter-domain routing on the Internet.

Whether anyone likes it, it has become a TE knob of sorts, in a protocol
with few such knobs, and many smaller transit providers rely upon it to
affect route selection for non-malicious reasons, such as to balance their
own transit links.  Without providing an alternative, it will be crippling
to many to inhibit its use as such.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-protocol-mib-04

[heasley]

Tue, Dec 04, 2012 at 05:25:16PM +0100, Bert Wijnen (IETF):
> Not sure why you send this to authors/editors.
> 
> The document is in IETF Last Call.
> So comments need to to got to IETF or IESG list.
> 
> Your comments seem to be comments that get responded
> to a WG or IETF Last Call. Those comments need to
> go to WG and/or IESG or IETF list.
> 
> 
> On 12/4/12 5:15 PM, heasley wrote:
> > rpkiRtrCacheServerPreference doesnt indicate which is more preferred, 0 or
> > 255, but should imo.
> >
> Since it is an Unsigned 32, I think that this text:
> 
> 
>  A lower value means more preferred. If two
>  entries have the same preference, then the
>  order is arbitrary.
> 
> Which is present in the DESCRIPTION clause clearly explains
> that 0 is more preferred than 255.

grumble; the mib import tool is truncating descriptions.  sorry for the noise.

> > shouldnt rpkiRtrCacheServerV4ActiveRecords et al be in an afi/safi table?
> > in theory, other afis may be supported.
> >
> not sure I can properly answer this one.
> possibly you'd like to see them there too?
> 
> But I don't think this is a fatal flaw is it?

you tell me; seems like afi/safi tables are common now and other rpki pairs
are possible.  
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] additions and changes to agenda on Friday

[heasley]

Thu, Nov 08, 2012 at 11:25:44AM +, Murphy, Sandra:
> There are ISPs that spend considerable energy creating prefix filters from 
> IRR data and strongly encourage their customers to register in IRRs.  Those 
> registers are maintained by an outside party that's outside the operator 
> organization's direct control.  Those registered objects directly affect 
> reachability information carried within their network.

Some operators maintain their own registry and mirror the database of others,
as we do.  Others run their own server which mirrors the DB of some subset of
registries.  Others rely on the servers operated by those who own the
registries (or other publicly available servers).

We'll do the same, to whatever extent possible, for rpki, so as to be as
independant as possible.

> Commercial operators have been comfortable with this mode of operation for 
> many years.  I doubt whether any of them have felt the need to carefully 
> evaluate the risks or consult their legal departments.  It has been best 
> current practice and urged on operators at *OG meetings.

Not all that comfortable; but it is what we have.  we expend great effort to
insulate ourselves from failures.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] additions and changes to agenda on Friday

[heasley]

Thu, Nov 08, 2012 at 03:27:02AM +, John Curran:
> > no need.  this is object based security.  rama and hanuman have tals and
> > validate.  
> 
> This would leave Rama and hanuman dependent on the CA services but 
> not aware of the CPS term and conditions despite the explicit 
> requirement specified in the PKIX profile?

It looks like a SHOULD to me, not a MUST.  no?
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] origin attribute

[heasley]

Wed, Oct 24, 2012 at 10:53:58AM -0600, Shane Amante:
> Danny,
> 
> On Oct 24, 2012, at 9:11 AM, Danny McPherson  wrote:
> > On Oct 23, 2012, at 6:03 PM, Shane Amante wrote:
> > 
> >> I suspect John is referring to the operational practice employed by some 
> >> networks, right now, whereby they overwrite ORIGIN during receipt of an 
> >> UPDATE into their network to 'normalize' ORIGIN to a consistent value.
> > 
> > Ironically, if "normalize[ing] ORIGIN to a consistent value" at an upstream 
> > AS results in a change to the ORIGIN code for a given path, you've _created 
> > INconsistent ORIGIN codes for the prefix in the routing system.  I suppose 
> > I understand why this might be desirable for a transit network provider, 
> > but as an edge AS I'd prefer to not have intermediate networks changing the 
> > values I set.
> 
> Fair enough.  In my defense :-), RFC 4271 does state that ORIGIN code "SHOULD 
> NOT" be changed by any other speaker 
> .  Fortunately, it doesn't 
> say: "MUST NOT".  :-)
> 
> Perhaps a better question should be: is ORIGIN code still required, 
> particularly from a BGP path selection perspective, in today's networks?  I 
> would say "no".  (If you wanted to know the 'source' of a BGP route, there 
> are already a plethora of BGP communities to help operators narrow this down 
> ... but, this is more for convenience of troubleshooting, it doesn't need to 
> be in path selection).
> 
> IOW, instead of "securing" ORIGIN, maybe folks should be looking at 
> deprecating it?  IMO, this would have likely been a far more productive use 
> of time than the deprecation of AS_SET's, (the latter of which I still 
> maintain was a bad idea, done primarily for convenience w/out adequate 
> consideration of it's _long-term_ usefulness).

its used as a "TE" knob, whether danny likes it or not.  given the lack of
TE knobs, a lot of hatred should be expected if its taken away (deprecated or
"secured").

> 
> >> This is especially valuable in cases where one network, A, is multi-homed 
> >> to an adjacent network, B, and network A may not be announcing a 
> >> consistent set of BGP path attributes associated with a set of IP prefixes 
> >> at all locations.  Ultimately, this practice allows network B to 
> >> consistently skip over ORIGIN and, instead, evaluate more well-understood 
> >> BGP Path Selection criteria like MED's, IGP metric, etc.
> >> across the full set of "common" BGP routes, (i.e.: those with the same 
> >> AS_PATH, LOCAL_PREF, etc.), learned across all exit points to network B.
> > 
> > I'm pretty sure MEDs and "IGP metric" are far more ambiguous and broken in 
> > practice than ORIGIN code (e.g., [1]), especially when comparing across 
> > paths learned from different adjacent ASes.
> 
> FWIW, I wasn't actually referring to to MED or IGP metric comparison across 
> different AS_PATHs, rather MED or IGP metric comparison across same AS_PATHs.
> 
> Regardless, your point is valid that comparison of MED's, even just across 
> the same AS_PATH, is oftentimes fraught with operational 
> headaches/brokenness.  However, in defense of MED's :-), I believe that the 
> root cause problem here is, most likely, an inability (or, worse, 
> unwillingness) for the network sending MED's to continually fine-tune not 
> only the MED value(s), but at the same time (just as importantly) to 
> __intelligently__, (i.e.: only when necessary), deaggregate [very] large 
> prefixes in order that more relevant MED values can be targeted at those more 
> specifics resulting in better 'signals' toward upstream networks.  Then 
> again, we might agree to disagree on this.   :)
> 
> 
> To the larger point of going back to actual requirements for this work, then 
> why hasn't there been discussion in the requirements or threats documents 
> about 'securing':
> - ORIGIN
> - NEXT_HOP: third-party NEXT_HOP at IXP's anyone?
>   BTW, I would note that the above would be an extremely clever way to divert 
> traffic through a bad guy's network that would be completely invisible within 
> the AS_PATH, (but could show up in traceroutes).  w00t!
> - MED's
> - BGP communities: which are quite commonly used to manipulate an upstream's 
> BGP path selection algorithm (i.e.: raise/lower LOCAL_PREF) and/or _scope_ 
> the announcement toward adjacent ASN's/routers, (i.e.: no-export, 
> no-advertise, being the two standards-based ones)?
> 
> ... not even a mention of being "out-of-scope" and for what reason(s), even 
> though draft-ietf-sidr-bgpsec-reqs-05 states: "As noted in the threat model, 
> [I-D.ietf-sidr-bgpsec-threats], this work is limited to threats to the BGP 
> protocol."  
> 
> Then again, there still isn't a serious acknowledgement that 'route leaks' 
> are, in fact, a much more serious "threat to the BGP protocol", than 
> manipulation of most of those BGP attributes even though the route-leaks 
> problem has been crisply defined in 1.5 pages:
> http://tools.ietf

Re: [sidr] sidrSlides for "RPKI Over BitTorrent" presentation

[heasley]

Thu, May 24, 2012 at 06:36:51AM -0700, Wes Hardaker:
> I didn't say only :-) . In fact, I pointed at bittorrent as a backup.  I
> simply said it would be more efficient when sending out *new* changes.

understood; i'm registering/re-enforcing that if that is developed it must
not be the only mathod.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] sidrSlides for "RPKI Over BitTorrent" presentation

[heasley]

Wed, May 23, 2012 at 06:22:33PM -0700, Wes Hardaker:
> Rob Austein  writes:
> 
> > For those who didn't get to see the end of the "RPKI Over BitTorrent"
> > presentation in today's SIDR meeting, the full slide deck is available
> > at
> >
> >   http://www.ietf.org/proceedings/83/slides/slides-83-sidr-9.pdf
> >
> > and should be relatively self-explanatory.
> 
> I've been thinking about this a lot lately, as it'll certainly be a
> challenge to ensure everyone is up to date.  It doesn't matter whether
> you "should have pulled" or whether "you pull right when you get a
> request".  Either way, there is an underlying data distribution problem.
> 
> Most importantly, every bit of the repository needs to pretty much get
> everywhere.  Rdist works well for trying not to duplicate data.
> Bittorrent works well for sharing the load, but either requires a lot of
> bittorrent start files (whatever they're called), which then becomes
> hard to syncronize; or a small number of bittorrent files (one per
> aggregation point) that indicate you need to refetch and entire .zip
> file even if you already have most of it anyway.
> 
> But the real underlying problem is what I said above: every bit needs to
> get efficiently to every place, ideally at time of initial publication.

I have probably have missed it, but has an IRR distribution protocol-like
mechanism been discussed?  See Merit's IRRd documentation, but simply its
DNS serial number-like with record "add" and "delete" functions.  I would
expect this to be relative low impact and, at least with Merit's IRRd, to
be low maintenance.

And, regarding the comment about NNTP in the slides, I believe that is
false.  If one had a server used solely for sidr, rather than sidr +
alt.whatever.stream.of.garbage, I believe it would be found to be very
low maintenance.  I haven't run a server for about 15 years, but I never
had trouble with the software and certainly the software has likely
improved rather than degraded.  The problems were always hardware (disk)
failures and the volume.

> This sure smells to me like a solution in need of multicast (or, more
> accurately, "deployed multicast") with a fall back to something like
> bittorrent for bootstrapping or when you've missed session data and
> can't recover.  Multicast as a data stream would be much more efficient
> is collecting updates, although there are still issues that would need
> to be worked through like "how do you know you heard everything".  Oh,
> and it only works if you multicast deployed to your site of course.

please, we do not want multicast as the only solution.  does your noc know
how to debug multicast forwarding problems?
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath

[heasley]

Wed, Mar 28, 2012 at 05:00:43PM +, Murphy, Sandra:
> Replacing ASs in the AS_PATH sounds like a behavior you would want the 
> security protections to prohibit.  It would enable attacks.
> 
> Can you explain how you would distinguish legitimate uses of this feature?

I've not used this feature, but from cisco's documentation, it doesnt appear
to function as raszuk described.

http://www.cisco.com/en/US/docs/ios/12_3t/12_3t11/feature/guide/gtbgpdas.html

if local-as is configured for a peer(-group), ie: if configured to peer as
a different AS than your own, such as for merging two ASes or changing your
ASN, then:
"The replace-as keyword is used to prepend only the local autonomous-system 
number (as configured with the ip-address argument) to the AS_PATH attribute. 
The autonomous-system number from the local BGP routing process is not 
prepended."

though I think that is unclear, I interpret it to mean that if my ASN is 1
and, I peer as ASN 2 with ebgp peer 3, then a route received from AS 3 will
have the path [2 3], but if configured with replace-as, it will be [3].

I do not believe that the feature allows the arbitrary replacement of AS path
elements.

> --Sandy
> 
> 
> From: sidr-boun...@ietf.org [sidr-boun...@ietf.org] on behalf of Robert 
> Raszuk [rob...@raszuk.net]
> Sent: Wednesday, March 28, 2012 12:43 PM
> To: Christopher Morrow
> Cc: i...@ietf.org List; Paul Jakma; sidr wg list
> Subject: Re: [sidr] [Idr]  AS_SET depreciation (RFC6472) and BGP multipath
> 
> >> Are we going to freeze any AS_PATH modifications by operator's policy too ?
> >> I mentioned replace-as which all major vendors support. There can be more
> >> knobs like this coming in the future.
> >
> > replace as i think is dealt with  sign again and pcount=0 and move 
> > along.
> 
> replace-as allows to replace any arbitrary match of list of ASes in the
> AS_PATH by your own AS. Does not need to be the last one.
> 
> I don't think SIDR has a solution to deal with such policy.
> 
> Best regards,
> R.
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] SIDR Interim 24/March is CANCELLED

[heasley]

oh, come on already.  error in timezone calculation.  it was cancelled and
no one has lost anything.  move on with life.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] BGP4 MIB module

[heasley]

Tue, Mar 20, 2012 at 04:28:15PM +0100, Bert Wijnen (IETF):
> So I had been in discussion with Jeff in order to see
> if we could get the BGP4-mibv2 module in good shape.
> 
> Below is out discussion.
> 
> Those who are interested in this MIB module at all
> may want to take a look to make sure they agree with
> the changes being proposed.
> 
> The most modules we're discussion are:
> 
> - drafts/draft-ietf-idr-bgp4-mibv2-13.txt
> - drafts/draft-ietf-idr-bgp4-mibv2-tc-mib-03.txt
> 
> In fact I had below discussion on bgp4-mibv2-12.txt,
> which resulted in revision 13.

I'm disappointed in the speed at which this draft has progressed.  I do
understand that mibs are often partially gated for/by trial implementation
(or so I've been told), but I have the impression its pace is wholly due to
the complexity of the proposed mib.  I also feel that there is a fair
amount of fluff that we find unnecessary for network management and would
be better suited to a separate mib; the RIBs, for example.  bgp4-mibv2
("lite"), bgp4-ribs, etc; or some approach that would allow the necessities
of peer state, nlri counts, and the like to progress without the fluff and
thus be more timely.

As such, I am unsure why its been brought to the sidr list, but I am hoping
that no attempt will be made to add SIDR-related stuff to this mib and
further delay adoption.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] rpki-rtr protocol maximum message length

[john heasley]

Tue, May 31, 2011 at 10:52:07AM -0700, Paul Hoffman:
> C or assembly-based implementations will need to malloc (etc.) the buffer for 
> the incoming message. Having that fit into 256 octets could easily have some 
> value to some implementations.

that magic could just as easily be 64 or 512 octets (or ...).  i dont
understand this concern or need of compensation that keeps coming up for
what seems like lousy implementations (of memory allocators, of ...).
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr