On Sat, Apr 02, 2011 at 11:22:18AM +0200, Matthias Waehlisch wrote:
| Hi Hannes,
|
| On Fri, 1 Apr 2011, Hannes Gredler wrote:
|
| > so i'd be much more in favour of TCP-AO or even TCP-MD5 (did i mention
| > that i am no security guy ;-)), since those are the standard tools to
| > protect messa
Sandra Murphy wrote on 01-04-11 22:24:
>
>
> On Fri, 1 Apr 2011, Andrei Robachevsky wrote:
>
>> Hi,
>>
>> I propose the inclusion of the following requirement:
>>
>> 3.x A BGPsec design should not decrease the performance characteristics
>> of the BGP, nor have a negative impact on the overall r
On Apr 4, 2011, at 4:32 AM, Hannes Gredler wrote:
>
> so my question is: "why do we need to solve the same problem
> (= protecting message integrity) 2 times in different ways" ?
This new machinery simply introduces object-level integrity functions
in the application (i.e., BGP), it does nothi
On Mon, Apr 04, 2011 at 08:22:42AM -0400, Danny McPherson wrote:
|
| On Apr 4, 2011, at 4:32 AM, Hannes Gredler wrote:
|
| >
| > so my question is: "why do we need to solve the same problem
| > (= protecting message integrity) 2 times in different ways" ?
|
| This new machinery simply introduce
-Original Message-
From: Carlos Martinez-Cagnazzo [mailto:carlosm3...@gmail.com]
Sent: Sunday, April 03, 2011 8:49 PM
To: George, Wes E [NTK]
Cc: sidr@ietf.org
Subject: Re: [sidr] BCP for implementing RPKI?
That said, I believe documenting best practices is always a good idea.
Do you thin
On Mon, Apr 4, 2011 at 8:50 AM, Hannes Gredler wrote:
> On Mon, Apr 04, 2011 at 08:22:42AM -0400, Danny McPherson wrote:
> |
> | On Apr 4, 2011, at 4:32 AM, Hannes Gredler wrote:
> |
> | >
> | > so my question is: "why do we need to solve the same problem
> | > (= protecting message integrity) 2 t
On Apr 3, 2011, at 18:17 MDT, George, Wes E [NTK] wrote:
> While we have an operational considerations document that covers origin
> validation, it focuses mainly on policy and implementation
> details of the validation machinery. We don't have anything that covers the
> back-end of implementing
> some folks (not me) suggest that ipsec is the way to go here... (bgp I
> mean) I think one point to keep in mind is that tcp-ao has exactly
> zero implementations... while SSH implementations abound.
turns out that
o yfv may have ssh client and server, but they do not have the library
in
At 1:24 PM -0400 4/2/11, Russ White wrote:
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="enig5992EC3DE2163EED1CCB39EC"
As it stands now, BGPSEC is opt-in.So it seems that clearly
documenting these issues is more operative t
> I propose the inclusion of the following requirement:
>
> 3.x A BGPsec design should not decrease the performance
> characteristics of the BGP, nor have a negative impact on the overall
> resilience of the routing system.
ok. i'll bite. i think this is worthwhile desire. but as an internet
r
At 12:17 AM + 4/4/11, George, Wes E [NTK] wrote:
...
Put another way, a lot of the folks involved in this protocol's
design and implementation are already intimately familiar with how
to manage things like ROAs to ensure that the underlying trust of
the system is not compromised.
A minor
11 matches
Mail list logo
