Re: [IPsec] WESP - Roadmap Ahead

[Stephen Kent]

Jack,

Thanks for describing the additional selection criteria that must be 
employed to avoid the problem I cited.


Given this more complete description of the selection criteria, I am 
not convinced that that is a significant benefit for using WESP in 
this context.


	- Whether using WESP or just ESP-NULL, the router needs to 
determine that the packet is addressed to it.  This means looking for 
either a unicast address (per interface?) or a multicast address. I 
thought that the traffic of interest would arrive on a multicast 
address. If so, then this is a very easy check.


	- Traffic other than OSPF can be addressed to the router, but 
I'm not sure what other traffic would be multicast. For unicast 
traffic addressed to the router, if some of that is protected using 
ESP with confidentiality, then the address check might have to be 
extended to include a source address as well.


	- There is an assumption that the OPSFv3 traffic is 
(ultimately)  protected using ESP-NULL. The next check that you 
described, i.e., looking for a few bits that indicate whether the 
payload is OSPF and appears to be a HELLO or ACK, is the real focus 
of this thread.  There appears to be a couple of cases:


	- If all multicast traffic directed to the router and 
protected using ESP is ESP-NULL, then WESP seems to help ONLY if 
there are algorithms being used for different SAs, AND if those 
algorithms result in different offsets for the start of the ESP-NULL 
payload. It's not clear that this is a realistic case. But, in this 
case, using WESP could avoid the need to check the SPI in the packet. 
What's not clear is whether checking for WESP and extracting the 
offset info is faster than matching against a set of SPIs.


	- if some multicast traffic directed to the router is 
protected with ESP with confidentiality, in addition to the ESP-NULL 
OSPF traffic, then one would need to check SPI values to 
differentiate between these two classes of traffic.


So, the question of whether we have one multicast SA for this 
traffic, or potentially a lot of these SAs is potentially relevant. 
As I mentioned in my previous message, this is not completely clear 
to me from 4552. You didn't respond to that part of my message, so I 
don't know if that means you find the RFC unclear on this point as 
well, or if you didn't think it mattered to this discussion. Well, if 
appears to matter, if one believes that the number is substantial.


So, the bottom line appears to be that WESP might be better than just 
using ESP-NULL, depending on the number of multicast SAs that 
terminate at the router, that make use of ESP, and maybe whether the 
ones that use ESP make use of different integrity algorithms that 
result in different offsets.  That is a lot of IFs for which we have 
yet to get an answer.


In any case, as I noted earlier, because of the use of manual keying 
in this context, selecting a subset of packets for out-of-order 
processing does not impose any burden on the IPsec for the remaining 
packets, so all of the comments about that issue were red herrings.


Steve
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WESP - Roadmap Ahead

[Jack Kohn]

>
>> Now, assume that we were using WESP.
>>
>> You would need just two rules in your filter database saying the
>> following:
>>
>> Incoming Pkt is WESP integrity Protected, then look at the nth bit and
>> if its a OSPF HELLO, put it in Ospfv3HighPrioQueue.
>> Incoming Pkt is WESP integrity Protected, then look at the mth bit and
>> if its a OSPF ACK, put it in Ospfv3HighPrioQueue.
>
> This is much simpler, but also potentially inaccurate. Specifically, because
> it pays no attention to the SAD info, it would grab ANY packet that passes
> through the router, uses WESP, and that matches the bits that one uses to
> decide of a packet is an OSPF HELLO or ACK.

Obviously the following rules would only be applied if the IP packet
was addressed to the router that was doing these checks. This way it
will not trap the other packets passing through this router.

>
>> Thus one now needs only 2 rules in the HW to prioritize packets for
>> *all* OSPF adjacencies.
>
> Unless you used some other rules to narrow down the set of packets subject
> to these quick checks, other packets may be grabbed.

Same as above. It is trivial to find out if the packet is locally
bound, or needs to be routed.

Jack
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WESP - Roadmap Ahead

[Stephen Kent]

At 12:11 PM +0100 11/25/09, Daniel Migault wrote:

Hi Manav,

I agree that for an already negotiated SA, the SPD lookup detects IP 
source address spoofing. So in that case ESP detects the address 
spoofing during the SPD check whereas AH would detect it while 
checking the signature check.


However SAD lookup is done with the longest match rule, and section 
4.1 of RFC4301 specifies :

  "3. Search the SAD for a match on only SPI if the receiver has
 chosen to maintain a single SPI space for AH and ESP, and on

 both SPI and protocol, otherwise."

This seems to enable a ESP or AH datagram with spoofed IP addresses 
to match the SAD and SPD.


I'm confused at this juncture.  The 4301 inbound processing algorithm 
(section 5.2 in RFC 4310) refers to SAD entries for processing 
IPsec-protected packets; the SPD inbound cache (SPD-I) is used only 
for bypass and discard traffic. So there should be no reference to 
the SPD in the sentence immediately above, right?


Also, you should remind folks that this rule applies only to 
multicast SAs. That's relevant to the OSPFv3 discussion we are 
having, but it seems inconsistent with the comment below of a 
middlebox that changes addresses, i.e., does one really expect to 
encounter a NAT on a link between two routers running OSPF?


I am not criticizing your later comments about AH vs. ESP 
applicability in mobile environments, just trying to keep the various 
arguments straight.


Steve
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WESP - Roadmap Ahead

[Stephen Kent]

At 9:05 AM +0530 11/25/09, Jack Kohn wrote:

 >
 >...

Assume we dont have WESP.

The end router having scores of OSPF adjacencies will have following
rules in its database for *each* adjacency:

Incoming Pkt carries SPI X, then look at the nth bit and if its a OSPF
HELLO, put it in Ospfv3HighPrioQueue.
Incoming Pkt carries SPI X, then look at the mth bit and if its a OSPF
ACK, put it in Ospfv3HighPrioQueue.

This is assuming that SPI X corresponds to ESP-NULL and one can
disambiguate OSPF Hellos/ACKs from other OSPF packets by looking at
the nth bit and the mth bit (Please note that n could also be equal to
m).


These packets are arriving on a multicast SA, so the preferred way to 
do the lookup, to make certain that the packet is from a relevant 
router is to perform
the lookup as described in section 4.1 (pages 12+13) of RFC 4301. 
That means that these SAs generally are uniquely identified based on 
both the SPI value and the source and/or destination addresses.  So, 
you would need to refine the matching algorithm described above based 
on the rules from 4301.


Now, if this router has N adjacencies then the # of rules required = 
2 x N = 2N


Thus the # of filter entries scales up linearly with the # of adjacencies.


I've always found the 4552 discussion of SA use a bit confusing, but 
my recollection is that it called for reusing SAs in a way to avoid 
this problem (see Figure 3, section 7, page 7). But I am not 
completely confident about this, based on the wording in that RFC.



Now, assume that we were using WESP.

You would need just two rules in your filter database saying the following:

Incoming Pkt is WESP integrity Protected, then look at the nth bit and
if its a OSPF HELLO, put it in Ospfv3HighPrioQueue.
Incoming Pkt is WESP integrity Protected, then look at the mth bit and
if its a OSPF ACK, put it in Ospfv3HighPrioQueue.


This is much simpler, but also potentially inaccurate. Specifically, 
because it pays no attention to the SAD info, it would grab ANY 
packet that passes through the router, uses WESP, and that matches 
the bits that one uses to decide of a packet is an OSPF HELLO or ACK.



Thus one now needs only 2 rules in the HW to prioritize packets for
*all* OSPF adjacencies.


Unless you used some other rules to narrow down the set of packets 
subject to these quick checks, other packets may be grabbed.


Steve
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WESP - Roadmap Ahead

[Tero Kivinen]

Daniel Migault writes:
> I agree that for an already negotiated SA, the SPD lookup detects IP source
> address spoofing.

Not quite true, as you point out yourself. 

> So in that case ESP detects the address spoofing during
> the SPD check whereas AH would detect it while checking the signature check.
> 
> However SAD lookup is done with the longest match rule, and section 4.1 of
> RFC4301 specifies :
> 
>   "3. Search the SAD for a match on only SPI if the receiver has
>  chosen to maintain a single SPI space for AH and ESP, and on
>  both SPI and protocol, otherwise."
> 
> 
> This seems to enable a ESP or AH datagram with spoofed IP addresses to match
> the SAD and SPD.

