[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Tunnel fragmentation/reassembly for RRG map-and-encaps architectures
On Jan 16, 2008, at 8:10 AM, Noel Chiappa wrote:
My advice to the LISP people was that they didn't need to implement
security stuff in any prototype implemenatations they were doing
manpower is limited, and the chief concern is trying to get some
data on things like delays, unforseen operational issues, etc),
doesn't change the fundamentals of the operation at all; it's just
sugar layered over everything.
However, it has all been thought through and worked out, to make
the basic architecture they are trying out *is* securable.
As you mentioned elsewhere, there is no progress without pain. One
of those pain points is that security is now a much more stringent
requirement today than it was previously, and having proven, deployed
security mechanisms as part of a proposal would seem to be a Very
Good Thing, IMHO. Just having the claim that something is securable
is only going to hold so much water and will definitely attract
On Jan 16, 2008, at 8:33 AM, Brian Dickson wrote:
We don't need to reinvent the wheel, IMHO - just take advantage of
That would be fine by me. However, DNSsec has been awaiting
deployment for about a decade now. I'm not hopeful that this is
going to happen anytime soon.
More generally, my friends in the security and operations communities
point out that, in general, approaches with a full blown PKI
infrastructure are simply too heavyweight to be pragmatically
deployable. There are simply too many interdependencies. Their
strong suggestions point much more towards pairwise security and/or
web-of-trust approaches (ala PGP).
On Jan 16, 2008, at 2:11 PM, Brian Dickson wrote:
There's two distinct things:
1) how to *publish* the data;
2) how to *serve* the data
Both need to be secure to be trustworthy.
Is this really true? Does serving the data truly need to be secure
as long as the data is authentic, accurate, timely, etc.?
If we can avoid securing the mapping transport layer, it would be a
very big win.
to unsubscribe send a message to firstname.lastname@example.org with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg