Bhatia, Manav (Manav) writes:
> > You gave reasons why ESP-NULL is needed, not why ESP-NULL visibility
> > is needed.
>
> One might want to filter OSPFv3 packets coming from outside the domain.
It is much better to do that check on the OSPFv3 receiver end where
the packet is actually authenticat
> > > Yes, but I do not really think people are going to solve
> those using
> > > ESP-NULL. I think they must move to encrypted ESP to provide
> > > confidentiality also, and that makes the need for
> ESP-NULL visibility
> > > even less.
> >
> > I disagree. With AH as a MAY and ESP as MUST in I
Bhatia, Manav (Manav) writes:
> >
> > > BTW, insider threats are on the rise according to various public
> > > reports, so should not be discounted. This is one of the motivations
> > > of employing security, even within the Enterprise.
> >
> > Yes, but I do not really think people are going to s
>
> > BTW, insider threats are on the rise according to various public
> > reports, so should not be discounted. This is one of the motivations
> > of employing security, even within the Enterprise.
>
> Yes, but I do not really think people are going to solve those using
> ESP-NULL. I think they
Grewal, Ken writes:
> >Are QOS and auditing devices really stateless?
> >
> >I would expect QOS devices to have all kind of reservation systems and
> >so on and for those I would expect them to be keeping state?
>
> [Ken] QoS may be applied on the need of the underlying service. E.g.
> A static ru
Grewal, Ken writes:
> [Ken] In some cases, the certainty must be 100%, otherwise there is
> no control. E.g. A new exploit has just been published for certain
> types of traffic - published vulnerability where a virus/worm can
> exploit a 'buffer overrun/stack overflow' condition for a given
> piec
>> [Ken] This may be feasible for stateful devices, but does not work
>> for stateless devices (QOS/Statistics/auditing functions). Even in
>> stateful devices, it requires coupling between observation on flows
>> and the associated heuristics cache engine, which creates an
>> additional overhead.
>At 2:33 PM -0700 2/10/09, Grewal, Ken wrote:
>>Stateless firewalls are commonly employed for efficiency and as a crude
>method for cutting off access to certain services - these are useful for
>basic access control in cost effective, high bandwidth, network scenarios.
>E.g. Corporations may not wa
At 2:33 PM -0700 2/10/09, Grewal, Ken wrote:
>Stateless firewalls are commonly employed for efficiency and as a crude method
>for cutting off access to certain services - these are useful for basic access
>control in cost effective, high bandwidth, network scenarios. E.g.
>Corporations may not w
>-Original Message-
>From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
>Yoav Nir
>Sent: Tuesday, February 10, 2009 11:52 AM
>To: gabriel montenegro; Tero Kivinen; Grewal, Ken
>Cc: ipsec@ietf.org; Dragan Grebovich
>Subject: Re: [IPsec] draft
gabriel montenegro wrote:
>I'll just comment on one item below:
>
>> As the draft says this is mostly meant for stateful devices, and that
>> has been the main goal for the document. The charter says:
>>
>> "A standards-track mechanism that allows an intermediary device, such
>> as a firewall or i
ing stateless).
The above was just an example.
Gabriel
- Original Message
> From: Tero Kivinen
> To: "Grewal, Ken"
> Cc: "ipsec@ietf.org" ; Dragan Grebovich
> Sent: Monday, February 9, 2009 6:19:54 AM
> Subject: Re: [IPsec] draft-kivinen-ipsecme-e
Grewal, Ken writes:
> [Ken] This may be feasible for stateful devices, but does not work
> for stateless devices (QOS/Statistics/auditing functions). Even in
> stateful devices, it requires coupling between observation on flows
> and the associated heuristics cache engine, which creates an
> additi
turday, February 07, 2009 1:53
> To: Paul Hoffman; Yaron Sheffer; Dragan Grebovich; Yoav Nir;
> ipsec@ietf.org
> Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments
>
> Thanks for the clarification. If I could ask for further clarification
> here: is there much su
Additional comment below...
...Snip...
>> Cache eviction - how will this work?
>> We can keep adding SAs (based on heuristics), but how do we decide
>> when a given SA is no longer needed? This compounds the issues with
>> keeping state, as in the best case, cache eviction will likely be
>> poli
Dragan Grebovich writes:
> I looked for some traffic stats in a real, large enterprise network and
> I found that UDP comprises 25-30% vs. TCP 70-75% of all traffic. The
> stats were measured on multiple places in the network, and multiple
> samples were taken over the past 6 weeks. Also, there i
I looked for some traffic stats in a real, large enterprise network and
I found that UDP comprises 25-30% vs. TCP 70-75% of all traffic. The
stats were measured on multiple places in the network, and multiple
samples were taken over the past 6 weeks. Also, there is a slow but
consistent growth of
Grebovich; ipsec@ietf.org
Subject: RE: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments
Hi Ken, Yoav,
I agree with Ken that the policy needs not be black and white, but for a
different reason. Some people will treat deep packet inspection by middleboxes
as an optional service: you want i
At 9:52 AM +0200 2/5/09, Yaron Sheffer wrote:
>Hi Gabriel,
>
>This thread is precisely the discussion that Paul mentions.
>
>The two alternatives I see on the table right now (Paul might have different
>opinions) are:
>
>- Publish a modified/wrapped ESP as Standards Track, and heuristi
Grewal, Ken writes:
> The 'bait and switch' attack where a connection uses ESP-NULL and
> then at a later stage uses ESP-Encrypted may also be possible
> unintentionally. E.g. Connection to a server (cluster / farm) to
> gain access to a 'normal' service uses ESP-NULL and then at a later
> stage, w
Grewal, Ken writes:
> Cache eviction - how will this work?
> We can keep adding SAs (based on heuristics), but how do we decide
> when a given SA is no longer needed? This compounds the issues with
> keeping state, as in the best case, cache eviction will likely be
> policy based. How is the policy
ipsec@ietf.org
Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments
Quote ...
"Our use case is an edge device that inspects all traffic, and drops things it
doesn't understand, such as non-NULL ESP and possibly SSL (they might make an
exception for HTTPS, but do a MiTM at
le in all cases.
From: Dragan Grebovich
To: Yoav Nir ; ipsec@ietf.org
Sent: Wednesday, February 4, 2009 11:24:20 AM
Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments
Hi Yoav
As per #4, I did not elaborate what the policy should be, because it is
network-specific, howe
le in all cases.
From: Dragan Grebovich
To: Yoav Nir ; ipsec@ietf.org
Sent: Wednesday, February 4, 2009 11:24:20 AM
Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments
draft-kivinen-ipsecme-esp-null-heuristics comments
Hi Yoav
As per #4, I did not elaborate what the po
AM
To: Grebovich, Dragan (BL60:SF00); ipsec@ietf.org
Subject: RE: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments
Dragan Grebovich wrote:
Yoav
I apologize for not being clearer earlier. I was not suggesting
any new/different policy enforc
av
Nir
Sent: Wednesday, February 04, 2009 12:04 AM
To: Dragan Grebovich; ipsec@ietf.org
Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments
Dragan Grebovich wrote:
Yoav
I apologize for not being clearer earlier. I was not suggesting any
new/different policy enforcement.
Some comments inline...
Thanks,
Ken
>-Original Message-
>From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
>Tero Kivinen
>Sent: Tuesday, February 03, 2009 5:12 AM
>To: Dragan Grebovich
>Cc: ipsec@ietf.org
>Subject: [IPsec] draft-kiv
Dragan Grebovich wrote:
Yoav
I apologize for not being clearer earlier. I was not suggesting any
new/different policy enforcement.
I believe/agree that traffic visibility will matter only to a subset of
traffic, but that is enforced at each appliance level, or on a more granular
(per interfac
g] On Behalf
Of Yoav Nir
Sent: Tuesday, February 03, 2009 5:16 AM
To: Grebovich, Dragan (BL60:SF00); ipsec@ietf.org
Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments
Dragan Grebovich wrote:
Hi Tero
I reviewed your heuristics draft and I believe it is in
Dragan Grebovich writes:
> Hi Tero
> I reviewed your heuristics draft and I believe it is interesting and
> doable, however:
>
> 1) I believe the actual implementation would require more code than
> current front-end hardware allows. The hardware we work with have a
> limited space for that much
Dragan Grebovich wrote:
Hi Tero
I reviewed your heuristics draft and I believe it is interesting and doable,
however:
1) I believe the actual implementation would require more code than current
front-end hardware allows. The hardware we work with have a limited space for
that much heuristics
Hi Tero
I reviewed your heuristics draft and I believe it is interesting and
doable, however:
1) I believe the actual implementation would require more code than
current front-end hardware allows. The hardware we work with have a
limited space for that much heuristics code. Our preference is to
32 matches
Mail list logo