Yes, and this is very important to get NAT-T and MOBIKE to work as
there the source address might change (either because NAT box rebooted
or otherwise forgot the mapping, and gave new IP address for the IPsec
connection, or because host moved around using MOBIKE).

> If we consider a middleboxe that changes the IP address,
> then using ESP will not detect the IP address spoof. On the other hand using
> AH the spoofing attack will be detected.

Yes. 

> Thus I would not consider AH as ESP_NULL equivalent, and thus feel AH should
> not be removed. Nevertheless, AH has a major drawback which is NAT. For now
> we can only hope IPv6 will bring an end-to-end connectivity. At least AH
> would take considerable advantage of this statement!

To reiterate for others, the major drawback in AH is that it actually
detects changes in the source / destination IP addresses, thus it
breaks if there is evil attackers (called NATs) in the middle who try
to modify source and/or destination addresses...

> IMO, rather then removing AH I would see if future use of the Internet make
> it "historical" or not. For now it might be too soon to take such a
> decision. Furthermore, AH does not cause "problems" with other protocols,
> since they can chose not to use it.

I agree.
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WESP - Roadmap Ahead

[Tero Kivinen]

Jack Kohn writes:
> Assume we dont have WESP.

I would like to, but unfortunately I lost :-)

> The end router having scores of OSPF adjacencies will have following
> rules in its database for *each* adjacency:
> 
> Incoming Pkt carries SPI X, then look at the nth bit and if its a OSPF
> HELLO, put it in Ospfv3HighPrioQueue.
> Incoming Pkt carries SPI X, then look at the mth bit and if its a OSPF
> ACK, put it in Ospfv3HighPrioQueue.

As all of those IPsec connections is created by node, it actually
knows which algorithms are allowed, so it can very quickly do simple
run partial heuristics on the packet to know it is ESP-NULL.

Or actually it can also make so that if SPI number bit x is set then
the IPsec SA is using ESP-NULL for ospf, otherwise it is normal
encrypted traffic or something else. As SPI allocation is local
matter for this node, it can do this kind of things.

Middle boxes (where wesp and heuristics are really intended for)
cannot do this kind of things, but end-boxes can.

So for end boxes there is even more efficient methods than using WESP
to do the same thing. Splitting SPI range to indicate algorithms is
more efficient than WESP, as then you do waste extra bytes for extra
header. 

> Thus one now needs only 2 rules in the HW to prioritize packets for
> *all* OSPF adjacencies.
> 
> This becomes a huge advantage when we start scaling up the OSPF
> adjacencies. 

If you start using IPsec protected OSPF then you most likely will
require hardware support for IPsec also, and SPI lookup to find out
the algorithms etc is very fast first step done in there. After that
you know the parameters for the SA and you can then do this kind of
prioritizing before forwarding packet to the actual crypto engines. On
the other hand it might be better to just put few extra dollars for
the hardware and get fast enough crypto chips so you can do this
prioritizing using AUTHENTICATED data from the packet, i.e. after
IPsec processing as that will protect against attackers flooding the
Ospfv3HighPrioQueue by sending packets matching your bits.
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WESP - Roadmap Ahead

[Daniel Migault]

Hi Manav,

I agree that for an already negotiated SA, the SPD lookup detects IP source
address spoofing. So in that case ESP detects the address spoofing during
the SPD check whereas AH would detect it while checking the signature check.


However SAD lookup is done with the longest match rule, and section 4.1 of
RFC4301 specifies :

  "3. Search the SAD for a match on only SPI if the receiver has
 chosen to maintain a single SPI space for AH and ESP, and on
 both SPI and protocol, otherwise."


This seems to enable a ESP or AH datagram with spoofed IP addresses to match
the SAD and SPD. If we consider a middleboxe that changes the IP address,
then using ESP will not detect the IP address spoof. On the other hand using
AH the spoofing attack will be detected.

There are some cases you want to protect the IP address header with IP
addresses and options. The example I have in mind is when you are a mobile
or a multihomed node, you are changing you IP address and want to notify
your peer with a IPsec protected signalling message.
  - MIPv6 [RFC3776] uses ESP to protects the BU message. The information
to be carried is the new CoA. Since ESP does not protects the IP header, the
BU datagram carries the IP address in its Payload, thus carrying twice this
information. It seems that AH would avoid repeating information.
  - MOBIKE [RFC4555] MOBIKE does not protect the new IP value which is
taken from the IP header. In some cases this can lead to traffic redirecting
attacks. The main purpose of this attack seems to be DoS.

Thus I would not consider AH as ESP_NULL equivalent, and thus feel AH should
not be removed. Nevertheless, AH has a major drawback which is NAT. For now
we can only hope IPv6 will bring an end-to-end connectivity. At least AH
would take considerable advantage of this statement!

IMO, rather then removing AH I would see if future use of the Internet make
it "historical" or not. For now it might be too soon to take such a
decision. Furthermore, AH does not cause "problems" with other protocols,
since they can chose not to use it.

Regards,

Daniel

Regards,

Daniel

On Fri, Nov 13, 2009 at 2:18 AM, Bhatia, Manav (Manav) <
manav.bha...@alcatel-lucent.com> wrote:

> Daniel,
>
> > AH is a security feature we need to keep for header authentication
>
> Am really not sure about the value that AH adds even in case of header
> authentication.
>
> So what fields does AH protect:
>
> Version, Payload length, Next Header, Source IP and dest IP
>
> The only field worth modifying is the source and the dest IP. Now note that
> an IPSec SA is established between a pair of source IP and dest IP. Upon
> receipt of a packet containing an AH header, the receiver determines the
> appropriate (unidirectional) SA, based on the dest IP, security protocol
> (AH), and the SPI (it could also include the source IP). If the attacker
> modifies (or spoofs) either of the source or the dest IP, the SA lookup will
> fail and the receiver will regardless discard the packet. So what are we
> gaining by AH "header authentication"?
>
> AH can only add value over ESP-NULL if there are instances where despite
> address spoofing we erroneously process the IPSec packet. I don't see that
> happening, so is this really an issue?
>
> Cheers, Manav
> 
>
>From: Daniel Migault [mailto:mglt.i...@gmail.com]
>Sent: Thursday, November 12, 2009 11.14 AM
>    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 and they do cite
> ESP-NULL (although
>> they never refer to it that way) as a MUST, and AH as a
> MAY.
>
>Ok, so can we work on deprecating AH? This way new standards
> defined
>in other WGs dont have to provide support for AH.
>
>
>AH is a security feature we need to keep for header authentication.
> Other WG may chose not to deal with AH and only consider ESP. I don't see
> what's wrong with that?
>
> Regards
>
>Daniel
>--
>Daniel Migault
>Orange Labs -- Security
>+33 6 70 72 69 58
>
>
>


-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WESP - Roadmap Ahead

[Jack Kohn]

>
>- the principle example offered is OSPFv3 use of IPsec
>- OSPFv3 relies on both unicast and multicast SAs
>- in either case, a router receiving IPsec-protected OSPFv3 traffic
>  will have an SAD entry for the traffic, which means that the
>  router will know that the traffic will be protected via AH
>  or ESP. if ESP is employed, a router receiving traffic will know
>  ESP-NULL is used.
>- RFC 4552 mandates support for using different SAs for DSCP-marked
>  traffic
>- RFC 4552 calls for manual keying for both unicast and multicast
> SAs,
>  and states that a receiver is not checking sequence numbers.
>
> In a given OSPF context (e.g., an AS), all the routers are operated by the
> same administrative entity (based on the definition of an AS). If the AS in
> which OSPF is being employed chooses to use ESP-NULL, all the routers can be
> configured to require this, as part of local SPD management.
>
> Why do we need to use WESP in this context? The current argument you
> provided was that this was an issue for a router receiving OSPF traffic, not
> a middlebox issue. But the router knows that the traffic will be ESP-NULL,
> and knows the algorithm employed, so it should be able to examine this
> traffic easily. If the router wants to process traffic out-of-order, after
> examination, that too is easy, since there is no receiver sequence number
> checking, so processing the rest of the traffic (potentially with gaps) will
> not be a problem from an IPsec perspective.

Assume we dont have WESP.

