[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: TOS copying considered harmful
Jun-ichiro itojun Hagino wrote:
> >> 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 see. RFC2402 mandates 32bit bitmap, and recommends 64bit bitmap.
> - is 64bit not enough for normal nodes?
> - if larger window size helps, how big do you suggest?
> - if not, what other mechanism do you suggest?
>
> itojun
I admit I did not test and I'm not aware of any study done on the window size vs packet
loss due to reordering. On the theorical point of view, the problem will still be there
whatever the size of the window, but yes, probably hidden by a large enough window size.
The best thing would probably be to have one tunnel per class of service, but it is not
always possible to set up parallel tunnels on today's IPSec implementations (e.g. linux
Freeswan).
Follow-Ups:
References: