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).
>>>
>>>
At 1:56 AM -0500 11/15/11, Steven Bellovin wrote:
On Nov 13, 2011, at 4:30 PM, Vilhelm Jutvik wrote:
> De...
The notion of discarding AH entirely has been discussed for many years.
I've long been in favor of it, though I can't find a copy of anything old I
had posted in my mail archives at the
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
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,
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 to keep one eye on the
security requirements...
Chris
[This
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
What you are referring to is when a single SA/key is shared across multiple
devices (or the entire network). Here, we are talking about a unique SA pair
between any two devices. I.e. each device pair on the network has its own IPsec
SA.
fred
On 15 Nov 2011, at 19:36, Ulliott, Chris wr
> "Mark" == Mark Boltz writes:
Mark> With all due respect to Cisco, the larger problem we're trying
Mark> to address, is in part the fact that DMVPN and ACVPN are
Mark> vendor specific implementations. And the goal of the
Mark> implementation we're seeking is *large scale* P2P
> "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>
On Nov 15, 2011, at 10:52 PM, Michael Richardson wrote:
>
>> "Mark" == Mark Boltz writes:
>Mark> With all due respect to Cisco, the larger problem we're trying
>Mark> to address, is in part the fact that DMVPN and ACVPN are
>Mark> vendor specific implementations. And the goal of
Couple of clarification here. Juniper implementation of AC-VPN does not do
GRE over IPSec. It is IPSec alone for implementation (Route based VPN).
Yes, AC-VPN uses NHRP to do resolution just like DM-VPN. But in AC-VPN
there are proprietary messages. It uses standard messages, but has many
proprieta
On 16 Nov 2011, at 01:57, Praveen Sathyanarayan wrote:
> Couple of clarification here. Juniper implementation of AC-VPN does not do
> GRE over IPSec. It is IPSec alone for implementation (Route based VPN).
> Yes, AC-VPN uses NHRP to do resolution just like DM-VPN. But in AC-VPN
> there are propri
>
>> "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"
>
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
On Tue, 15 Nov 2011, Praveen Sathyanarayan wrote:
Couple of clarification here. Juniper implementation of AC-VPN does not do
GRE over IPSec. It is IPSec alone for implementation (Route based VPN).
Yes, AC-VPN uses NHRP to do resolution just like DM-VPN. But in AC-VPN
there are proprietary messag
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 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 tun
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
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
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
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?
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.
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.
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
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
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
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:
> > 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
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
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: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
32 matches
Mail list logo
