Re: [IPsec] WESP - Roadmap Ahead

[Stephen Kent <[e-mail]>]

>...
>  >        - 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 context has changed since Manav cited 
OSPFv3 a week ago, yet all the arguments about sequence number 
checking (by IPsec) are irrelevant in this context. I have seen no 
good arguments about why WESP is needed here, i.e., what benefits it 
offers for a router receiving OSPF traffic, some of which may need to 
be processed out-of-order.

Steve