Posting again with a different subject so that this doesn't drown in the other
back and forth. Please do not reply to this message.
Hi.
Steve has come up with a formulation for the subject for discussion tonight:
In an environment with many IPsec gateways and remote clients that share an
You are mixing everything up. It is too much work to correct you over email. I
will try to help you at the meeting.
regards,
fred
On 16 Nov 2011, at 15:35, Yoav Nir wrote:
OK.
Routing protocols are not security protocols. That's fine. Neither is HTTP.
BGPSEC and SIDR implement
I think we will benefit greatly if we focus tonight's
meeting mainly on discussion of and perhaps agreement
on the PROBLEM TO BE SOLVED.
Comparison and analysis of proposed solutions should
wait until we have agreed on the problem statement
and the requirements derived from that. And, as we've
OK. A dumber but more practical question: Do you have any idea how we can get
microphones?
The projector is indeed here, but the microphones seem to be missing.
Keeping the audio stream running all night doesn't help if the mikes are gone...
On Nov 16, 2011, at 7:13 PM, Stephen Hanna wrote:
On Tue, 15 Nov 2011, Vilhelm Jutvik wrote:
As for the (apparently widely held) belief that transport mode is
redundant I would like to voice my opinion in defense of it: Tunnel
mode incurs an overhead due to the extra IP header. In the case of
IPv6 that overhead will be over 40 bytes and will
On Wed, 16 Nov 2011, Frederic Detienne wrote:
And like I said earlier, the amount of negotiation when there are multiple prefixes to
protect is limited to one. With modern ipsec tunneling (got to love that),
there is still a lot of negotiation going on.
We are talking about potentially
On Wed, Nov 16, 2011 at 2:02 AM, Yoav Nir y...@checkpoint.com wrote:
Steve has come up with a formulation for the subject for discussion tonight:
Thank you. That synthesis is short and clear and helped me cut
through the otherwise too-long thread.
Nico
--
Mike == Mike Sullenberger m...@cisco.com writes:
Mike We use other tunnel mechanisms (GRE), because IPsec tunneling
Mike mode is lacking in functionality. For example, when you use
Mike GRE for the tunneling you also reduce the IPsec SA's that are
Mike needed to describe the
On Nov 17, 2011, at 2:17 AM, Michael Richardson wrote:
Mike I am not sure where you are getting a set of extended
Mike access-lists. There aren't any extended access-lists added.
Mike If a packet is routed through the tunnel it is encapsulated
Mike and then encrypted. There
On Thu, 17 Nov 2011, Yoav Nir wrote:
Not necessarily. If your device drops packets that come through the wrong
tunnel, you're safe. Typically in a complex network you will allow multiple paths through
the overlay network, and then some spoofing can happen.
So you want privacy, not security.
On Nov 17, 2011, at 9:31 AM, Paul Wouters wrote:
On Thu, 17 Nov 2011, Yoav Nir wrote:
Not necessarily. If your device drops packets that come through the wrong
tunnel, you're safe. Typically in a complex network you will allow multiple
paths through the overlay network, and then some
Vilhelm Jutvik writes:
ESP doesn't protect the immutable parts of the IPv6 header nor those
of any extension header. Both source as well as IP destination field
can be verified by comparing them to the information found in the
associated SA's traffic selector, but extension headers can be
On Tue, 15 Nov 2011, Vilhelm Jutvik wrote:
As for the (apparently widely held) belief that transport mode is
redundant I would like to voice my opinion in defense of it: Tunnel
mode incurs an overhead due to the extra IP header. In the case of
IPv6 that overhead will be over 40 bytes and will
13 matches
Mail list logo