The end router having scores of OSPF adjacencies will have following
rules in its database for *each* adjacency:

Incoming Pkt carries SPI X, then look at the nth bit and if its a OSPF
HELLO, put it in Ospfv3HighPrioQueue.
Incoming Pkt carries SPI X, then look at the mth bit and if its a OSPF
ACK, put it in Ospfv3HighPrioQueue.

This is assuming that SPI X corresponds to ESP-NULL and one can
disambiguate OSPF Hellos/ACKs from other OSPF packets by looking at
the nth bit and the mth bit (Please note that n could also be equal to
m).

Now, if this router has N adjacencies then the # of rules required =  2 x N = 2N

Thus the # of filter entries scales up linearly with the # of adjacencies.

Now, assume that we were using WESP.

You would need just two rules in your filter database saying the following:

Incoming Pkt is WESP integrity Protected, then look at the nth bit and
if its a OSPF HELLO, put it in Ospfv3HighPrioQueue.
Incoming Pkt is WESP integrity Protected, then look at the mth bit and
if its a OSPF ACK, put it in Ospfv3HighPrioQueue.

Thus one now needs only 2 rules in the HW to prioritize packets for
*all* OSPF adjacencies.

This becomes a huge advantage when we start scaling up the OSPF adjacencies.

Jack.
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WESP - Roadmap Ahead

[Stephen Kent]

...
 >- it fails to characterize the range of protocols for which you

 believe this argument applies,


http://www.ietf.org/mail-archive/web/ipsec/current/msg05070.html

This is one example, we could think of some more.


This is only one example, and I think it is not "mainstream", so more 
examples would be helpful.



 >
 >-it fails to explain how WESP is relevant, since a receiver has the

This has already been discussed in this email thread earlier.


