Speaking as regular ol' member.
Too bad you couldn't make the meeting, Danny.
This is in bgpsec path validation and the signalling would go no further than
the bgpsec path validation would go.
A method of signalling that was mentioned was the validity periods on the
router keys so all RPKI
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 in its
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 jh...@pfrc.org wrote:
On Wed, Mar 28, 2012 at 05:57:32PM -0400, Jakob Heitz wrote:
This can be
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.
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.
On Wed, Mar 28, 2012 at 8:33 PM, Danny McPherson da...@tcb.net 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
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
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 feature
On Thu, Mar 29, 2012 at 4:16 AM, Jeffrey Haas jh...@pfrc.org 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.
On 3/29/12 10:24 , Christopher Morrow wrote:
On Thu, Mar 29, 2012 at 4:16 AM, Jeffrey Haas jh...@pfrc.org 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
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 this
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
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 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 and
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
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
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
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-gen rpki
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
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
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
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
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 done on cron
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
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
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
-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
Alright, I'll tackle that tomorrow morning.
-chris
(cochair)
On Fri, Dec 9, 2011 at 9:03 AM, Sriram, Kotikalapudi
kotikalapudi.sri...@nist.gov wrote:
Sandy,
Chris,
The WGLC on this doc ended 09/22/2011.
We (the authors) submitted a substantially revised version on October 31,
2011,
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
On Thu, Mar 29, 2012 at 3:11 PM, Brian Dickson
brian.peter.dick...@gmail.com 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
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
31 matches
Mail list logo
