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
estab
BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft CDO for Microsoft Exchange
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Asia/Taipei
BEGIN:STANDARD
DTSTART:19790930T00
TZOFFSETFROM:+0900
TZOFFSETTO:+0800
RDATE:19790930T00
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19790630T00
TZOFFSETFROM:+0800
TZOFFSETTO:
Hi everyone,
this plain email just in case someone can't read the invite in my previous
email.
This email provides instruction to connect to the video bridge that will allow
us to share documents at the BoF. We will use the audio stream in the room.
If room audio is not available, we will advi
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 imple
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
jus
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:
>
The audio streaming in the room is not working so
we'll be using Webex for remote audio. All
presenters and speakers will use headsets or
PC mikes for speaking.
Please join the Webex below and get audio
there.
Thanks,
Steve
> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ips
Hello all!
I would like to thank everyone for the much enlightening discussion.
>From what I've gathered from the discussion and the documents that
have been referred is that ESP provides the same level of security in
the IPv6 unicast transport mode case, with one exception:
ESP doesn't protect
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 ha
By the way, header compression in IPsec is standardized in RFC 5856/7/8.
I don't know if anybody's implemented this stuff.
Yaron
On 16/11/2011 18:37, Paul Wouters wrote:
On Tue, 15 Nov 2011, Vilhelm Jutvik wrote:
As for the (apparently widely held) belief that transport mode is
redundant
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 hund
On Wed, Nov 16, 2011 at 2:02 AM, Yoav Nir 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
--
___
IPsec mai
> "Mike" == Mike Sullenberger 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 traffi
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. T
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
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 a
>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
18 matches
Mail list logo
