[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Moving PIC forwards
Actually, "kludging around existing crap" is very much in line with what
we've been doing. After all, the whole point of IPSRA is to use *legacy*
More to the point, a bare-bones PIC exchange is 2 RTT. For example, if
you're only doing a simple challenge-response. Adding the DOS prevention
round bring us to 3 RTT. While a TCP implementation adds 2 RTT for
connection setup, bringing the number to 4 - TCP takes care of ensuring the
originating address can be routed to, and you don't need a dedicated
An advantage of TCP is the well defined retry mechanism, compared with the
fuzzy definition in ISAKMP (Sec. 5.1 of the RFC has some minimal details.
The rest is left to your imagination.)
A disadvantage is the complexity of dealing with TCP disconnects. But in our
case we can simply drop the whole exchange.
DOS-resistance is more of an issue. Nobody is going to implement a
DOS-resistant TCP package on their hardware VPN, just to accommodate PIC.
It all boils down to whether we expect separate PIC and IKE endpoints (in
which case IKE/UDP with PIC/TCP make sense) or we expect them to be
[mailto:owner-ietf-ipsra@xxxxxxxxxxxxx]On Behalf Of Markus Stenberg
Sent: Wednesday, October 31, 2001 7:15 PM
Subject: Re: Moving PIC forwards
aboba@xxxxxxxxxxxxx (Bernard Aboba) writes:
> The fragmentation I've observed is already intentional. If people aren't
> up for TCP, then another alternative would be support of a
> "continuation" mechanism to spread the cert payload across multiple UDP
What MTU should we use then? 576? Doesn't this triple+ number of packets in
normal case and it'd happen only thanks to braindead routers?
[ one can argue that 1500-byte packets are de facto, but one can also argue
that <some poor fellow out there> is using ADSL+PPPoE with low MTU.. ]
(Secondary alternative, own PMTU-detection scheme by trial-and-error, I
won't even go to.. nor user configuration :P)
Is the problem _really_ out there? I personally haven't encountered it
much, but my cert chains have been mostly on short side.
- If the problem is broken configuration of a firewall (i.e. I know of
firewalls that have been configured with insanely low number of fragments
to keep / time to keep them), then it can be amended (hopefully) by
- If it's matter of product, we should just embrace some form of 'IPsec
compatible' term to differentiate between broken and working firewalls.
Admittedly, I know firsthand the pain of "we do not want to change <X>" in
organizations, but still, I find it interesting that some parties in IETF
push for weird (and of course useful) stuff like IPv6 which requires total
change of hardware et al, and others (like us, it seems) are mostly
concerned in getting SOMETHING working by kludging around existing crap out
(and to be politically correct, no offense, for the humor impaired that
happen to have/work on firewall which is broken)