...
> - 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
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
