On Thu, Sep 26, 2013 at 5:19 PM, George, Wes wesley.geo...@twcable.com wrote:
[WEG] close enough, ship it.
hurray! :) (I'm also ok with the last edit buffer fun)
thank wes and randy for a fun discussion.
-chris
___
sidr mailing list
sidr@ietf.org
From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of
Randy Bush
how about
To relieve routers of the load of performing certificate validation,
cryptographic operations, etc., the RPKI-Router protocol, [RFC6810],
does not provide object-based security to the
To relieve routers of the load of performing certificate validation,
cryptographic operations, etc., the RPKI-Router protocol, [RFC6810],
does not provide object-based security to the router. I.e. the
router may not validate the data cryptographically from a well-known
trust
From: Randy Bush [mailto:ra...@psg.com]
i don't even know what geographic redundancy is, alternate earths?
[WEG] nah, the latency is too high until we sort out IP over Quantum
Entanglement. ;-) Geographic redundancy in the context of things that live on
servers is that it exists on servers in
From: christopher.mor...@gmail.com [mailto:christopher.mor...@gmail.com]
[CLM]
In the RPKIcache example, 'consumer' is 'routers in your network'.
'Close' is 'close enough that bootstrapping isn't a problem', balanced
with 'gosh, maybe I don't want to put one on top of each router! plus
On Wed, Sep 25, 2013 at 12:38 PM, George, Wes wesley.geo...@twcable.com wrote:
From: christopher.mor...@gmail.com [mailto:christopher.mor...@gmail.com]
[CLM]
In the RPKIcache example, 'consumer' is 'routers in your network'.
'Close' is 'close enough that bootstrapping isn't a problem',
[WEG] that's part of my issue - the only way that you get close
enough that bootstrapping isn't a problem is when the cache and
router are directly
there's some baseline that's acceptable, you intimate that IGP comes
up before EGP below. that makes some sense, and thus maybe the target
is
how about
To relieve routers of the load of performing certificate validation,
cryptographic operations, etc., the RPKI-Router protocol, [RFC6810],
does not provide object-based security to the router. I.e. the
router may not validate the data cryptographically from a well-known
From: Randy Bush [mailto:ra...@psg.com]
i think the two paragraphs you would like to see improved are
[snip]
i am not against further explanation, send text. but short text. :)
[WEG] just the first paragraph really, and as I'll note below - I'd love to
send text, but I don't understand one of
hi wes,
why does proximity matter? Is this just an extension of the trust
domain and limited dependence on routing protocols? If so, I'd
dispense with recommending close because it confuses the issue and
just keep the discussion about secondary dependencies and trust
domains.
are you really
Following this line of reasoning (which is not unreasonable); if the
router requires the cache to arrive at correctness, maybe the cache
should be _inside_ the router.
yep. but no chance of it fitting in existing routers, and routers today
don't have the crypto oomph to validate (frequently).
On Tue, Sep 24, 2013 at 12:26 PM, George, Wes wesley.geo...@twcable.com wrote:
From: Randy Bush [mailto:ra...@psg.com]
i think the two paragraphs you would like to see improved are
[snip]
i am not against further explanation, send text. but short text. :)
[WEG] just the first paragraph
-
From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-
boun...@ietf.org] On Behalf Of The IESG
Sent: Tuesday, September 17, 2013 10:52 AM
To: IETF-Announce
Cc: sidr@ietf.org
Subject: Last Call: draft-ietf-sidr-origin-ops-21.txt (RPKI-Based
Origin Validation Operation) to Best Current
However, the concerns I raised during WGLC in
http://www.ietf.org/mail-archive/web/sidr/current/msg05010.html
regarding the ambiguity of some of the guidance regarding location of
RPKI caches (close) in section 3 still have not been addressed. IMO
if it is important enough to discuss
take two paragraphs and call back in the morning if you are still in
pain :)
randy
In order that routers need not perform certificate validation,
cryptographic operations, etc., the RPKI-Router protocol, [RFC6810],
does not provide object-based security to the router. I.e. the
The IESG has received a request from the Secure Inter-Domain Routing WG
(sidr) to consider the following document:
- 'RPKI-Based Origin Validation Operation'
draft-ietf-sidr-origin-ops-21.txt as Best Current Practice
The IESG plans to make a decision in the next few weeks, and solicits
final
16 matches
Mail list logo
