[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: TOS copying considered harmful
Glen Zorn wrote:
> 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?
>
Of course it is, but my understanding is that low priority packets should be
thrown away at nodes enforcing the QoS, not at the IPSec gateways, which knows
nothing about QoS. If a packet arrives at the destination IPSec gateway, it
means that it did somehow conform to the QoS rules of the network is went
through.
A drop due to the IPSec anti-replay mechanism just makes quality of service even
lower for these packets, though it is not its original purpose...
Hope this makes sense...
>
> > 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
> >
> >
> >
> >
--
Olivier Kreet Alcatel (ESD/SME)
tel: +33 (0)3 90 67 68 52 1, rte du Dr Schweitzer
fax: +33 (0)3 90 67 77 93 67408 Illkirch cedex
email: olivier.kreet@sxb.bsf.alcatel.fr France
References: