> >In BITW scenarios with SPDs that use port selectors this issue comes up,
>as it does in one side of SG/VPN scenarios, right?
It used to be the case that transport mode was restricted to end
systems, but due to popular demand we have removed that restriction.
so, this used to be just a tunnel mode issue for SG scenarios, but it
might arise for transport mode too,under our new paradigm.
I thought that SGs were allowed to use transport mode for administrative
traffic where the SG is an end-point. Is this a misunderstanding of the
new paradigm? If not then no issue here.
> analysis is correct, based on dropping non-initial fragments. one
also has to deal with housekeeping issues, e.g., timing out fragment
IDs, to prevent possible mismatches, and one needs to specify the
How bad would mismatches be? They may get protected with an incorrect
SA, but the receiver should be the same either way (if not, that would
be a bigger deal) and should then simply drop them since they wouldn't
match a correct first fragment (and if they did the result would, in all
likelyhood, not match various checksums and the like, leading to the
full packet being dropped which, again, would be within spec).
> receiver-side algorithm too, e.g., remembering packet IDs for initial
fragments so that the later fragments are treated as acceptable. but,
is this easier than what Charlie Lynn described?
I'd have to re-read that. In any case, the receiver already has to
track packet IDs for reassembly,
so now all it has to do in addition is
track the SA that was used to protect each fragment and drop any
fragments that don't use an acceptable SA. Unlike an SG, the receiver
here probably wouldn't want to drop non-initial fragments received
before their intial counterparts, if it can avoid it, and should have
the necessary buffer space, usually, so the receiver here can behave as
Tero proposed -- it does not seem like this would impose much of a
burden on the receiver.