[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: using por numbers in selectors
Paul Koning wrote:
>
> >>>>> "Dan" == Dan Harkins <dharkins@network-alchemy.com> writes:
>
> Dan> For gateways, yes. If you've negotiated port/protocol
> Dan> granulatity for an IPSec SA and a packet gets fragmented prior
> Dan> to being IPSec protected then the other end will have to queue
> Dan> up enough of the decapsulated fragments to get the port/protocol
> Dan> and decide whether to forward it on to the ultimate end-system.
>
> It may not be able to do that, for example if the first fragment went
> a different route. Also, the problem applies equally well to end
> systems if using tunnel mode, since the (inner) reassembly occurs
> after the IPSEC processing.
>
> paul
Howdy ()
There is no workaround. Administrators must choose between filtering on
ports AND knowing that their fragments MUST pass through the same SGW or
not filtering on ports and not sweating which path a fragment takes.
We implementors also have an interoperability issue to solve, should we
force intermediate reassembly (in order to look at ports) on the ingress
or egress end of the tunnel (or both)? An inplementor who choses to
force re-assembly on the egress end or both ends of the tunnel would not
have concerns about interoperability. But it seems MUCH easier to me to
do the intermediate reassembly on the ingress end of the tunnel and in
my wonderful imaginary world, we could all agree to do it this way.
What do you all think?
--
####################################
# Ricky Charlet
# (510) 795-6903
# rcharlet@redcreek.com
####################################
end Howdy;
Follow-Ups:
References: