Subject: RE: Moving PIC forwards

From: "William Dixon" <[email-masked]>
Date: Fri, 9 Nov 2001 00:37:24 -0800

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:[email-masked]] 
Sent: Wednesday, October 31, 2001 3:36 PM
To: Markus Stenberg; [email-masked]
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: [email-masked]
[mailto:[email-masked]]On Behalf Of Markus Stenberg
Sent: Wednesday, October 31, 2001 7:15 PM
To: [email-masked]
Subject: Re: Moving PIC forwards

[email-masked] (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

---

From: "Yaron Sheffer" <[email-masked]>
Date: Fri, 9 Nov 2001 11:13:11 +0200

Hi William,

fragmentation is obviously a serious issue. However, I'm worried that moving
PIC to TCP could mean the death of this protocol, at least in the VPN space.
Hardware VPN vendors don't trust TCP, because of the amount of state
involved and the associated DOS exposure. And until PIC is "re-purposed",
this is an important deployment segment.

An admittedly ugly way around this issue is to make *both* UDP and TCP MUST
on the client, and only UDP MUST on the server, with TCP being SHOULD or
MAY. This would add complexity to the implementation and probably to
configuration, too.

Regarding your other points: PIC is extensible in the legacy authentication
space, using EAP extensions. PIC has its own extension mechanisms for
additional credential and credential request types. PIC does mention the
issue of NAT, anticipating the solution that will probably be adopted by IKE
(i.e. to float the port, the rest of the IKE NAT issues don't exist in PIC).

On DOS prevention: if you guys want another round just to verify routability
of the initiator, fine. I hope Paul is right and we can get by without a
second WG last call.

Paul, once this issue is resolved we will publish a new version, hopefully
in the next week, and certainly before Nov. 21.

Thanks,
	Yaron

-----Original Message-----
From: William Dixon [mailto:[email-masked]]
Sent: Friday, November 09, 2001 10:37 AM
To: Yaron Sheffer; Markus Stenberg; [email-masked]
Subject: RE: Moving PIC forwards

:Begin Story:

Wm

-----Original Message-----
From: Yaron Sheffer [mailto:[email-masked]]
Sent: Wednesday, October 31, 2001 3:36 PM
To: Markus Stenberg; [email-masked]
Subject: RE: Moving PIC forwards

Thanks,
	Yaron
-----Original Message-----

-Markus

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 9 Nov 2001 06:56:27 -0800 (PST)

> this is an important deployment segment.

OK. So what about a "cert continuation" payload? I'd note that PIC already
supports multiple round-trips, and EAP methods can already support such
continuations (see RFC 2716).

---

From: "Scott G. Kelly" <[email-masked]>
Date: Fri, 09 Nov 2001 07:37:26 -0800

I agree with both points below. I think UDP should be a MUST, implying
that we need a cert continuation mechanism of some sort. I also think we
should make TCP a MAY, and reserve a port for it.

Scott

---

From: Jari Arkko <[email-masked]>
Date: Mon, 12 Nov 2001 12:23:23 +0200

Sounds good!

---

From: "Yaron Sheffer" <[email-masked]>
Date: Fri, 16 Nov 2001 21:26:05 +0200

In a previous mail replying to William I mentioned that PIC can be extended
via the use of additional payload types. However PIC is layered on top of
ISAKMP, and at least my reading of ISAKMP is that if an unknown payload is
received, the entire message is discarded - you don't just "silently ignore"
the payload. Quoting from ISAKMP:

"[Under "Payload Processing":] Check the Next Payload field to confirm it is
valid.  If the Next Payload field validation fails, the message is discarded
and the following actions are taken..."

This obviously makes it hard to use new payload types to extend PIC, in
particular for the first message, before a Vendor ID payload can be sent.

Am I misreading ISAKMP? Are real-life IKE implementations different? Please
enlighten me.

Thanks,
	Yaron
-----Original Message-----
[mailto:[email-masked]]On Behalf Of William Dixon

[Long discussion deleted]

Wm

---

From: "Andrew Krywaniuk" <[email-masked]>
Date: Wed, 21 Nov 2001 14:46:35 -0500

I think most people will abort the negotiation if they receive an unknown
payload type. This caused a problem for some implementers when the vendor id
payload was added. But without a critical bit, how do you know if it is safe
to ignore them?

However, most people decided not to reject unknown attribute types in an SA
proposal that they don't accept. It seemed the sensible thing to do, since
the inclusion of alternate proposals implies that the attibute is not
critical.

Andrew
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.

> [mailto:[email-masked]]On Behalf Of Yaron Sheffer
> Sent: Friday, November 16, 2001 2:26 PM
> To: William Dixon; Markus Stenberg; [email-masked]