On Thu, Nov 17, 2011 at 5:17 PM, Yoav Nir wrote:
> On Nov 18, 2011, at 2:06 AM, Nico Williams wrote:
>> Oh, this is good news. It means you're both close to having RFC5660
>> implemented :)
>
> Yeah, except without those pesky APIs. :-)
Sure, but adding those is relatively easy at that point. Y
On Nov 18, 2011, at 2:06 AM, Nico Williams wrote:
> On Wed, Nov 16, 2011 at 8:17 PM, Yoav Nir wrote:
>> On Nov 17, 2011, at 9:31 AM, Paul Wouters wrote:
But seriously, IPsec tunnels are based on RFC 4301 and there SPDs and PADs
are static, so there is only one peer where a particular
On Wed, Nov 16, 2011 at 8:17 PM, Yoav Nir wrote:
> On Nov 17, 2011, at 9:31 AM, Paul Wouters wrote:
>>> But seriously, IPsec tunnels are based on RFC 4301 and there SPDs and PADs
>>> are static, so there is only one peer where a particular source IP might
>>> come from.
>>
>> Openswan supports M
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
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 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
> "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 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
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
teve
>
>> -Original Message-
>> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
>> Of Frederic Detienne
>> Sent: Wednesday, November 16, 2011 4:24 AM
>> To: Yoav Nir
>> Cc: ipsec@ietf.org WG; Tero Kivinen; Mike Sullenberger
&g
> Sent: Wednesday, November 16, 2011 4:24 AM
> To: Yoav Nir
> Cc: ipsec@ietf.org WG; Tero Kivinen; Mike Sullenberger
> Subject: Re: [IPsec] P2P VPN - Side Meeting
>
>
> You are mixing everything up. It is too much work to correct you over
> email. I will try to help you at
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
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
On Nov 16, 2011, at 3:38 PM, Tero Kivinen wrote:
> Frederic Detienne writes:
>>> Frederic Detienne writes:
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 st
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
established trust infrastructure (single domain or multi-domain), customers
want to get full mesh IPsec connectivity for efficiency. Howev
On Nov 16, 2011, at 3:31 PM, Tero Kivinen wrote:
> Frederic Detienne writes:
>> Again, I urge you to be specific because there is nothing tangible
>> in your claims. I understand what you mean but if you rationalized
>> it, you would see your intuition fools you.
>
> When one does not know what
Frederic Detienne writes:
> > Frederic Detienne writes:
> >> 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.
> >
> > I d
OK.
Routing protocols are not security protocols. That's fine. Neither is HTTP.
BGPSEC and SIDR implement a layer of security on top of BGP to overcome this
issue, and that may be used in the Internet.
OSPF and NHRP are designed to be used in closed environments (corporate
networks), where eve
Frederic Detienne writes:
> Again, I urge you to be specific because there is nothing tangible
> in your claims. I understand what you mean but if you rationalized
> it, you would see your intuition fools you.
When one does not know what problem we are really solving and what
security and other r
Security is a matter of architecture and end-to-end design. Several mechanisms
are used to achieve an efficient balance with complexity. Features and security
protocols are only building blocks.
IPsec and IKE are not the only features that protect a network and routing as a
security policy rea
On Nov 16, 2011, at 1:45 PM, Tero Kivinen wrote:
> Yoav Nir writes:
>>> So you still didn't explain what GRE does better than modern IPsec
>>> tunneling?
>>
>> I think GRE (or any tunnel that is not IPsec - like L2TP) allows
>> them to avoid having to deal with RFC 4301 stuff like SPD. The only
On 16 Nov 2011, at 13:48, Tero Kivinen wrote:
> Frederic Detienne writes:
>> 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.
Frederic Detienne writes:
> 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.
I do not understand what you are trying to say there.
Yoav Nir writes:
> > So you still didn't explain what GRE does better than modern IPsec
> > tunneling?
>
> I think GRE (or any tunnel that is not IPsec - like L2TP) allows
> them to avoid having to deal with RFC 4301 stuff like SPD. The only
> selector they need is for the GRE tunnel (protocol 43?
Mike Sullenberger writes:
> I conceed the 1 IPsec SA issue, but with IPsec you still have to enumerate
> all of the subnets within that SA and renegotiate when subnets are added
> or removed. With GRE tunneling IPsec only ever sees the GRE tunnel packet
I most likely would need to read the draft
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 hundreds of subnets behind a branch here.
On 16 Nov
On Nov 16, 2011, at 9:32 AM, Tero Kivinen wrote:
>> What you call other fancy features is what I call functional separation.
>> IPsec does encryption well, but in reality it does a fairly poor job of
>> tunneling. So lets have IPsec do what it does well and have GRE do what
>> it does well and th
>Mike Sullenberger writes:
>> We use other tunnel mechanisms (GRE), because IPsec tunneling mode
>> is lacking in functionality. For example, when you use GRE for the
>> tunneling you also reduce the IPsec SA's that are needed to "describe"
>> the traffic for IPsec to encrypt. If you use IPsec tun
On Nov 15, 2011, at 7:08 PM, Yoav Nir wrote:
Hi Yoav,
...
>> We use other tunnel mechanisms (GRE), because IPsec tunneling mode
>> is lacking in functionality. For example, when you use GRE for the
>> tunneling you also reduce the IPsec SA's that are needed to "describe"
>> the traffic for IPse
Mike Sullenberger writes:
> We use other tunnel mechanisms (GRE), because IPsec tunneling mode
> is lacking in functionality. For example, when you use GRE for the
> tunneling you also reduce the IPsec SA's that are needed to "describe"
> the traffic for IPsec to encrypt. If you use IPsec tunnel m
On 15 Nov 2011, at 23:03, Michael Richardson wrote:
[...]
> So, you trade IPsec SAs ("security ACLs") for extended access-lists and
> routing tables. I don't see a difference if both are automatically
> updated by a policy engine.
>
> I can see that this might matter for devices with fixed purp
>
>> "Mike" == Mike Sullenberger writes:
>Mike> We use other tunnel mechanisms (GRE), because IPsec tunneling mode
>Mike> is lacking in functionality. For example, when you use GRE for the
>Mike> tunneling you also reduce the IPsec SA's that are needed to
>Mike> "describe"
>
> "Mike" == Mike Sullenberger writes:
Mike> We use other tunnel mechanisms (GRE), because IPsec tunneling mode
Mike> is lacking in functionality. For example, when you use GRE for the
Mike> tunneling you also reduce the IPsec SA's that are needed to
Mike> "describe"
Mike>
the
> security requirements...
>
> Chris
>
> [This message has been sent by a mobile device]
>
> - Original Message -
> From: Yoav Nir [mailto:y...@checkpoint.com]
> Sent: Tuesday, November 15, 2011 11:08 AM
> To: Mike Sullenberger
> Cc: ipsec@ietf.org ; f...@
On Nov 15, 2011, at 7:36 PM, Ulliott, Chris wrote:
> Classification:UNCLASSIFIED
>
> The problem with a single SA is that it usually means a single key (what ever
> form that takes) such that a compromise of a single spoke puts all traffic at
> risk... So what ever solution we go for - we need
[This message has been sent by a mobile device]
- Original Message -
From: Yoav Nir [mailto:y...@checkpoint.com]
Sent: Tuesday, November 15, 2011 11:08 AM
To: Mike Sullenberger
Cc: ipsec@ietf.org ; f...@cisco.com
Subject: Re: [IPsec] P2P VPN - Side Meeting
Hi Mike
On Nov 15, 2011, at 6:25
Hi Mike
On Nov 15, 2011, at 6:25 PM, Mike Sullenberger wrote:
> Hi Yoav,
>
>Please see inline.
>
> Mike.
>
>> On Nov 15, 2011, at 12:12 PM, Frederic Detienne wrote:
>>
>>>
>>> On 15 Nov 2011, at 12:05, Yoav Nir wrote:
>>>
Hi Frederic
Inline...
On Nov 15, 2011,
Hi Yoav,
Please see inline.
Mike.
>On Nov 15, 2011, at 12:12 PM, Frederic Detienne wrote:
>
>>
>> On 15 Nov 2011, at 12:05, Yoav Nir wrote:
>>
>>> Hi Frederic
>>>
>>> Inline...
>>>
>>> On Nov 15, 2011, at 11:42 AM, Frederic Detienne wrote:
>>>
Hi Yoav,
We will be there (follow
On Nov 15, 2011, at 12:12 PM, Frederic Detienne wrote:
>
> On 15 Nov 2011, at 12:05, Yoav Nir wrote:
>
>> Hi Frederic
>>
>> Inline...
>>
>> On Nov 15, 2011, at 11:42 AM, Frederic Detienne wrote:
>>
>>> Hi Yoav,
>>>
>>> We will be there (following offline with you for the details).
>>>
>>>
On 15 Nov 2011, at 12:05, Yoav Nir wrote:
> Hi Frederic
>
> Inline...
>
> On Nov 15, 2011, at 11:42 AM, Frederic Detienne wrote:
>
>> Hi Yoav,
>>
>> We will be there (following offline with you for the details).
>>
>> I do not think there is a need to spend 20 minutes on the draft which
>>
Hi Frederic
Inline...
On Nov 15, 2011, at 11:42 AM, Frederic Detienne wrote:
> Hi Yoav,
>
> We will be there (following offline with you for the details).
>
> I do not think there is a need to spend 20 minutes on the draft which
> everyone should have read. There are three vague points in it
Hi Yoav,
We will be there (following offline with you for the details).
I do not think there is a need to spend 20 minutes on the draft which everyone
should have read. There are three vague points in it and 10 min seem largely
sufficient.
At this stage several vendors think they have a fair u
Hi all
This is to announce a side meeting about peer to peer VPN, as described in our
recently published draft: http://tools.ietf.org/html/draft-nir-ipsecme-p2p-00
In the meeting we will discuss the use case of directly connecting two IKE
implementations that already have a path of trust betwee
43 matches
Mail list logo