Not a very specific reference :-(.


 > ability to process encrypted packets. WESP is a protocol that has been

 promoted as designed to aid middle boxes, not end systems


Border Gateway Protocol (BGP) (http://www.ietf.org/rfc/rfc4271.txt)
was originally designed to work as an Exterior Gateway Protocol (EGP).
Today besides working as an EGP it is used in myriad other
applications, from discovering nodes in a VPN to distributing advisory
messages to remote network operators. So, i dont see a reason why we
should restrict ourselves to the applications for which a protocol can
be used ..


I would NEVER use BGP as a good example of a protocol that has been 
extended to cover a broader range of contexts, if security is the 
focus of the discussion.



Let me try to recapitulate the context of our discussion, since I 
have had trouble following the thread:


- the principle example offered is OSPFv3 use of IPsec
- OSPFv3 relies on both unicast and multicast SAs
- in either case, a router receiving IPsec-protected OSPFv3 traffic
  will have an SAD entry for the traffic, which means that the
  router will know that the traffic will be protected via AH
  or ESP. if ESP is employed, a router receiving traffic will know
  ESP-NULL is used.
- RFC 4552 mandates support for using different SAs for DSCP-marked
  traffic
- RFC 4552 calls for manual keying for both unicast and multicast SAs,
  and states that a receiver is not checking sequence numbers.

In a given OSPF context (e.g., an AS), all the routers are operated 
by the same administrative entity (based on the definition of an AS). 
If the AS in which OSPF is being employed chooses to use ESP-NULL, 
all the routers can be configured to require this, as part of local 
SPD management.


Why do we need to use WESP in this context? The current argument you 
provided was that this was an issue for a router receiving OSPF 
traffic, not a middlebox issue. But the router knows that the traffic 
will be ESP-NULL, and knows the algorithm employed, so it should be 
able to examine this traffic easily. If the router wants to process 
traffic out-of-order, after examination, that too is easy, since 
there is no receiver sequence number checking, so processing the rest 
of the traffic (potentially with gaps) will not be a problem from an 
IPsec perspective.



I went back and analyzed the thread to see how we got to this point.

In his message of 11/16, Manav said:

And the reason why you might want to use WESP is to prioritize 
certain protocol packets over the others, as is normally done for v4 
control packets (e.g. OSPFv3 HELLOs and ACKs over other OSPFv3 
packets)


Tero question this assertion, citing packet ordering concerns, and 
Manav provided the following cryptic comment:


This is an implementation specific optimization that has already 
been solved in multiple implementations.


That caused me to ask what "implementation specific" optimizations meant, which
resulted in your response (11/17)


Do the seq number check, and then place the packets in different
priority queues/paths based on the kind of packet it is. Proprietary
ASICs on the routers can easily do this and its one of those things
that differentiate one vendor from the other.


This response seems confusing, since it discusses a sequence number 
check being performed in a context (OSPFv3) that calls for no such 
checks. Sriram noted that in a manual keying context (not just 
OSPFv3) sequence checking is not performed,

which reaffirmed the notion that this thread went awry.

Finally, Gregory said:

GML>  Or perhaps, a local security policy decision to ease up on the 
size of the enforcement window -- aka ease security requirements -- 
in order to get more QoS enforcement capability -- aka convenience 
-- ??


Which prompted my reply (10/21) noting that 4301 mandates QoS support 
via use of multiple SAs (which, as noted above, is also called for by 
4552) and that
using larger receive windows is always a local matter, not an 
implementation specific optimization.


It was this response that you labelled as "all wrong" and said:


... The sender is sending packets with the same QoS
parameters; its the receiver thats trying to prioritize some packets
over the others. One would typically do this for the Hellos/KeepAlives
that are associated with a protocol, so that the  adjacency/peering
session are not timed out.


So, it does not appear that the con

Re: [IPsec] WESP - Roadmap Ahead

[Jack Kohn]

>>
>> You got it all wrong. The sender is sending packets with the same QoS
>> parameters; its the receiver thats trying to prioritize some packets
>> over the others. One would typically do this for the Hellos/KeepAlives
>> that are associated with a protocol, so that the  adjacency/peering
>> session are not timed out.
>>
>> Jack
>
> Jack,
>
> Maybe I got it "all wrong" because the explanation provided in the messages
> was, at best, ambiguous :-).
>
> Your description above is only marginally better:
>
>- it fails to characterize the range of protocols for which you
> believe this argument applies,

http://www.ietf.org/mail-archive/web/ipsec/current/msg05070.html

This is one example, we could think of some more.

>
>-it fails to explain how WESP is relevant, since a receiver has the

This has already been discussed in this email thread earlier.

> ability to process encrypted packets. WESP is a protocol that has been
> promoted as designed to aid middle boxes, not end systems

Border Gateway Protocol (BGP) (http://www.ietf.org/rfc/rfc4271.txt)
was originally designed to work as an Exterior Gateway Protocol (EGP).
Today besides working as an EGP it is used in myriad other
applications, from discovering nodes in a VPN to distributing advisory
messages to remote network operators. So, i dont see a reason why we
should restrict ourselves to the applications for which a protocol can
be used ..

Jack

>
> Steve
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WESP - Roadmap Ahead

[Stephen Kent]

At 11:09 PM +0530 11/21/09, Jack Kohn wrote:

Steve,



 4301 contains We have explicit directions on how to use multiple SAs when
 the peers know that they want to send traffic with different QoS parameters.
 This appears to be an instance where the middle boxes are to examining
 traffic, and putting in into different QoS queues. That raises the question


You got it all wrong. The sender is sending packets with the same QoS
parameters; its the receiver thats trying to prioritize some packets
over the others. One would typically do this for the Hellos/KeepAlives
that are associated with a protocol, so that the  adjacency/peering
session are not timed out.

Jack


Jack,

Maybe I got it "all wrong" because the explanation provided in the 
messages was, at best, ambiguous :-).


Your description above is only marginally better:

	- it fails to characterize the range of protocols for which 
you believe this argument applies,


	-it fails to explain how WESP is relevant, since a receiver 
has the ability to process encrypted packets. WESP is a protocol that 
has been promoted as designed to aid middle boxes, not end systems


Steve
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WESP - Roadmap Ahead

[Jack Kohn]

Steve,

>
> 4301 contains We have explicit directions on how to use multiple SAs when
> the peers know that they want to send traffic with different QoS parameters.
> This appears to be an instance where the middle boxes are to examining
> traffic, and putting in into different QoS queues. That raises the question

You got it all wrong. The sender is sending packets with the same QoS
parameters; its the receiver thats trying to prioritize some packets
over the others. One would typically do this for the Hellos/KeepAlives
that are associated with a protocol, so that the  adjacency/peering
session are not timed out.

Jack
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WESP - Roadmap Ahead

[Stephen Kent]

At 11:03 AM -0800 11/17/09, Gregory Lebovitz wrote:

inline...

On Mon, Nov 16, 2009 at 8:18 AM, Stephen Kent 
<k...@bbn.com> wrote:


At 7:50 PM +0530 11/16/09, Bhatia, Manav (Manav) wrote:

This is an implementation specific optimization that has already 
been solved in multiple implementations.


Cheers, Manav


Is the phrase "implementation specific" a euphemism for non-standard?


GML>  Or perhaps, a local security policy decision to ease up on the 
size of the enforcement window -- aka ease security requirements -- 
in order to get more QoS enforcement capability -- aka convenience 
-- ??


4301 contains We have explicit directions on how to use multiple SAs 
when the peers know that they want to send traffic with different QoS 
parameters. This appears to be an instance where the middle boxes are 
to examining traffic, and putting in into different QoS queues. That 
raises the question of how a receiver would know that this is 
happening, so that a bigger enforcement window is needed.


ESP and AH already allow a receiving peer to select any size window 
that it wants, bigger than the specified minimum. So that is not an 
issue.


Steve___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WESP - Roadmap Ahead

[Jack Kohn]

Gregory,

Do you see how WESP can be used in KARP?

Jack


On Wed, Nov 18, 2009 at 12:49 AM, Gregory Lebovitz
 wrote:
> inline...
>
> On Mon, Nov 16, 2009 at 8:39 AM, Stephen Kent  wrote:
> --snip--
>
>>
>> I am not suggesting that any aspect of your analysis is flawed. I am
>> suggesting that before the WG chooses to further deprecate AH, it needs to
>> document the analysis supporting this decision, not just cite a couple of
>> examples and make general statements in support of such an action.
>
> WESP implementations need to occur, be deployed, and have some time in
> operational networks. It would benefit the standards process to get some
> feedback from the operational community once this has happened. Whether or
> not we call it "experimental", we need to try out the WESP mechanism, in
> parallel with the heuristics method, in the wild and see what comes of
> them.
> We need not be shy about WESP's existence and benefits. I agree we ought to
> go on a bit of an intra-IETF "road show" and get the word to other Areas and
> WG's about WESP as compared to AH, and see what feedback we get. This can
> only help the standards process. In this context, Steve's suggestion for a
> an analysis document would be very helpful. Much of the arguments made in
> this thread would be excellently housed in said document.
> After some time in the wild, If we observe signs that WESP is operationally
> replacing AH, then we could seriously discuss deprecating AH.
> HTH,
> Gregory.
>
>>
>> Steve
>> ___
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
>
>
>
> --
> 
> IETF related email from
> Gregory M. Lebovitz
> Juniper Networks
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WESP - Roadmap Ahead

[Gregory Lebovitz]

inline...

On Mon, Nov 16, 2009 at 8:39 AM, Stephen Kent  wrote:

--snip--


> I am not suggesting that any aspect of your analysis is flawed. I am
> suggesting that before the WG chooses to further deprecate AH, it needs to
> document the analysis supporting this decision, not just cite a couple of
> examples and make general statements in support of such an action.
>

WESP implementations need to occur, be deployed, and have some time in
operational networks. It would benefit the standards process to get some
feedback from the operational community once this has happened. Whether or
not we call it "experimental", we need to try out the WESP mechanism, in
parallel with the heuristics method, in the wild and see what comes of
them.

We need not be shy about WESP's existence and benefits. I agree we ought to
go on a bit of an intra-IETF "road show" and get the word to other Areas and
WG's about WESP as compared to AH, and see what feedback we get. This can
only help the standards process. In this context, Steve's suggestion for a
an analysis document would be very helpful. Much of the arguments made in
this thread would be excellently housed in said document.

After some time in the wild, If we observe signs that WESP is operationally
replacing AH, then we could seriously discuss deprecating AH.

HTH,
Gregory.


>
> Steve
>
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>



-- 

IETF related email from
Gregory M. Lebovitz
Juniper Networks
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WESP - Roadmap Ahead

[Gregory Lebovitz]

inline...

On Mon, Nov 16, 2009 at 8:18 AM, Stephen Kent  wrote:

> At 7:50 PM +0530 11/16/09, Bhatia, Manav (Manav) wrote:
>
>> This is an implementation specific optimization that has already been
>> solved in multiple implementations.
>>
>> Cheers, Manav
>>
>
> Is the phrase "implementation specific" a euphemism for non-standard?
>

GML>  Or perhaps, a local security policy decision to ease up on the size of
the enforcement window -- aka ease security requirements -- in order to get
more QoS enforcement capability -- aka convenience -- ??

GML> Gregory


>
> Steve
>
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>



-- 

IETF related email from
Gregory M. Lebovitz
Juniper Networks
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WESP - Roadmap Ahead

[Venkatesh Sriram]

Tero,

On Mon, Nov 16, 2009 at 6:39 PM, Tero Kivinen  wrote:
> Bhatia, Manav (Manav) writes:
>> And the reason why you might want to use WESP is to prioritize
>> certain protocol packets over the others, as is normally done for v4
>> control packets (e.g. OSPFv3 HELLOs and ACKs over other OSPFv3
>> packets)
>
> You cannot do that, as if the packets get reordered more than what is
> the replay window size of the responder, then older packets will get
> dropped. If you want to do QoS you need to use multiple IPsec SAs each
> carrying only one traffic for one QoS level.

Since processing of the sequence number fields is at the discretion of
the receiver, it can always elect not to enable the anti-replay
service for a specific SA for which it needs to prioritize certain
packets.

Also if the keys have been manually distributed, which would most
probably happen if WESP is being used as a standalone protocol then
compliant implementations SHOULD NOT provide anti-replay service.

In addition to this, we are discussing a multi-sender SA in which case
replay protection is anyways NOT recommended.

Sriram
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WESP - Roadmap Ahead

[Jack Kohn]

There multiple "implementation specific" optimizations available. One
such optimization that is currently in use in multiple platforms is:

Do the seq number check, and then place the packets in different
priority queues/paths based on the kind of packet it is. Proprietary
ASICs on the routers can easily do this and its one of those things
that differentiate one vendor from the other.

Jack

On Mon, Nov 16, 2009 at 9:48 PM, Stephen Kent  wrote:
> At 7:50 PM +0530 11/16/09, Bhatia, Manav (Manav) wrote:
>>
>> This is an implementation specific optimization that has already been
>> solved in multiple implementations.
>>
>> Cheers, Manav
>
> Is the phrase "implementation specific" a euphemism for non-standard?
>
> Steve
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WESP - Roadmap Ahead

[Dan McDonald]

On Mon, Nov 16, 2009 at 11:39:30AM -0500, Stephen Kent wrote:



> >Or put the labels in the SA, since especially for IPSO you probably
> >want cryptographic separation of different security levels.
> 
> There are various options here. I know of devices that have opted to
> use ESP in tunnel mode to ensure the binding, and that is what I
> noted during the IPSECME WG session. I may know of an instance or two
> where AH has been used to do this, because if introduced less
> (bandwidth) overhead than tunnel mode. Implementations that make use
> of IPSO or CIPSO should negotiate the labels as part of the SA. The
> label should be part of the SPD, and be checked based on SAD entry
> data cached form the SPD. (Can you tell that I've been through al of
> this?) We had a presentation by Joy (remotely) on adding label
> support, as a new work item, which would explore these issues in more
> detail, if we choose to adopt this as a new Wg item.

If the WG takes on labeling, please make sure we don't concentrate on just
one platform (SELinux).  Besides Joy's work, there's now also SA-implicit
labeling on another platform:

http://hub.opensolaris.org/bin/view/Project+txipsec/

Once build 128 hits the servers, you can play with it!

FYI,
Dan
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WESP - Roadmap Ahead

[Stephen Kent]

...

Divine guidance is, I suppose, one way to do protocol design, but it 
could lead to *real* religious wars


an appropriate caution given my typo :-).


 >
 Also, note that IPSO and CIPSO are examples of options that were 
