Re: Choosing between IKEv2 and JFK

[Jan Vilhuber <vilhuber@cisco.com>]

On Thu, 7 Mar 2002, Angelos D. Keromytis wrote:

> 
> In message <Pine.LNX.4.33.0203071347150.29434-100000@janpc-home.cisco.com>, Jan
>   Vilhuber writes:
>  >
>  >Yes. Think about it: If you have load and high priority traffic on the
>  >same SA, and there are not only reordering (and prioritization) of
>  >packets as they leave the box, but also when they enter (and are
>  >processed by) the receiver AND there is prioritization and reordering
>  >happening IN THE NETWORK (assuming QoS ever becomes more prevalent),
>  >then chances are the receiver will see a LOT of the higher priority
>  >packets before he sees any low priority packets.
>  >
>  >hence each high priority packet will advance the replay window, until
>  >finally some low priority packet comes in which is rejected, since the
>  >replay window has moved too far forward due to the high priority
>  >packets.
>  >
>  >Hence: Separate SA's and replay counters.
> 
> Yes, in that scenario you would need separate SAs.
> 
> However, I would assume that, in the case of multiple traffic streams of
> different priorities going over the same IPsec tunnel (*), the sender:
> 
> a) would request for the ESP traffic the same priority level as the highest
>     priority among the different data streams, and

But that would kill QoS.

Also, I thought the IPsec specs say to copy the inner Tos bits to the
outer header. Now you are saying we copy the inner tos bits and map
them to the highest of all streams in our ESP tunnel.


> b) would do its own prioritization for packets entering the tunnel
>    (treating the tunnel as a link on its own)
> 

Not sure I get this. I think you'd do this anyway, but the problem is
that high priority packets will traverse the network at large faster
than low priority traffic.

I don't think it's valid to just put all your ESP packets into the
highest QoS level....


> The network and the receiver can do prioritization only if:
> 1) they can decrypt the ESP packets (in which case, there's not issue with
>     the replay window), or
> 2) the packets are marked appropriately by the sender
> 
> So the sender has control over QoS in this case. Then again, I'm not a QoS
> person.
> 
> (*) I use the term tunnel in a general sense, I don't want to start another
>      holy war about its use and exact semantics, or transport vs. tunnel mode.
> 

:)


>  >> --- huge, monolithic protocols are not pleasant to specify,
>  >> analyze, implement, or debug. On a slightly more philosophical vein, they
>  >> promote both bloat
>  >
>  >What kind of bloat are we talking about?
> 
> Piling up of not-very-necessary features.
> 

Like doing QoS' admission control for it?


>  >> (see IKEv1) and bad APIs (another source of trouble and
>  >> embarassments).
>  >
>  >Underspecification in a protocol definition leads to bad API's, not a
>  >comprehensive protocol...
> 
> To begin with, a complex protocol is more likely to be underspecified. And,
> complicated protocols lead to complicated APIs (because people feel the need to
> exploit all the features offered by the protocol).
> 
>  >IOS does, I believe. Not an unprotected notify, of course.
> 
> That hasn't been my experience, with any vendor I've interoperated with (mind
> you, *my* implementations are not doing any better).
> 
>  >That's because so far there's been much confusion surrounding these
>  >exchanges. If they were clearly spelled out in their use and semantics
>  >(note: well defined protocol specification), this wouldn't be nearly
>  >as confusing. We're finding that it's becoming very important to have
>  >these informational exchanges and are starting to use them more and
>  >more.
> 
> As far as I can tell, everyone is simply ignoring them (except for a couple of
> easy-to-understand cases);

As Andrew said, that's mostly because they were not well understood
and ambiguous to deploy. We've learned a lot and can actually now
specify better messages and semantics to go with them.

Just because the situation is currently bad means it's a bad mechanism.

jan



> and, the more complicated the protocol, the harder
> it is to figure out what the right response is to an error message. Again,
> not all notifications are bad, just that they are not as useful as people
> think (and that's IMOE).
> 
> Cheers,
> -Angelos
> 
> 

 --
Jan Vilhuber                                            vilhuber@cisco.com
Cisco Systems, San Jose                                     (408) 527-0847