RE: Moving PIC forwards

["William Dixon" <wdixon@xxxxxxxxxxxxxxxxxxxxx>]

Maybe I'm just rehashing my earlier points, but it seems some folks
aren't convinced about fragments being a problem.

Let me first say a new thought: TCP may allow the PIC exchange to be
more easily proxied, which means VPN client installation could be done,
and PIC to get or renew the cert, from just about anywhere.

The fragmentation problems I've seen result from passing certs in IKE,
thus 3-4kbyte PKCS#7 blobs.  These blobs contain the end-entity cert and
the intermediate CA certs, possibly including the root cert. Yes,
customers probably will use your dedicate VPN PKI if you make them and
make it easy by integrating it into the VPN box.  But the customers I've
talked to don't want to deploy a separate PKI for VPN if they already
have one.  If PKI is done for a large enterprise, then they have a root
and at least 2 intermediate CAs.  Outsourcing PKI often means at least 1
or 2 intermediate CAs under a public PKI provider root, and access
policy to trust just the issuer CA or intermediate CA, not trusting all
certs from the public root.  Yes, IKE can pass just the end-entity cert.
But actually PIC must pass the whole chain and possibly the private
root, so when the gateway passes the end-entity cert, it can be
verified.

So yes, fragmentation is a serious issue, even more serious for PIC than
for IKE.  My IKE deployment experience shows that in some way, some how,
excessive fragments (like 4-5 fragments) will cause problems for clients
connecting at some point in time.  

:Begin Story:
Most recently I saw 3 weeks of time spent finding a "braindead" switch
that dropped the 4th fragment out of 5, usually but not always.  IKE
retransmissions half of the time got the full ID exchange through, but
retrans on both sides were required.  The switch was sitting in a data
center somewhere so it took quite a long time to locate, monitor, and
repeat the test.  Different owners of network equipment under different
orgs, scheduling tests, bypassing the suspected device during the test
while it was fully loaded, finally replacing/upgrading the equipment,
etc.  Lots of email, status reports, tracking and eliminating all the
possible problems.  So sure, that's one braindead switch, but one switch
that affected half of the customer's VPN traffic, due to the way it was
routed in from the Internet.  They spent a month or so just hoping it
would go away, dealing with the intermittent delay and loss of
connectivity behavior, because clearly some clients had no problems and
some did.  They could not group the clients and understand why some did
and didn't until they investigated traceroutes from 10-20 clients once
the client part of the investigation got under way.  They didn't
immediately or even later, suspect it was their own switch in their own
data center.

It was unclear when investigating the problem whether it's a faulty
switch, or a packet filter that doesn't track fragments.  Filtering is
very common at network boundaries.  Ultimately every owner of every box
in the path needed to be contacted and the configuration examined to
determine what should have been passing through. All we knew from the
start was the sniffs from the client showing fragments  sent, and from
the gateway, showing that they weren't making it.  Thankfully return
traffic from the gateway was routed along the same path as incoming
traffic.
:End Story:

You might say this is a mute issue since PICs purpose is to provision
IKE which might see the same fragmentation when it uses the cert, and
along the same path.

But I'd expect PIC will be re-purposed as a general secure encapsulation
of cert request and response, which means that PIC won't necessarily go
to the VPN gateway, it will go to the 3rd party Internet issuing CA, or
the customer's issuing CA internally or their VPN provider's issuing CA
on the Internet, along a much different path that the IKE negotiation to
the IPSec GW.  Certainly these non-VPN device Internet CAs would support
TCP, and the client would support TCP.  Other TCP based security
protocols like SSL use certificates.  802.1x wireless authentication
uses certificates. And EAP-TLS uses client certificates for Win2k's PPP
dial, PPTP and L2TP user authentication.  And of course PIC might even
be useful for enrolling for a cert for S/MIME.

Bernard already mentioned the perf impact of tracking fragments on
border router filters.

So if you can avoid fragmentation by allowing PIC over TCP, please do,
OR, define a multiple payload continue method that IKE might even adopt
:-)  I think TCP is imminently more deployable.

I guess the only thing I haven't rehashed from my last post was that PIC
protocol extensions really must be provided for, like additional
authentication data, and NAT traversal and DOS prevention. 

Wm

-----Original Message-----
From: Yaron Sheffer [mailto:yaronf@xxxxxxx] 
Sent: Wednesday, October 31, 2001 3:36 PM
To: Markus Stenberg; ietf-ipsra@xxxxxxxx
Subject: 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*
authentication methods...

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
mechanism.

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
collocated.

Thanks,
	Yaron
-----Original Message-----
From: owner-ietf-ipsra@xxxxxxxxxxxxx
[mailto:owner-ietf-ipsra@xxxxxxxxxxxxx]On Behalf Of Markus Stenberg
Sent: Wednesday, October 31, 2001 7:15 PM
To: ietf-ipsra@xxxxxxxx
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 packets.

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 cluebrick.

 - 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 there.

(and to be politically correct, no offense, for the humor impaired that
happen to have/work on firewall which is broken)

-Markus