discussed at the IPSECME meeting this week, where there is a need 
to bind the options to the payload.  I observed that using tunnel 
mode (ESP) addresses this concern, but one could also note that 
using AH would do the same, with lower per-packet bandwidth 
overhead.


Or put the labels in the SA, since especially for IPSO you probably 
want cryptographic separation of different security levels.


There are various options here. I know of devices that have opted to 
use ESP in tunnel mode to ensure the binding, and that is what I 
noted during the IPSECME WG session. I may know of an instance or two 
where AH has been used to do this, because if introduced less 
(bandwidth) overhead than tunnel mode. Implementations that make use 
of IPSO or CIPSO should negotiate the labels as part of the SA. The 
label should be part of the SPD, and be checked based on SAD entry 
data cached form the SPD. (Can you tell that I've been through al of 
this?) We had a presentation by Joy (remotely) on adding label 
support, as a new work item, which would explore these issues in more 
detail, if we choose to adopt this as a new Wg item.


I did go through the analysis you suggest for IPv4 and concluded 
that nothing was both protectable and useful.  I also noted the 
following issue:


Furthermore, the AH spec says that we can't
enumerate the v4 options, and hence whether or not they should
be included or not -- but RFC1122 says that unknown IP options
MUST be silently ignored.  So an implementation can receive an
option that it doesn't recognize, doesn't know if it changes
en route, must be ignored anyway -- but may or may not be included
in the AH calculation, and the receiver doesn't know.

Note, of course, that that was from 1995; I have not repeated the 
analysis for newer AH or IPv6 specs.


I am not suggesting that any aspect of your analysis is flawed. I am 
suggesting that before the WG chooses to further deprecate AH, it 
needs to document the analysis supporting this decision, not just 
cite a couple of examples and make general statements in support of 
such an action.


Steve
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WESP - Roadmap Ahead

[Stephen Kent]

At 7:50 PM +0530 11/16/09, Bhatia, Manav (Manav) wrote:
This is an implementation specific optimization that has already 
been solved in multiple implementations.


Cheers, Manav


Is the phrase "implementation specific" a euphemism for non-standard?

Steve
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WESP - Roadmap Ahead

[Bhatia, Manav (Manav)]

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@ietf.org
> Subject: RE: [IPsec] WESP - Roadmap Ahead
> 
> Bhatia, Manav (Manav) writes:
> > And the reason why you might want to use WESP is to prioritize
> > certain protocol packets over the others, as is normally done for v4
> > control packets (e.g. OSPFv3 HELLOs and ACKs over other OSPFv3
> > packets) 
> 
> You cannot do that, as if the packets get reordered more than what is
> the replay window size of the responder, then older packets will get
> dropped. If you want to do QoS you need to use multiple IPsec SAs each
> carrying only one traffic for one QoS level.
> 
> See RFC4301 section 4.1.
> -- 
> kivi...@iki.fi
> 
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WESP - Roadmap Ahead

[Tero Kivinen]

Bhatia, Manav (Manav) writes:
> And the reason why you might want to use WESP is to prioritize
> certain protocol packets over the others, as is normally done for v4
> control packets (e.g. OSPFv3 HELLOs and ACKs over other OSPFv3
> packets) 

You cannot do that, as if the packets get reordered more than what is
the replay window size of the responder, then older packets will get
dropped. If you want to do QoS you need to use multiple IPsec SAs each
carrying only one traffic for one QoS level.

See RFC4301 section 4.1.
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WESP - Roadmap Ahead

[Bhatia, Manav (Manav)]

 
> 
> 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 requested at end of 2003.
> 
> So stable draft which could be used to implement IKEv2 was ready 6
> years ago, and while there are several implementations out, people are
> still using IKEv1. Also before WESP can be used people would first
> need to move to IKEv2 anyways... 

Not all applications of WESP (or AH and ESP for that matter) would require an 
IKEv2 negotiation. You could use WESP as a protocol for routing protocol 
authentication without an IKEv2 extension.

And the reason why you might want to use WESP is to prioritize certain protocol 
packets over the others, as is normally done for v4 control packets (e.g. 
OSPFv3 HELLOs and ACKs over other OSPFv3 packets)

Cheers, Manav
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] WESP - Roadmap Ahead

[Tero Kivinen]

Jack Kohn writes:
> From operational perspective if we are supporting both v4 and v6 (and we
> will) then having different protocols ESP and AH is and will be a
> nightmare.  Common denominator is ESP-Null. However, there were issues with
> ESP-Null as it couldnt be deep inspected which has now been solved with
> WESP.

ESP-NULL and AH will still have different properties. AH will also
protect data which is not protected by the ESP-NULL, i.e. IP-header
including IP-addresses (unless ESP-NULL is used with tunnel mode). 

> In short, the argument that "Oh, but we can inspect AH packets" is not
> relevant anymore.

I do not think it was never really relevant... AH was not used because
it offers ability to inspect packets, it was used when encryption was
not necessarely and where protection of the IP header was needed. 

> Given this, should we still have AH as a MAY for IPSEC - Cant we deprecate
> it?

I do not see any reason why it should be deprecated. It is already MAY
which means it does not need to be implemented unless your environment
or use scenario needs it. I was earlier in favor of changing it to
MAY, but I do not think we need to move it further than that. 

> WESP is ESP++, and it offers everthing that ESP offers plus more. What is
> our stance for ESP moving forward?

I am very sceptical for the WESP getting lots of implementations
quickly, so I do not really consider WESP as competitor for ESP. Also
I do not see any reason to wasting bytes for extra WESP header for
encrypted traffic, so I assume WESP will be used (if it will be used)
for ESP-NULL traffic not for encrypted traffic. 

> Also, I see that a lot of work done in other WGs is still using ESP
> (primarily for data integrity). Shouldn?t they be moving to WESP, as WESP
> offers more flexibility?

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 requested at end of 2003.

So stable draft which could be used to implement IKEv2 was ready 6
years ago, and while there are several implementations out, people are
still using IKEv1. Also before WESP can be used people would first
need to move to IKEv2 anyways... 
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WESP - Roadmap Ahead

[Steven Bellovin]

On Nov 13, 2009, at 12:16 AM, Stephen Kent wrote:

> My message pointed out that there was no mention of options,  Your reply 
> picked a couple of option examples and argued that they were either not used 
> or did not pose a security problem.
> 
> The right way to generate a god answer is to construct a table of all the 
> options, and provide a rationale for why each one is not covered, deprecated, 
> or not secruity relevant.

Divine guidance is, I suppose, one way to do protocol design, but it could lead 
to *real* religious wars
> 
> Also, note that IPSO and CIPSO are examples of options that were discussed at 
> the IPSECME meeting this week, where there is a need to bind the options to 
> the payload.  I observed that using tunnel mode (ESP) addresses this concern, 
> but one could also note that using AH would do the same, with lower 
> per-packet bandwidth overhead.

Or put the labels in the SA, since especially for IPSO you probably want 
cryptographic separation of different security levels.

I did go through the analysis you suggest for IPv4 and concluded that nothing 
was both protectable and useful.  I also noted the following issue:

Furthermore, the AH spec says that we can't
enumerate the v4 options, and hence whether or not they should
be included or not -- but RFC1122 says that unknown IP options
MUST be silently ignored.  So an implementation can receive an
option that it doesn't recognize, doesn't know if it changes
en route, must be ignored anyway -- but may or may not be included
in the AH calculation, and the receiver doesn't know.

Note, of course, that that was from 1995; I have not repeated the analysis for 
newer AH or IPv6 specs.

--Steve Bellovin, http://www.cs.columbia.edu/~smb





___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WESP - Roadmap Ahead

[Stephen Kent]

My message pointed out that there was no mention of options,  Your 
reply picked a couple of option examples and argued that they were 
either not used or did not pose a security problem.


The right way to generate a god answer is to construct a table of all 
the options, and provide a rationale for why each one is not covered, 
deprecated, or not secruity relevant.


Also, note that IPSO and CIPSO are examples of options that were 
discussed at the IPSECME meeting this week, where there is a need to 
bind the options to the payload.  I observed that using tunnel mode 
(ESP) addresses this concern, but one could also note that using AH 
would do the same, with lower per-packet bandwidth overhead.


Steve
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WESP - Roadmap Ahead

[Bhatia, Manav (Manav)]

