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).
I do not think there is a
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 (following offline with you for the
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, at 11:42 AM, Frederic Detienne 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 to keep one eye on the
security requirements...
Chris
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 to
On Nov 15, 2011, at 10:52 PM, Michael Richardson wrote:
Mark == Mark Boltz mark.bo...@stonesoft.com 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
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
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
Mike == Mike Sullenberger m...@cisco.com 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 purpose
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 to
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?) or
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.
I do
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
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
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
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 problem
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 still a lot of
21 matches
Mail list logo
