RE: TOS copying considered harmful

["Glen Zorn" <gwz@xxxxxxxxx>]

Olivier Kreet [mailto://olivier.kreet@sxb.bsf.alcatel.fr] writes:

> Jun-ichiro itojun Hagino wrote:
>
> > >As stated in the first post of this discussion thread, besides
> security reasons,
> > >clearing the TOS field may also be required when QoS is to be
> applied on the path
> > >of the tunnel. The packet reordering may cause the anti-replay
> mechanism to
> > >reject low prio packets that were (strongly) delayed  due to QoS. See
> > >draft-ietf-diffserv-tunnels-02.txt, section 5.1.
> > >This is related to ESP and AH sequence numbers, that are
> specific to IPSec and
> > >not an IP in IP encapsulation problem. This point should go to
> RFC2401, right?
> >
> >         I don't understand the last sentence.  why sequence
> numbers are the
> >         issue?  they are defined per SA (= unique to src, and normally
> >         identifies single dst), and should not matter even if
> we add a tunnel
> >         encapsulation.  could you tell us more?
>
> The anti-replay mechanism is based on these sequence numbers.
> Replayed packets but
> also packets arriving on the left of the sliding window used to
> implement this
> mechanism are thrown away. If the TOS is copied from inner to
> outer header and you
> have different classes of service inside a single tunnel (a
> single SA), then you are
> subject to packet reordering if some nodes on the tunnel path do
> QoS based on the tos
> (or dscp). At a certain level of reordering, low prio packets
> will arrive too late at
> dst, i.e. on the left of the window and be deleted. This is not
> expected.

Please forgive my ignorance, but I don't quite understand the last sentence.
Ignoring the presence of both IPSec and the tunnel, isn't the occasional
dropping of low priority packets exactly what one would expect on an
under-provisioned network using QOS?

> Once again,
> this is discussed in the draft I mentionned above.
>
>
> >         I personally still believe that we should separately
> define tunnelling
> >         separately from IPsec itself (like RFC182x did), but
> given the way IKE
> >         is defined today and is used to negotiate IPsec
> tunnels, i think it's
> >         too late.
> >
> > itojun
>
>
>
>