Yup, that's correct I had not considered multicast.

SSM groups would use a 3-tuple SA identifier composed of an SPI, a dest mcast 
address, and the source IP. An Any-Source Multicast group SA would only require 
an SPI and a dest mcast identifier. If either of the IPs change, wouldn'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
> Subject: Re: [IPsec] WESP - Roadmap Ahead
> 
> I think this argument implicitly assumes unicast.
> 
> Rich Graveman
> 
> On Thu, Nov 12, 2009 at 8:18 PM, Bhatia, Manav (Manav)
>  wrote:
> > Daniel,
> >
> >> AH is a security feature we need to keep for header authentication
> >
> > Am really not sure about the value that AH adds even in 
> case of header authentication.
> >
> > So what fields does AH protect:
> >
> > Version, Payload length, Next Header, Source IP and dest IP
> >
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WESP - Roadmap Ahead

[Bhatia, Manav (Manav)]

> >
> >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 mutable but a predictable extension header. It has been 
discovered and is widely known that these functionalities can be exploited in 
order to perform remote network discovery, can be used to bypass firewalls and 
can be used for DoS attacks. RFC 5095 has more details on this. This has been 
deprecated and nobody is really using this.

Hop-by-Hop Options and Destination Extension Headers

These options contain a bit that indicates whether the option might change 
(unpredictably) during transit.  For any option for which contents may change 
en-route, the entire "Option Data" field must be treated as zero-valued octets 
when computing or verifying the ICV.  The Option Type and Opt Data Len are 
included in the ICV calculation. All options for which the bit indicates 
immutability are included in the ICV calculation.  

If we were to use ESP-NULL instead then there is no way to validate whether the 
Option Type and Opt Data Len is valid or not till the processing is done at the 
receiving end.

So, what kind of attack can be possibly done by changing these values? What is 
the real risk involved here?

Fragmentation Header

Fragmentation occurs after AH processing and the reassembly, before AH 
processing on the other end. So, there is really no gain there too.

Cheers, Manav 
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WESP - Roadmap Ahead

[Stephen Kent]

At 6:48 AM +0530 11/13/09, Bhatia, Manav (Manav) wrote:

Daniel,


 AH is a security feature we need to keep for header authentication


Am really not sure about the value that AH adds even in case of 
header authentication.


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


Steve
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WESP - Roadmap Ahead

[Richard Graveman]

I think this argument implicitly assumes unicast.

Rich Graveman

On Thu, Nov 12, 2009 at 8:18 PM, Bhatia, Manav (Manav)
 wrote:
> Daniel,
>
>> AH is a security feature we need to keep for header authentication
>
> Am really not sure about the value that AH adds even in case of header 
> authentication.
>
> So what fields does AH protect:
>
> Version, Payload length, Next Header, Source IP and dest IP
>
> The only field worth modifying is the source and the dest IP. Now note that 
> an IPSec SA is established between a pair of source IP and dest IP. Upon 
> receipt of a packet containing an AH header, the receiver determines the 
> appropriate (unidirectional) SA, based on the dest IP, security protocol 
> (AH), and the SPI (it could also include the source IP). If the attacker 
> modifies (or spoofs) either of the source or the dest IP, the SA lookup will 
> fail and the receiver will regardless discard the packet. So what are we 
> gaining by AH "header authentication"?
>
> AH can only add value over ESP-NULL if there are instances where despite 
> address spoofing we erroneously process the IPSec packet. I don't see that 
> happening, so is this really an issue?
>
> Cheers, Manav
> 
>
>        From: Daniel Migault [mailto:mglt.i...@gmail.com]
>        Sent: Thursday, November 12, 2009 11.14 AM
>        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 and they do cite 
> ESP-NULL (although
>                > they never refer to it that way) as a MUST, and AH as a MAY.
>
>                Ok, so can we work on deprecating AH? This way new standards 
> defined
>                in other WGs dont have to provide support for AH.
>
>
>        AH is a security feature we need to keep for header authentication. 
> Other WG may chose not to deal with AH and only consider ESP. I don't see 
> what's wrong with that?
>
>         Regards
>
>        Daniel
>        --
>        Daniel Migault
>        Orange Labs -- Security
>        +33 6 70 72 69 58
>
>
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WESP - Roadmap Ahead

[Bhatia, Manav (Manav)]

Daniel,

> AH is a security feature we need to keep for header authentication
 
Am really not sure about the value that AH adds even in case of header 
authentication.
 
So what fields does AH protect:
 
Version, Payload length, Next Header, Source IP and dest IP
 
The only field worth modifying is the source and the dest IP. Now note that an 
IPSec SA is established between a pair of source IP and dest IP. Upon receipt 
of a packet containing an AH header, the receiver determines the appropriate 
(unidirectional) SA, based on the dest IP, security protocol (AH), and the SPI 
(it could also include the source IP). If the attacker modifies (or spoofs) 
either of the source or the dest IP, the SA lookup will fail and the receiver 
will regardless discard the packet. So what are we gaining by AH "header 
authentication"?

AH can only add value over ESP-NULL if there are instances where despite 
address spoofing we erroneously process the IPSec packet. I don't see that 
happening, so is this really an issue?

Cheers, Manav


From: Daniel Migault [mailto:mglt.i...@gmail.com] 
Sent: Thursday, November 12, 2009 11.14 AM
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 and they do cite 
ESP-NULL (although
> they never refer to it that way) as a MUST, and AH as a MAY.

Ok, so can we work on deprecating AH? This way new standards 
defined
in other WGs dont have to provide support for AH.


AH is a security feature we need to keep for header authentication. 
Other WG may chose not to deal with AH and only consider ESP. I don't see 
what's wrong with that?

 Regards

Daniel
-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WESP - Roadmap Ahead

[Steven Bellovin]

On Nov 11, 2009, at 3:56 PM, Stephen Kent wrote:

> Jack,
> 
> 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 a need to 
> coordinate with them, and it may be unacceptable to kill AH as a standalone 
> protocol for them.

I believe that most such uses date from the "just use IPsec" era of security 
design.  I further suspect that it is very rarely used or even implemented in 
practice, and that in many cases it wouldn't in fact have been usable.

Yes, as a matter of due diligence someone needs to check if it's still mandated 
for anything, and if so figure out what to do.  But I'd be very happy if AH 
were to go awa; I concluded in 1995 that it was pretty useless.


--Steve Bellovin, http://www.cs.columbia.edu/~smb





___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WESP - Roadmap Ahead

[Daniel Migault]

On Thu, Nov 12, 2009 at 5:30 AM, Jack Kohn  wrote:

> >
> > Whoops, I was wrong. I looked at 4552 and they do cite ESP-NULL (although
> > they never refer to it that way) as a MUST, and AH as a MAY.
>
> Ok, so can we work on deprecating AH? This way new standards defined
> in other WGs dont have to provide support for AH.
>
>
AH is a security feature we need to keep for header authentication. Other WG
may chose not to deal with AH and only consider ESP. I don't see what's
wrong with that?

 Regards

Daniel
-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WESP - Roadmap Ahead

[Jack Kohn]

>
> Whoops, I was wrong. I looked at 4552 and they do cite ESP-NULL (although
> they never refer to it that way) as a MUST, and AH as a MAY.

Ok, so can we work on deprecating AH? This way new standards defined
in other WGs dont have to provide support for AH.

Jack

>
> I probably was confused because the authors did not understand the IPsec
> model as per RFC 4301, when I sat down and talked with them over 3 years
> ago, with Sam Hartman in his SEC AD role. I am amazed that, in the final
> analysis, they did try to adhere to the 4301 model (see section 11)!
>
> I don't know if any other apps have done what I thought (erroneously) had
> been done here.
>
> Steve
>
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WESP - Roadmap Ahead

[Bhatia, Manav (Manav)]

> 
> All of the standards I've seen that explicitly define how 
> IPsec is to  
> be used for authentication (including RFC 4552 - Authentication/ 
> Confidentiality for OSPFv3) say that for authentication 
> ESP-Null MUST  
> be used and AH MAY.

In fact there was some discussion of using IPSec for OSPFv2 authentication, and 
that proposal too uses ESP as a MUST and AH as a MAY.

http://tools.ietf.org/html/draft-gupta-ospf-ospfv2-sec-01

