On Mon, Dec 14, 2015 at 12:09:09PM -0500, John G. Scudder wrote:
> Hi Everybody,
>
> Just when we thought we were completely done with this draft, we were
> approached by Thomas King who pointed out a use case that can be enabled by
> validation signaling, which benefits from a minor revision in
On Thu, Apr 12, 2012 at 01:07:38PM -0400, George, Wes wrote:
> [WEG] I'm not totally sure which message you're referring to, but I think
> that may be a red herring. I'm not seeing how incrementing the BGP version
> automatically means that all routers in an ASN must upgrade to it.
Fish aside, g
On Thu, Apr 12, 2012 at 11:28:44AM -0400, Christopher Morrow wrote:
> you don't seem to disagree that the functionality could be there, so
> ... 'violent agreement'!
I think what I'd be saying is "if you want this to be done at point of
origination", there's significant work to be done.
- Jeff
__
On Wed, Apr 11, 2012 at 03:53:29PM -0400, Christopher Morrow wrote:
> > Functionally, confed segments are stripped prior to the global AS being
> > added to the path. ?The box performing this function is the one that needs
> > to amend the BGPSEC signature, not some box in the middle of the
> > con
On Thu, Apr 12, 2012 at 03:52:29PM +0200, Robert Raszuk wrote:
> I very much agree with both Paul and Wes that new BGP version number
> or at least new set of AFIs would be the best way to smoothly
> migrate unsecure BGP to secure one.
If it's not backward compatible, sure.
> I have not seem anyo
On Wed, Apr 11, 2012 at 12:17:40PM -0400, Jakob Heitz wrote:
> Confeds are out of scope.
>
> VPN address families are out of scope.
Meaning that the AS_PATH has to be present. No?
(I suspect you mean yes. That's the matter at hand.)
> If the BGPSEC path does not match the AS_PATH, the update
On Wed, Apr 11, 2012 at 12:28:32PM -0400, Christopher Morrow wrote:
> On Wed, Apr 11, 2012 at 12:17 PM, Jakob Heitz
> wrote:
> > Confeds are out of scope.
>
> how are confeds out of scope?
> if you want path validation for ibgp/originated-by-you routes and the
> originating router is in one of t
I'm not at my usual spot in the week to catch up on IETF mail, but this
thread is noisy enough that it's caught my attention anyway. :-)
On Tue, Apr 10, 2012 at 01:37:34PM -0400, Warren Kumari wrote:
> I think that sone of the biggest issues to keep in mind with carrying the
> "same" data in two
On Thu, Mar 29, 2012 at 02:01:24PM +0200, Randy Bush wrote:
> ahh. yes. if we do a next-gen rpki flooding mechanism, that would be a
> good addition.
Agreed. It certainly belongs in there.
> to a bgp hacker everything looks like a nail, eh? how about a sip
> notification? :)
Just a minor co
Randy,
On Thu, Mar 29, 2012 at 01:41:23PM +0200, Randy Bush wrote:
> > Just to be clear, this is not a route freshness mechanism I am
> > recommending. What I am recommending is a signal that a repository
> > has newer data that may be needed for validation.
>
> Serial Notify, sec 5.2 of draft-i
Sandy,
On Wed, Mar 28, 2012 at 05:00:43PM +, Murphy, Sandra wrote:
> 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?
The featur
Jakob,
On Thu, Mar 29, 2012 at 03:51:10AM -0400, Jakob Heitz wrote:
> Could we not put a freshness indication into the BGP update?
> Then everyone that receives the new update would know to invalidate the less
> fresh paths.
Just to be clear, this is not a route freshness mechanism I am
recommen
On Wed, Mar 28, 2012 at 09:02:24PM -0400, Danny McPherson wrote:
> On Mar 28, 2012, at 4:19 AM, Jeffrey Haas wrote:
> > Per my mic comment at IETF 83:
> > During the San Diego interim session we had discussed potentially signaling
> > in BGP the idea that a given AS may have f
On Wed, Mar 28, 2012 at 12:45:22PM -0400, Christopher Morrow wrote:
> ah yes, was thinking of local-as. the 'replace-as' seems like
> loop-creation, joy.
For the list, as I mentioned in SIDR, the use of local-AS where the router
has more than one local AS will generate AS_SETs in some implementati
On Wed, Mar 28, 2012 at 10:56:52AM -0400, Jakob Heitz wrote:
> The issue is SIDR can not aggregate multiple paths.
>
> Solutions I can think of:
> 1. Aggregate the signatures of the paths being aggregated.
What are the semantics you're trying to preserve SIDR-wise? We're hitting
the realm where
Paul,
On Wed, Mar 28, 2012 at 02:10:04PM +0100, Paul Jakma wrote:
> Where's the document to describe how to do multi-pathing using
> add-path? E.g. what should happen when there is a non-add-path
> capable neighbour?
In add-path, this is no different than receiving routes from directly
attached p
Chris,
On Wed, Mar 28, 2012 at 12:45:22PM -0400, Christopher Morrow wrote:
> ah yes, was thinking of local-as. the 'replace-as' seems like
> loop-creation, joy.
It can. The use of replace-as is typically in situations where you need to
replace private AS numbers with a public number. This is typ
On Wed, Mar 28, 2012 at 01:30:03AM -0700, Terry Manderson wrote:
> I think this is interesting. I think I would further like an
> assessment/disussion of this "serial number" being consistent between the
> BGP information, the RPKI repository, and this through the validated cache
> and presented to
Per my mic comment at IETF 83:
During the San Diego interim session we had discussed potentially signaling
in BGP the idea that a given AS may have fresher data available in its
repository.
My original thought had been something along the lines of a new AFI/SAFI
that contains this data. Matt L.,
Per mic comment:
The slides propose a 8 octet "reserved field".
Instead, consider making it a container for TLVs. Length field of 2 octets.
Consider immediately specifying TLVs in it: 1 (or 2?) octet code point, 2
octet lengths. Immediately request a registry for this reserved section
with first
Brian,
On Mon, Mar 05, 2012 at 07:32:25PM -0500, Brian Dickson wrote:
> Greetings, SIDR folks,
>
> Here is the notice on the ID for the route leak "requirements" document.
I am likely misunderstanding something in this document, but my
interpretation of it is that routes are always colored based
Brian,
On Mon, Mar 05, 2012 at 07:31:23PM -0500, Brian Dickson wrote:
> Here is the first of three IDs, concerning the definitions of "route leak".
: 1.1. Rationale
:
:
:A route-leak occurs when a prefix is originated by one party,
:propagated by other parties, and received by the obse
Per the microphone at SIDR on Friday:
1. Text should be added to strongly recommend that when a route that is
about to expire is having an update of the expiration advertised that
receiving peers should treat the reception of an update with no other
changes to the reachability than the expiration
Bill,
On Thu, Aug 05, 2010 at 10:50:42AM +, bmann...@vacation.karoshi.com wrote:
> On Thu, Aug 05, 2010 at 12:28:12PM +0200, Randy Bush wrote:
> > > Answer the second paragraph in the context of *unedited cache
> > > consistency*
> >
> > givem the rpki operational structure, it would be deli
On Wed, Aug 04, 2010 at 10:29:40PM +0200, Randy Bush wrote:
> this document is not about how, why, and under what policies you get
> whatever you get into whatever cache(s) you trust.
Ignore policy. Answer the second paragraph in the context of *unedited
cache consistency* from the same mail you
On Wed, Aug 04, 2010 at 03:41:17PM -0400, Rob Austein wrote:
> > A provider may wish to override validated RPKI data for their own purposes.
> > While not explicitly a SIDR-driven requirement, this was discussed multiple
> > times as a requirement during the original RPSEC work.
>
> What RPSEC did
On Wed, Aug 04, 2010 at 08:37:07PM +0200, Randy Bush wrote:
> there are no redundantly configured caches.
: 7. Router-Cache Set-Up
: [...]
:A router may be configured to peer with a selection of caches
> there are no database version numbers.
That was my proposal and not my assertion that yo
To amend my last post:
On Wed, Aug 04, 2010 at 07:02:09PM +, Jeffrey Haas wrote:
> Implementation/Deployment models:
> 1. The Local Cache with resulting routing origin policy and the rpki-router
> protocol server are in the same box.
>
> In this model, the provider will likely
On Wed, Aug 04, 2010 at 02:06:53PM -0400, Rob Austein wrote:
> At Wed, 4 Aug 2010 17:44:24 +0000, Jeffrey Haas wrote:
> >
> > My concern is that if a cache is out of step with the policy server
> > that is used to populate that cache.
>
> This description makes no
Rob,
Thanks for a clearer answer than Randy's.
On Wed, Aug 04, 2010 at 01:08:08PM -0400, Rob Austein wrote:
> If it really cares whether the caches are exactly in sync, it could
> compare the results, but I doubt that doing so would be particularly
> useful. This protocol is presenting a live v
On Wed, Aug 04, 2010 at 06:49:16PM +0200, Randy Bush wrote:
> > The use-case I have in mind is that a given provider may have a number of
> > cache servers deployed within their network. A given router may wish to
> > have a session with two servers for redundancy purposes.
>
> do not do it
It s
Could the authors comment on the expected behavior of a single router with a
pair of sessions to cache servers operated by the same provider which
implement the same RPKI policy?
The use-case I have in mind is that a given provider may have a number of
cache servers deployed within their network.
In addition to the energetic discussion about the terminology for the three
states of the community, I'd also like to suggest that the origin of the
validation may be relevant. The cache protocol gives a data source for the
validation and that source probably should be represented within this
comm
On Sun, Aug 01, 2010 at 11:20:48PM -0700, Pradosh Mohapatra wrote:
> I support Jeff's proposal for matching the "first AS after AS_SET" with the
> [AS4_]AGGREGATOR attribute.
Just to be clear, this is Sriram's proposal. I'm just suggesting some
additional language for protocol clarity. :-)
> If
On Thu, Jul 29, 2010 at 05:41:01AM -0400, Sriram, Kotikalapudi wrote:
> Thanks, Jeff.
> One more clarification request:
> What do you mean when you say "first non-sequence AS"?
I mean I had a typo. That should have read first non-set AS.
Just to be clear, consider the following cases:
1 2 3 4
On Thu, Jul 29, 2010 at 10:33:30AM +0200, Randy Bush wrote:
> > IMO that's not the problem. The problem is that we don't want to have
> > special mechanisms for cases that occur 0.0007% (or is 0.02%?) of the
> > time.
>
> bingo!
>
> > It's like creating a special shampoo product line for albinos.
Sriram,
On Thu, Jul 29, 2010 at 04:14:46AM -0400, Sriram, Kotikalapudi wrote:
> We need not look inside the AS_SET, and also we would require no ROAs for the
> AS_SET.
> Simply take the AS to the immediate left of the AS_SET to be the origin.
> The update/RIB data establish clearly that the ASN
On Wed, Jul 28, 2010 at 04:22:50PM +0200, Randy Bush wrote:
> want knob to just not bother with aggs. they are a teensie weensie bit
> of the routes, often bizarre (have only self, have three copies of self,
> private asns, ...), why should i pay with complexity (== fragility) to
> accommodate the
On Wed, Jul 28, 2010 at 11:54:38AM -0400, Sandra Murphy wrote:
> The problem is the possibility that not accommodating legitimate BGP
> updates might result in opportunities for bad guys to get around
> protections.
>
> So we need to have some statement of what to do with this legitimate BGP
>
Specifically with regard to the presentation on Measurement Data on AS_SET
and AGGREGATOR: Implications for {Prefix, Origin} Validation Algorithms:
When an AS_SET is present in a BGP Update, it isn't required that it is the
right-most segment type. While this is certainly the most typical scenari
Robert,
On Tue, Nov 18, 2008 at 09:40:19AM -0600, Robert Kisteleki wrote:
> After my (rushed) presentation yesterday I'd like to ask if there are
> people in the WG who think that this idea is worth pursuing and should it
> be a WG item?
>
> http://www.ietf.org/internet-drafts/draft-kisteleki-si
On Thu, Jul 17, 2008 at 04:02:34AM -0400, Rob Austein wrote:
> > To put it in a slightly different way, what I wondering was is there a
> > means of specifying this "minimal expression" you refer to?
>
> Aye, that is the question. I've tried to specify an algorithm for
> this twice already, and f
On Tue, Jul 15, 2008 at 06:49:49AM +1000, Geoff Huston wrote:
> My question is: is it of any value to define a "canonical" format for a
> ROA?
I don't think it adds much in the way of value to enforce this within
the ROA. The noise it adds is harmless.
-- Jeff
_
On Thu, May 29, 2008 at 02:05:16PM -0400, Sandy Murphy wrote:
> It might be judged "apathy", though.
The SIDR work is a hyperfocused implementation of esoteric security
issues. Admittedly those issues have broad impact on the Internet but
they are arcane enough that even those who want to follow
Chiming in a bit late after catching up on other IETF tasks:
On Fri, Apr 04, 2008 at 09:46:29AM -0400, Sandra Murphy wrote:
> This internet draft was presented at the sidr meeting in Philadelphia.
> Please state whether you believe that this is appropriate to adopt as a
> working group work item
Terry,
On Sat, Mar 15, 2008 at 06:13:32AM +1000, Terry Manderson wrote:
> I'm not going to go back through the process of discussing the merits
> and downfalls of RSYNC or any other competing protocol or service that
> might be used as the fetch mechanism.
And this was not my original point.
Florian,
On Thu, Mar 13, 2008 at 07:59:02PM +0100, Florian Weimer wrote:
> It's not clear to me if you need rsync's capability for transmitting
> collections of files.
This is the major advantage of using rsync. When you must sync a large
number of files, it is *very* efficient.
For our purpose
On Tue, Mar 11, 2008 at 02:00:27PM -0400, Sandra Murphy wrote:
> Of course, there's always the "the relying parties choose what importance
> to place on the RPKI" caveat.
Not to mention it's influence on one's "security metric".
(Fake config to drive point.)
route-map set-security-pref 10
mat
On Tue, Mar 11, 2008 at 07:57:13AM -0600, Danny McPherson wrote:
> So, I'm sure suspect I'm missing something here, could folks
> please help me better understand both incremental deployment
> models and how the above isn't an issue?
Multiple trust anchors and multiple ROAs.
The current ROA model
Last night during the SIDR session, I made the suggestion that a
matching profile should exist for an AS to say what prefixes it intended
to announce. While having matching entries from this proposed profile
and the ROA may help prevent some malicious announcements with spoofing
the origin AS, I t
Consider the case where an ISP has the following prefixes:
A1, A2, B, C, D
A1 and A2 are aggregateable.
B, C and D are not aggregateable.
Consider the case where A2, B, C and D are delegated by a given RIR. I
would expect to have a ROA for this. This would have a single
signature.
Similarly,
On Thu, Feb 28, 2008 at 01:34:49PM -0500, Sandra Murphy wrote:
> When I say origination of route advertisements, I am not talking about the
> ORIGIN attribute in the BGP Update.
I'd suggest refering to this as the originating AS.
-- Jeff
___
Sidr maili
52 matches
Mail list logo
