[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: using por numbers in selectors
>>>>> "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
I think keeping 'enough of the decapsulated packets' would prove too
much of a strain on a security gateway. We keep the details of first-frags,
but nothing more.
Here's the approach we take:
H1---SG1---SG2---H2
Packet from H1 to H2.
If packet arrives at SG1 unfragmented, we calculate if IPSEC encapsulation
will cause fragmentation (ESP frags say), and if the 'don't frag' flag is
set, report back to H1 to trim it back. We still send the packet (ESP
frags).
Hopefully, for co-operating Hosts, this can prevent packet frags from the
SGs.
If the ESP packet is fragmented on the way to SG2, we reassemble, and live
with it (don't process ICMP from joe random nodes in the Internet).
If SG1 gets a fragment, from H1, SG1 had better see the 'first-frag-first'
(FFF),
or we will silently discard it, and the packet it then doomed. If we do get
the FFF, then we keep the first-frag details in a cache and check subsequent
frags against it. At SG2, after decapsulation, we had better get the FFF,
or the
packet is doomed. All in all, the packet stands a good chance of being
doomed!
The fix is to chuck those systems that are not supporting MTU discovery I
guess.
This is still going to be a problem with certain UDP tools that will need to
be
hand-trimmed.
One thought that came to mind while I was thinking about this: At the
moment,
we have no way to 'mend' ESP packets getting fragmented by the Internet. We
can't
process ICMP from some random router, and we have no ready-made way for the
remote, reassembling SG, to notify the sending SG that it had to reassemble.
It feels like we would do with a 'maintenance' SA between SGs so that they
communicate information like this. This could be a transport-mode SA I
guess.
This would reduce the need for SG to cope with having to reassemble every
ESP
packet before processing.
Another fix would be to build and Internet PKI, issue all routers in the
Internet
boundary with certificates from that PKI, and then install signer
certificates in
all SG such that they could be IPSEC-engaged to any router wishing to
express
important ICMP information. Too hard/dangerous.
Steve.