[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: TOS copying considered harmful
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. 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
Follow-Ups:
References: