At 10:49 AM -0500 11/29/11, Danny McPherson wrote:
On Nov 29, 2011, at 10:36 AM, Christopher Morrow wrote:
I think this last bit gets at danny's concern (after the 'but every
asn in the path has to agree that the root is wrong' bit)... lots more
complexity here is not helpful :(
Yes.
-dan
On Nov 29, 2011, at 10:36 AM, Christopher Morrow wrote:
> I think this last bit gets at danny's concern (after the 'but every
> asn in the path has to agree that the root is wrong' bit)... lots more
> complexity here is not helpful :(
Yes.
-danny
___
On Tue, Nov 29, 2011 at 10:27 AM, Stephen Kent wrote:
> There are controls to allow RPs to ignore the expiration of the certs for
> the widget maker, but that's not the best outcome. Ultimately the widget
> maker
> would like to have a new CA cert issued to it, and continue to manage the'
> corres
At 7:53 PM -0500 11/28/11, Christopher Morrow wrote:
...
I think danny's example (as explained off-line in taipei) was something like:
o 3 cooperating ASNs (say: 701, 7018, 2914)
o one customer on either side of the 3 ASNs (a-widget-maker &&
a-widget-user/customer)
o All have RPKI + BGPSE
On Mon, Nov 28, 2011 at 5:13 PM, Stephen Kent wrote:
> At 10:09 PM -0500 11/21/11, Danny McPherson wrote:
>>
>> ...
>> > I don't understand all of the words above.
>>
>> Apologies for the loose terminology here.. Try this..
>>
>> AS1 --- ISP1 (AS2) --- ISP2 (AS3) --- AS4
>>
>> In the case of LTA
At 10:09 PM -0500 11/21/11, Danny McPherson wrote:
...
> I don't understand all of the words above.
Apologies for the loose terminology here.. Try this..
AS1 --- ISP1 (AS2) --- ISP2 (AS3) --- AS4
In the case of LTA if these four parties wish to transact their
constraints files
(or shared "
On Nov 16, 2011, at 2:50 AM, Stephen Kent wrote:
>
>> Here's my primary question. If I wanted to form a 'federation' of sorts for
>> resiliency would I have to use additional TALs in conjunction with my
>> LTA and paracertificate hierarchy? If so, can an RP include some sort of
>> filter to con
Danny,
Rob/Steve, et al.,
Relative to the SIDR Origin Ops draft and local trust anchor (LTA)
configuration, I'm trying to understand how one would actualize
trust anchor locators (TALs) and LTAs in a deployment scenario and
was hoping you could help me here.
A TAL points to a self-signed RPKI
On Mon, Nov 14, 2011 at 10:57 PM, Danny McPherson wrote:
>
> On Nov 14, 2011, at 10:07 PM, Christopher Morrow wrote:
>
>> On top of that if the resource is then re-certified (to the same or
>> different end entity) how do the intermediate parties know which is
>> the 'right' thing to do?
>
> Agree
On Nov 14, 2011, at 10:07 PM, Christopher Morrow wrote:
> On top of that if the resource is then re-certified (to the same or
> different end entity) how do the intermediate parties know which is
> the 'right' thing to do?
Agreed.. It's critical to highlight that LTA doesn't fix anything here
u
On Mon, Nov 14, 2011 at 7:02 PM, Danny McPherson wrote:
>
> On Nov 14, 2011, at 6:47 PM, Rob Austein wrote:
>
>> Layers 8+ are mostly out of scope for this list, so let me just say
>> that I am really hoping that IANA and the RIRs will get their
>> collective act together and issue a single TA bef
On Nov 14, 2011, at 6:47 PM, Rob Austein wrote:
> Danny,
>
> For purposes of this discussion, a LTA is semantically equivalent to a
> collection of TAs plus a constraint list. Since LTAs are also a more
> general mechanism (they can be shared by a group of like-minded folks
> more easily than a
Danny,
For purposes of this discussion, a LTA is semantically equivalent to a
collection of TAs plus a constraint list. Since LTAs are also a more
general mechanism (they can be shared by a group of like-minded folks
more easily than a constraint list -- just create a TAL pointing at
the LTA) and
Rob/Steve, et al.,
Relative to the SIDR Origin Ops draft and local trust anchor (LTA)
configuration, I'm trying to understand how one would actualize
trust anchor locators (TALs) and LTAs in a deployment scenario and
was hoping you could help me here.
I think it's probably safe to assume ever
14 matches
Mail list logo
