The SIDR Working Group will hold an interim meeting (with virtual
attendance) on April 30, 2012.
Location: Adjacent to the Dulles Airport, Reston, VA, USA 20190-4415
Time: 0900 - 1700 EDT
The draft agenda will be published on the SIDR mailing list prior to the
meeting.
_
I agree with the point of putting slide numbers on slides and with making that
a requirement got future presentations.
As for webex. There are features of webex that might be useful in remote
participation - letting a remote participant manage the slides, some control
over remote participan
On Thu, Mar 29, 2012 at 3:11 PM, Brian Dickson
wrote:
> I think the use cases are likely to be informed by protocol design, so even
s/informed by protocol design/altered if the protocol design changes/
I'm not sure if the protocol design's going to change the use-cases...
you're still going to
Hang on, and notwithstanding the request for WGLC.
I think the use cases are likely to be informed by protocol design, so even
if they are baked, I'd argue that at best that would be only halfway baked.
I have a few examples that I can think of, which would necessarily depend
significantly on des
Alright, I'll tackle that tomorrow morning.
-chris
(cochair)
On Fri, Dec 9, 2011 at 9:03 AM, Sriram, Kotikalapudi
wrote:
> Sandy,
> Chris,
>
> The WGLC on this doc ended 09/22/2011.
> We (the authors) submitted a substantially revised version on October 31,
> 2011,
> taking into careful conside
-secretary
We needed to send the announcement for the first date, in order to hit
it, depending on attendence numbers we would be either in Reston for
~20 people or Arlington for 'more' (30).
If the number of remote possibles is higher than in-person we should
take the opportunity to run a fully
Hello IESG Secretary,
Please send out an announcement to the right places for an interim
meeting (plus virtual attendance) for the SIDR-wg, April 30, 2012.
Location: Adjacent to the Dulles Airport, Reston, VA, USA 20190-4415
Time: 0900 - 1700 EDT
Draft agenda to be sent ~4/10/12.
Thanks!
-Chris
Andrew expressed surprise when he looked at the slides displaying in
Wednesday's session. People looking at the slides remotely were also probably
surprised.
That's because andrew sent a set of updated slides shortly before the meeting.
I was already cut off from email getting webex and such s
On 3/29/2012 3:58 AM, Jakob Heitz wrote:
Any place that does not receive a new BGP update can not be helped.
Even with a beacon.
Just to be clear, the explicit expire time approach to freshness does
work to age-out updates along a update path that is no longer
bgp-reachable from the origin.
> o but we do not know the long term scaling characteristics of the
> current rsync scheme.
While we may not know the scaling characteristics of the solution, do we
at least know what would be a desirable objective target for sustainable
deployment?
> o we could get much better rsync per
On Mar 29, 2012, at 5:01 AM, Randy Bush wrote:
>>> Serial Notify, sec 5.2 of draft-ietf-sidr-rpki-rtr-26.txt, provides
>>> such a mechanism
>> Not what I'm talking about.
>>
>> What notifies a cache that it needs to fetch new objects from a RPKI
>> repository? As best I understood, it's largely
just a note at the high level
o anyone who thinks rsync is not gonna do well for the scaling we are
likely to see in the next year+ is smoking some strong optimism.
we're only at 5k objects today, three months into the game.
o but we do not know the long term scaling characteristics o
Let's just require that BGPSEC capable routers
also support 4 byte AS. Then we don't need to worry
about AS4_PTH.
--
Jakob Heitz.
From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of Shane
Amante
Sent: Thursday, March 29, 2012 6:04 AM
To: Ste
> At Wed, 28 Mar 2012 20:33:24 -0400, Danny McPherson wrote:
>
> If you're talking about moving all of the existing SIDR protocols to
> Experimental, that's a cheap shot and you know it.
I didn't say that.
> If you're just talking about RPKI over BitTorrent, the BitTorrent
> experiment was just t
Steve,
Thanks for the response. First, a high-level comment before more specific
responses below.
The challenge I'm having is trying to reconcile threats against the existing
AS4_PATH attribute vs. threats against the BGP_Path_Signature attribute. More
specifically, the AS4_PATH attribute
>i don't think the rsync scale issues surprise anyone that was paying
>attention.
I am not sure what part of the presentation you are talking about. In the "day
in the life" presentation, I saw only differences due to implementation, not
differences due to scale.
And in the "rpki over bitto
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
>> Serial Notify, sec 5.2 of draft-ietf-sidr-rpki-rtr-26.txt, provides
>> such a mechanism
> Not what I'm talking about.
>
> What notifies a cache that it needs to fetch new objects from a RPKI
> repository? As best I understood, it's largely done on cron jobs now.
ahh. yes. if we do a next-ge
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
Sandra,
I attend the meeting remotely on both Monday and Wednesday. I did not feel the
need for Webex as the audio streaming + jabber worked just fine.
My only comment is to re-emphasize what was mentioned by Wes on the jabber
room, please request including page numbers on presentation decks t
> 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-ietf-sidr-rpki-rtr-26.txt, provides such
a mechanism
randy
___
At Wed, 28 Mar 2012 20:33:24 -0400, Danny McPherson wrote:
>
> i don't think the rsync scale issues surprise anyone that was paying
> attention. If we're already considering new architectures,
> substrates, et al., here perhaps we shouldn't be so quick on the
> trigger for Standards Track work an
Jeff and Jakob:
Several people shared the qualm that "AS-SETS" would be necessary.
However, Sandy has always posited that aggregation creates a point of
change/risk. So, are we just trying to reduce this risk by providing lists
of certificates for paths?
Or is would an AS-Sets originated at a
At Wed, 28 Mar 2012 08:57:19 -0400, Christopher Morrow wrote:
>
> Draft Author Ship Steerers,
> This we didn't chat about at the meeting(s), but are there outstanding
> bits/pieces or should this be sent along for WGLC in the near future?
Not ready yet. A few year's experience of using this prot
Shane,
To expand on my comments at the mic earlier today on this draft, I
think there is universal acknowledgment that there should be
statements that attacks involving path shortening should be
acknowledged as a "threat" in this document.
Section 4.2, near the top of page 12, addresses thi
On 3/29/12 10:24 , Christopher Morrow wrote:
> On Thu, Mar 29, 2012 at 4:16 AM, Jeffrey Haas wrote:
>> 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 kno
On Thu, Mar 29, 2012 at 4:16 AM, Jeffrey Haas wrote:
> 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 t
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 8:33 PM, Danny McPherson wrote:
>
> i don't think the rsync scale issues surprise anyone that was paying
> attention. If we're already considering new architectures, substrates, et
> al., here perhaps we shouldn't be so quick on the trigger for Standards Track
> work an
Any place that does not receive a new BGP update can not be helped. Even with a
beacon.
Therefore, a freshness indicator in the BGP update itself is enough to
invalidate less fresh updates.
Only freshen the BGP update when you actually have a dispute with your old
provider.
--
Jakob Heitz.
O
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.
Here is the key point:
The new update will reach everywhere that it needs to go.
Won't it?
No expiry time needed.
--
Jakob Heitz.
__
of course, we would need to reinvent the AS_SET to go along with it, but this
time, enumerating each exact path.
Definitely unwieldy.
--
Jakob Heitz.
On Mar 29, 2012, at 9:10 AM, "Jeffrey Haas" wrote:
> On Wed, Mar 28, 2012 at 05:57:32PM -0400, Jakob Heitz wrote:
>> This can be done.
>> Like
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 fresher data available
34 matches
Mail list logo
