Hi Tero,
[clipped]
> And why would routing protocols need to use WESP, I would assume
> they use ESP-NULL instead. In addition if you use manual keying
Sigh. We've gone through this before I think on the KARP mailing list (am not
sure though).
Routing protocols could "potentially" use WESP s
05, 2012 9:18 PM
To: Bhatia, Manav (Manav)
Cc: Tero Kivinen; IPsec ME WG List
Subject: Re: [IPsec] Avoiding Authentication Header (AH)
On Jan 5, 2012, at 4:37 PM, Bhatia, Manav (Manav) wrote:
>
>> Getting WESP implemented to the boxes will require a lot of time.
>> There are stil
> Getting WESP implemented to the boxes will require a lot of time.
> There are still lots of boxes which do not even support IKEv2 (which is
> required for
> WESP) and IKEv2 has been out for 6 years already. AH might already be
WESP can be used with manual keying the way routing protocols tod
ee with Yaron that there is value in some document that recommends not
using AH when ESP-NULL can be employed, and also that points out where AH does
make sense.
Cheers, Manav
-Original Message-
From: Sean Turner [mailto:turn...@ieca.com]
Sent: Thursday, January 05, 2012 9:01 AM
To:
Ran,
> Such packets have been encountered by prototype implementations in at least
> one firewall.
> I will certainly encourage those folks to share a sample packet here, but
> they don't
> usually show up at IETF and can be very shy.
>
> I think WESP was a valiant try, and it seems to work
ESP-NULL and not even bother with AH if they can do with just ESP.
Cheers, Manav
-Original Message-
From: m...@sandelman.ca [mailto:m...@sandelman.ca]
Sent: Wednesday, January 04, 2012 7:46 PM
To: Bhatia, Manav (Manav)
Cc: Nico Williams; ipsec@ietf.org
Subject: Re: [IPsec] Avo
> There is no evidence of any recent change either to the operational
> circumstances or to the available alternatives. So no update is appropriate
> at this time.
One major recent change is the publication of WESP [RFC 5840] and the standard
for using Heuristics for detecting ESP-NULL pack
NIST has published the "Guidelines for secure deployment of IPv6" and it
unequivocally says that AH has fallen out for ESP-NULL.
One can go through the document in detail. I have not gone through the entire
document but here are some excerpts from that document:
(1) It says the following for OS
Hi Nico,
> Advising (and updating said advice as circumstances change)
> use-IPsec protocol designers as to when to use ESP and/or AH
> is something we should do. Deprecating AH seems like a nice
> idea, but if there's good reasons to still use it, then maybe not.
We're not talking about dep
And most of these are considered dangerous and are generally discouraged.
http://tools.ietf.org/html/rfc6398
Cheers, Manav
-Original Message-
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of RJ
Atkinson
Sent: Tuesday, January 03, 2012 6:18 AM
To: IPsec ME WG Li
Ran,
> You might also be interested in the following draft which will be published
> as RFC any time now:
> http://tools.ietf.org/html/draft-ietf-ospf-auth-trailer-ospfv3-11
> I am well aware of it. That document does NOT deprecate use of AH with
> OSPFv3 either.
It doesn't need to because n
Hi Nico,
http://tools.ietf.org/html/draft-bhatia-ipsecme-avoiding-ah-00 is NOT trying to
move AH to Historic.
Its merely trying to discourage newer applications and protocols from mandating
AH as the same level of security can be achieved with ESP-NULL. The draft also
says:
It however, doe
[clipped]
> Most major IPv6 routers, for example multiple product lines from both Cisco
> and Juniper, also support AH in shipping product and have done for some while
> now.
> So AH remains a very widely available protocol.
It may be widely available, but clearly it isnt as widely used.
Are
Hi Michael,
> I do not agree that WESP provides the service desired.
> WESP requires cooperation (and therefore upgrade) of the end points.
>
> What AH does that ESP NULL does not, is that it guarantees that the things
> after the AH header are in fact in the clear. One can in fact, ignore the
0:03 PM
To: Bhatia, Manav (Manav)
Cc: ; IPsecme WG
Subject: Re: [IPsec] Moving Authentication Header (AH) to Historic
On Jan 1, 2012, at 8:17 AM, Bhatia, Manav (Manav) wrote:
> To get around this process problem do you suggest that I publish a new draft
> - "Avoiding Authentication Heade
Hi Paul,
To get around this process problem do you suggest that I publish a new draft -
"Avoiding Authentication Header (AH)" that's mostly a copy-paste of my current
draft?
Cheers, Manav
-Original Message-
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Paul
Hi David and Yaron,
I think its possible to edit the draft headers and the text so that we
basically say that AH should NOT be used for newer proposals unless there is a
burning reason to do so. And if someone wants to use AH, then they should have
a pretty good reason for doing that. In my dra
Hi,
We have had several discussions in the past about the utility of AH when ESP
with NULL encryption offers everything that AH has to offer. I have written a
very small draft that recommends moving AH to the Historic status. This
document does NOT deprecate AH and it does NOT mean that people
Hi,
I had spoken to one of the initial authors of this IPsec draft and I was told
that setting up an Ipsec tunnel exclusively for shipping 1588 may not be
possible in the femto architecture. They are thus trying to use WESP (that I
have co-authored) to identify 1588 packets within an IPSec stre
av
>
> The more I think of this problem the more worthless WESP becomes.
>
> Dan.
>
> On Mon, January 11, 2010 1:02 am, Bhatia, Manav (Manav) wrote:
> > I believe Ken is alluding to removing the WESP header from the ICV
> > calculation, and relying on e
I believe Ken is alluding to removing the WESP header from the ICV calculation,
and relying on explicitly checking the WESP header at the endnodes.
Cheers, Manav
> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org]
> On Behalf Of pasi.ero...@nokia.com
> Se
> >
> > In an ideal world maybe. Sometimes the netwwork needs to
> mark traffic
> > at the edge switch but doesn't 'trust' the endpoint to do it. So
> > typically it would be done with policy rules.
>
> We're talking about making changes to the end nodes anyways,
> so why not
> make them handle
2 AM
> To: Bhatia, Manav (Manav)
> Cc: Dan Harkins; Jack Kohn; ipsec@ietf.org
> Subject: Re: [IPsec] Traffic Visibility Future
>
>
> I would be very much interested in a real-world example instead
> of hypotheticals. What service provider is asking for WESP?
>
> Dan.
Dan,
[clipped]
> Because it's unnecessary bloat that another group may not have any
> use for. ESP-null could be used, for instance, to protect
> packets in an
> EGP routing protocol. There is no need for WESP in such an
> environment.
EGP routing protocols, by definition and design, will t
Hi Russ,
> My point is that the end system does not need the information in the
> WESP header to properly handle the packet for the supported
> application. The additional information is being exposed to allow
> middle boxes to make various checks. The end system can
> ensure that the
> ex
Hi Russ,
> > - A standards-track mechanism that allows an intermediary
> device, such
> > as a firewall or intrusion detection system, to easily and reliably
> > determine whether an ESP packet is encrypted with the NULL
> cipher; and
> > if it is, determine the location of the actual paylo
Yes, this was discussed in the WG
(http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/104) and the idea was this:
We could have some malicious entity that could modify the offsets to ensure
that the intermediaries don't parse a portion of the payload (which could
contain malicious content) or in
+1
> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org]
> On Behalf Of Brian Swander
> Sent: Tuesday, December 22, 2009 4.43 AM
> To: Yaron Sheffer; Tero Kivinen; Jack Kohn
> Cc: ipsec@ietf.org; Russ Housley
> Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecm
Tero,
> The reason I am in favor of heuristics instead of WESP, is that
> heuristics requires changes only on the middleboxes, we do not need to
> make new extension that will affect all the end nodes supporting
> IPsec.
>
> Also heuristics is not harmful, as it does not harm others, it is
> simp
[mail snipped]
> - If this proposal is accepted as a WG work item,
> are you committing to review multiple versions of the draft?
Yes
> - Are you willing to contribute text to the draft?
Yes
> - Would you like to co-author it?
Yes
I believe the OAM extension described in the draft is useful and
Hi Yaron,
I am fine with these changes and i think we must have them to keep WESP
extensible!
Thanks, Manav
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Yaron
Sheffer
Sent: Wednesday, November 18, 2009 1.00 PM
To: IPsecme WG
Subject
This is an implementation specific optimization that has already been solved in
multiple implementations.
Cheers, Manav
> -Original Message-
> From: Tero Kivinen [mailto:kivi...@iki.fi]
> Sent: Monday, November 16, 2009 6.39 PM
> To: Bhatia, Manav (Manav)
> Cc: ipsec@iet
>
> It will take several years before implementations start to implement
> WESP, and even more years before hardware chips support WESP. Most of
> the IPsec users are still using IKEv1, even when we published IKEv2
> 2005, i.e. 4 years ago. And IKEv2 draft was finished and publication
> was requ
t the
SAD lookup fail?
Cheers, Manav
> -Original Message-
> From: Richard Graveman [mailto:rfgrave...@gmail.com]
> Sent: Friday, November 13, 2009 7.07 AM
> To: Bhatia, Manav (Manav)
> Cc: Daniel Migault; ipsec@ietf.org; Stephen Kent; Kaeo;
> mer...@core3.amsl.com
> >
> >So what fields does AH protect:
> >
> >Version, Payload length, Next Header, Source IP and dest IP
>
> you forgot IPv4 and IPv6 options that have predictable values at the
> destination
Lets start with the IPv6 Type 0 Route Header (aka "Source Routing" in v4
parlance), which is a mutabl
M
To: Jack Kohn
Cc: Stephen Kent; ipsec@ietf.org; Bhatia, Manav (Manav); Merike Kaeo
Subject: Re: [IPsec] WESP - Roadmap Ahead
On Thu, Nov 12, 2009 at 5:30 AM, Jack Kohn wrote:
>
> Whoops, I was wrong. I looked at 4552 an
e flip side, in practical implementations, most vendors I
> know of started off with AH being used for OSPFv3 and I doubt in
> practice people are using ESP-Null. Would love to be wrong here :)
>
> - merike
>
> On Nov 11, 2009, at 7:28 PM, Stephen Kent wrote:
>
> >
this is really true. I know of at least two major vendors that
use ESP-NULL and one of them doesn't even support AH.
Cheers, Manav
>
> - merike
>
> On Nov 11, 2009, at 7:28 PM, Stephen Kent wrote:
>
> > At 7:44 AM +0530 11/12/09, Bhatia, Manav (Manav) wrote:
> >>
Steve,
> I would have no problem deprecating AH in the context of the IPsec
> architecture document, if others agree. It is less efficient than
> ESP-NULL. However, other WGs have cited AH as the IPsec protocol of
> choice for integrity/authentication in their environments, so there
> will be
Scott,
> From: ipsec-boun...@ietf.org On Behalf Of Scott C Moonen
> Sent: Thursday, November 12, 2009 2.37 AM
> To: Jack Kohn
> Cc: ipsec@ietf.org; ipsec-boun...@ietf.org
> Subject: Re: [IPsec] WESP - Roadmap Ahead
>
> Jack, I'm not sure it's clear yet whether WESP will be widely adopted.
Works for me too!
Cheers, Manav
> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org]
> On Behalf Of Grewal, Ken
> Sent: Tuesday, August 18, 2009 10.03 PM
> To: Yaron Sheffer; ipsec@ietf.org
> Subject: Re: [IPsec] Relating the two ESP-null documents
>
> Wo
then simply deriving
the state from the Next Header field.
Cheers, Manav
From: Yaron Sheffer [mailto:yar...@checkpoint.com]
Sent: Thursday, July 16, 2009 2.21 PM
To: Bhatia, Manav (Manav); Grewal, Ken; QIU Ying; ipsec@ietf.org
Subject: RE: [IPsec] WG Last Call:
2009 1.01 PM
To: QIU Ying; Bhatia, Manav (Manav); Grewal, Ken; Yaron Sheffer; ipsec@ietf.org
Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-traffic-visibility-05
Oh, maybe I misunderstood Manav's thought.
Perhaps Manav's meaning is that WESP carries an ESP-null packet which trailer
We can use ESP as the next header to denote encryption being used as long as we
are sure that we will never have an ESP packet inside the WESP encapsulation.
In my view there is nothing that precludes that from happening, which means
that we may have some corner cases where WESP may actually be
> > There are a lot of boxes deployed in the field that cant do what you
> > seem to be suggesting.
>
> Those deployed boxes will need updates anyways, as they do not support
> WESP either...
I had meant that there are boxes currently deployed in the field which would
have HW capable of only
et.
Is there an issue in keeping "Next Header" in the WESP header? I see an
advantage in doing so. Would like to hear arguments against it!
Cheers, Manav
> -Original Message-
> From: Tero Kivinen [mailto:kivi...@iki.fi]
> Sent: Tuesday, May 12, 2009 2.31 PM
> To
Hi,
I'd personally like to see the "Next Header" field retained in the WESP header.
It becomes extremely easy for the ASICs (even off the shelf ones like Broadcom,
Wintegra, etc) to look at a fixed offset in the packet for a particular byte
pattern and decide on what it needs to do with that pa
> > > 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
>
> > 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
49 matches
Mail list logo