Cheers, Manav

> 
> Which RFCs specify AH specifically as a MUST for authentication/ 
> integrity?
> 
> Now on the 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:
> 
> > 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 a need to coordinate with them, and it may be  
> >>> unacceptable to
> >>>  kill AH as a standalone protocol for them.
> >>
> >> I agree that it is a trifle too early to start deprecating AH,  
> >> though I wouldn't mind doing so. OTOH, don't most WGs already  
> >> suggest AH as a MAY, and ESP-NULL as a MUST?
> >
> > Not always. For example, I believe that OSPF security makes use of  
> > AH, outside the IPsec context.
> >
> >> In any case what should be the stand for the newer work 
> that comes  
> >> out of these WGs. Should they spell out support for AH, or should  
> >> they just be talking about ESP (or ESP-NULL or WESP)?
> >
> > I'd recommend ESP-NULL, unless the context on which the operate  
> > might require inspection by an intermediate system.
> >
> >> If we want to deprecate AH, or at least discourage its use in the  
> >> context of the IPSec architecture in the near future then  
> >> shouldn't we be working on this?
> >
> > Part of the problem is that some WGs want to make use of IPsec  
> > protocols outside of the IPsec architecture.
> >
> >>  > I am not comfortable with the notion of ESP with WESP.  
> WESP adds
> >>  > more per-packet overhead than ESP, and some users are very  
> >> sensitive
> >>>  to this aspect of IPsec use. Also, other WG rely on ESP and we  
> >>> would
> >>>  need to convince them that the packet inspection features of WESP
> >>>  merit making changes to their standards, which might be a tough  
> >>> sell.
> >>
> >> I agree. However, we should start socializing WESP in 
> other WGs so  
> >> that folks are at least aware of it.
> >
> > Agree.
> >
> > ___
> > IPsec mailing list
> > IPsec@ietf.org
> > https://www.ietf.org/mailman/listinfo/ipsec
> >
> 
> 
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WESP - Roadmap Ahead

[Stephen Kent]

At 7:49 PM -0800 11/11/09, Merike Kaeo wrote:
All of the standards I've seen that explicitly define how IPsec is 
to be used for authentication (including RFC 4552 - 
Authentication/Confidentiality for OSPFv3) say that for 
authentication ESP-Null MUST be used and AH MAY.


Which RFCs specify AH specifically as a MUST for authentication/integrity?

Now on the 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


Whoops, I was wrong. I looked at 4552 and they do cite ESP-NULL 
(although they never refer to it that way) as a MUST, and AH as a MAY.


I probably was confused because the authors did not understand the 
IPsec model as per RFC 4301, when I sat down and talked with them 
over 3 years ago, with Sam Hartman in his SEC AD role. I am amazed 
that, in the final analysis, they did try to adhere to the 4301 model 
(see section 11)!


I don't know if any other apps have done what I thought (erroneously) 
had been done here.


Steve

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WESP - Roadmap Ahead

[Bhatia, Manav (Manav)]

 
> All of the standards I've seen that explicitly define how 
> IPsec is to  
> be used for authentication (including RFC 4552 - Authentication/ 
> Confidentiality for OSPFv3) say that for authentication 
> ESP-Null MUST  
> be used and AH MAY.

Yes, this is correct.

The latest PIM-SM authentication document 
(http://tools.ietf.org/html/draft-ietf-pim-sm-linklocal-08) uses IPSec to 
authenticate link-local messages in PIM-SM. It too says that ESP is a MUST 
while use of AH is optional.
 
> 
> Which RFCs specify AH specifically as a MUST for authentication/ 
> integrity?

I am not aware of any that do that.

> 
> Now on the 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 :)

I don't think 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 a need to coordinate with them, and it may be  
> >>> unacceptable to
> >>>  kill AH as a standalone protocol for them.
> >>
> >> I agree that it is a trifle too early to start deprecating AH,  
> >> though I wouldn't mind doing so. OTOH, don't most WGs already  
> >> suggest AH as a MAY, and ESP-NULL as a MUST?
> >
> > Not always. For example, I believe that OSPF security makes use of  
> > AH, outside the IPsec context.
> >
> >> In any case what should be the stand for the newer work 
> that comes  
> >> out of these WGs. Should they spell out support for AH, or should  
> >> they just be talking about ESP (or ESP-NULL or WESP)?
> >
> > I'd recommend ESP-NULL, unless the context on which the operate  
> > might require inspection by an intermediate system.
> >
> >> If we want to deprecate AH, or at least discourage its use in the  
> >> context of the IPSec architecture in the near future then  
> >> shouldn't we be working on this?
> >
> > Part of the problem is that some WGs want to make use of IPsec  
> > protocols outside of the IPsec architecture.
> >
> >>  > I am not comfortable with the notion of ESP with WESP.  
> WESP adds
> >>  > more per-packet overhead than ESP, and some users are very  
> >> sensitive
> >>>  to this aspect of IPsec use. Also, other WG rely on ESP and we  
> >>> would
> >>>  need to convince them that the packet inspection features of WESP
> >>>  merit making changes to their standards, which might be a tough  
> >>> sell.
> >>
> >> I agree. However, we should start socializing WESP in 
> other WGs so  
> >> that folks are at least aware of it.
> >
> > Agree.
> >
> > ___
> > IPsec mailing list
> > IPsec@ietf.org
> > https://www.ietf.org/mailman/listinfo/ipsec
> >
> 
> 
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WESP - Roadmap Ahead

[Merike Kaeo]

All of the standards I've seen that explicitly define how IPsec is to  
be used for authentication (including RFC 4552 - Authentication/ 
Confidentiality for OSPFv3) say that for authentication ESP-Null MUST  
be used and AH MAY.


Which RFCs specify AH specifically as a MUST for authentication/ 
integrity?


Now on the 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:


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 a need to coordinate with them, and it may be  
unacceptable to

 kill AH as a standalone protocol for them.


I agree that it is a trifle too early to start deprecating AH,  
though I wouldn't mind doing so. OTOH, don't most WGs already  
suggest AH as a MAY, and ESP-NULL as a MUST?


Not always. For example, I believe that OSPF security makes use of  
AH, outside the IPsec context.


In any case what should be the stand for the newer work that comes  
out of these WGs. Should they spell out support for AH, or should  
they just be talking about ESP (or ESP-NULL or WESP)?


I'd recommend ESP-NULL, unless the context on which the operate  
might require inspection by an intermediate system.


If we want to deprecate AH, or at least discourage its use in the  
context of the IPSec architecture in the near future then  
shouldn't we be working on this?


Part of the problem is that some WGs want to make use of IPsec  
protocols outside of the IPsec architecture.



 > I am not comfortable with the notion of ESP with WESP.  WESP adds
 > more per-packet overhead than ESP, and some users are very  
sensitive
 to this aspect of IPsec use. Also, other WG rely on ESP and we  
would

 need to convince them that the packet inspection features of WESP
 merit making changes to their standards, which might be a tough  
sell.


I agree. However, we should start socializing WESP in other WGs so  
that folks are at least aware of it.


Agree.

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec



___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WESP - Roadmap Ahead

[Stephen Kent]

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 a need to coordinate with them, and it may be unacceptable to
 kill AH as a standalone protocol for them.


I agree that it is a trifle too early to start deprecating AH, 
though I wouldn't mind doing so. OTOH, don't most WGs already 
suggest AH as a MAY, and ESP-NULL as a MUST?


Not always. For example, I believe that OSPF security makes use of 
AH, outside the IPsec context.


In any case what should be the stand for the newer work that comes 
out of these WGs. Should they spell out support for AH, or should 
they just be talking about ESP (or ESP-NULL or WESP)?


I'd recommend ESP-NULL, unless the context on which the operate might 
require inspection by an intermediate system.


If we want to deprecate AH, or at least discourage its use in the 
context of the IPSec architecture in the near future then shouldn't 
we be working on this?


Part of the problem is that some WGs want to make use of IPsec 
protocols outside of the IPsec architecture.



 > I am not comfortable with the notion of ESP with WESP.  WESP adds
 > more per-packet overhead than ESP, and some users are very sensitive

 to this aspect of IPsec use. Also, other WG rely on ESP and we would
 need to convince them that the packet inspection features of WESP
 merit making changes to their standards, which might be a tough sell.


I agree. However, we should start socializing WESP in other WGs so 
that folks are at least aware of it.


Agree.

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WESP - Roadmap Ahead

[Bhatia, Manav (Manav)]

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 a need to coordinate with them, and it may be unacceptable to 
> kill AH as a standalone protocol for them.

I agree that it is a trifle too early to start deprecating AH, though I 
wouldn't mind doing so. OTOH, don't most WGs already suggest AH as a MAY, and 
ESP-NULL as a MUST?  In any case what should be the stand for the newer work 
that comes out of these WGs. Should they spell out support for AH, or should 
they just be talking about ESP (or ESP-NULL or WESP)?

If we want to deprecate AH, or at least discourage its use in the context of 
the IPSec architecture in the near future then shouldn't we be working on this?

> 
> I am not comfortable with the notion of ESP with WESP.  WESP adds 
> more per-packet overhead than ESP, and some users are very sensitive 
> to this aspect of IPsec use. Also, other WG rely on ESP and we would 
> need to convince them that the packet inspection features of WESP 
> merit making changes to their standards, which might be a tough sell. 

I agree. However, we should start socializing WESP in other WGs so that folks 
are at least aware of it. 

Cheers, Manav

> So, I cannot support this suggestion.
> 
> Steve
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
> 
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WESP - Roadmap Ahead

[Bhatia, Manav (Manav)]

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.  
> There's disagreement between end-node and middle-node folks as to whether 
> WESP or heuristics are the best approach for inspection of ESP-NULL traffic.  
> I think that end-node vendors will be very reluctant to adopt 

I cant comment on the interest of the end-node vendors, but i can certainly say 
that this will be of interest to the router vendors. There are currently a lot 
of applications (routing/signaling for instance) where we use ESP-NULL for 
integrity protection (confidentiality is not an issue there) and it will be 
really good if there are ways to deep inspect these packets for proper QoS 
treatment.

> WESP widely until there is broad customer demand for it, and I'm not 
> sure that this demand will ever materialize. 
>   
> This is all my personal opinion, of course.  But it seems to me that 
> heuristics 
> will have to be adopted by competitive middle-node vendors, and 
> therefore (barring any extensions to WESP that make it attractive 
> for other reasons) the use of heuristics will probably always be more 
> widespread and will dampen the demand for WESP.  Additionally, 

There you go:

http://tools.ietf.org/html/draft-montenegro-ipsecme-wesp-extensions-00

> ESP-NULL itself has rather narrow applicability in an environment where 
> end-to-end encryption is increasingly common, which further limits 

Most routing, signaling protocols use ESP-NULL (it's a MUST, while support for 
AH is a MAY) and I can see benefits of moving to WESP from the QoS perspective. 
I am not saying that we cannot do QoS with ESP, but it just becomes a tad more 
flexible/easier with WESP.

> the cases where there will be an absolute need for WESP.  Furthermore, 
> there will always be valid reasons to use AH (reduced overhead compared to 
> WESP). 
>   
> For reasons like these, I believe it's premature to call for deprecation 
> of AH and even more premature to start preferring WESP to ESP. 

I agree.

>
> What status will the WESP RFC have?  Experimental, informational, standards 
> track, etc.? 

Standards Track

Cheers, Manav

> 
>
> Scott Moonen (smoo...@us.ibm.com)
> z/OS Communications Server TCP/IP Development
> http://www.linkedin.com/in/smoonen <http://www.linkedin.com/in/smoonen>  

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WESP - Roadmap Ahead

[Tero Kivinen]

Scott C Moonen writes:
> Jack, I'm not sure it's clear yet whether WESP will be widely adopted. 
> There's disagreement between end-node and middle-node folks as to whether 
> WESP or heuristics are the best approach for inspection of ESP-NULL 
> traffic.  I think that end-node vendors will be very reluctant to adopt 
> WESP widely until there is broad customer demand for it, and I'm not sure 
> that this demand will ever materialize.

I agree on that... 

> This is all my personal opinion, of course.  But it seems to me that 
> heuristics will have to be adopted by competitive middle-node vendors, and 
> therefore (barring any extensions to WESP that make it attractive for 
> other reasons) the use of heuristics will probably always be more 
> widespread and will dampen the demand for WESP.  Additionally, ESP-NULL 
> itself has rather narrow applicability in an environment where end-to-end 
> encryption is increasingly common, which further limits the cases where 
> there will be an absolute need for WESP.  Furthermore, there will always 
> be valid reasons to use AH (reduced overhead compared to WESP).

And wider protection, i.e. IP addresses and options... 

> For reasons like these, I believe it's premature to call for deprecation 
> of AH and even more premature to start preferring WESP to ESP.

Agree on that too. 

> What status will the WESP RFC have?  Experimental, informational, 
> standards track, etc.?

It is aimed for proposed standard, altough I would be happier if would
be aimed for experimental. 
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WESP - Roadmap Ahead

[Scott C Moonen]

Jack, I'm not sure it's clear yet whether WESP will be widely adopted. 
There's disagreement between end-node and middle-node folks as to whether 
WESP or heuristics are the best approach for inspection of ESP-NULL 
traffic.  I think that end-node vendors will be very reluctant to adopt 
WESP widely until there is broad customer demand for it, and I'm not sure 
that this demand will ever materialize.

This is all my personal opinion, of course.  But it seems to me that 
heuristics will have to be adopted by competitive middle-node vendors, and 
therefore (barring any extensions to WESP that make it attractive for 
other reasons) the use of heuristics will probably always be more 
widespread and will dampen the demand for WESP.  Additionally, ESP-NULL 
itself has rather narrow applicability in an environment where end-to-end 
encryption is increasingly common, which further limits the cases where 
there will be an absolute need for WESP.  Furthermore, there will always 
be valid reasons to use AH (reduced overhead compared to WESP).

For reasons like these, I believe it's premature to call for deprecation 
of AH and even more premature to start preferring WESP to ESP.

What status will the WESP RFC have?  Experimental, informational, 
standards track, etc.?


Scott Moonen (smoo...@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen



From:
Jack Kohn 
To:
ipsec@ietf.org
Date:
11/11/2009 11:06 AM
Subject:
[IPsec] WESP - Roadmap Ahead



Hi,

From operational perspective if we are supporting both v4 and v6 (and we 
will) then having different protocols ESP and AH is and will be a 
nightmare.  Common denominator is ESP-Null. However, there were issues 
with ESP-Null as it couldnt be deep inspected which has now been solved 
with WESP.

In short, the argument that "Oh, but we can inspect AH packets" is not 
relevant anymore.

Given this, should we still have AH as a MAY for IPSEC - Cant we deprecate 
it? 

WESP is ESP++, and it offers everthing that ESP offers plus more. What is 
our stance for ESP moving forward?

Also, I see that a lot of work done in other WGs is still using ESP 
(primarily for data integrity). Shouldn’t they be moving to WESP, as WESP 
offers more flexibility?

Jack
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec



___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WESP - Roadmap Ahead

[Stephen Kent]

Jack,

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 a need to coordinate with them, and it may be unacceptable to 
kill AH as a standalone protocol for them.


I am not comfortable with the notion of ESP with WESP.  WESP adds 
more per-packet overhead than ESP, and some users are very sensitive 
to this aspect of IPsec use. Also, other WG rely on ESP and we would 
need to convince them that the packet inspection features of WESP 
merit making changes to their standards, which might be a tough sell. 
So, I cannot support this suggestion.


Steve
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] WESP - Roadmap Ahead

[Jack Kohn]

Hi,

>From operational perspective if we are supporting both v4 and v6 (and we
will) then having different protocols ESP and AH is and will be a
nightmare.  Common denominator is ESP-Null. However, there were issues with
ESP-Null as it couldnt be deep inspected which has now been solved with
WESP.

In short, the argument that "Oh, but we can inspect AH packets" is not
relevant anymore.

Given this, should we still have AH as a MAY for IPSEC - Cant we deprecate
it?

WESP is ESP++, and it offers everthing that ESP offers plus more. What is
our stance for ESP moving forward?

Also, I see that a lot of work done in other WGs is still using ESP
(primarily for data integrity). Shouldn’t they be moving to WESP, as WESP
offers more flexibility?

Jack
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec