Subject: Re: Moving PIC forwards

From: "Steven M. Bellovin" <[email-masked]>
Date: Wed, 31 Oct 2001 08:45:39 -0500

In message <[email-masked]>, Jari Arkko writes:

>Besides, for the problem to occur you must have
>a firewalling router between the businessman's
>PC and the corporate PIC node /VPN gateway. How
>likely is that? Network operators hopefully shouldn't
>be filtering your traffic, so that leaves the
>corporate network border routers possibly in front
>of the PIC/VPN nodes. If they can't handle fragmented
>UDP packets, the network manager can upgrade the
>routers at the same time he installs PIC. Or?
>

One cause of the fragmentation problem is PPPoE.  You may not like 
PPPoE (I certainly don't), but there's a lot of it out there on DSL 
lines.

None of which, of course, says that we need to break our protocol to 
deal with it.  But v6 doesn't even have router-based fragmentation, so 
we may want to plan ahead.  Do we want to go as far as to recommend 
intentional fragmentation at some rational threshhold?

		--Steve Bellovin, http://www.research.att.com/~smb
		Full text of "Firewalls" book now at http://www.wilyhacker.com

---

From: Jari Arkko <[email-masked]>
Date: Wed, 31 Oct 2001 16:08:55 +0200

>One cause of the fragmentation problem is PPPoE.
>...
>But v6 doesn't even have router-based fragmentation, so 
>we may want to plan ahead
>...

Fragmentation as such isn't sufficient to cause a
problem. You also need a firewalling router or
something like that to drop all fragments packets,
because they weren't programmed to deal with
that. IPv6 still allows up to 2^16 (or even 2^32)
bytes long UDP packets. The place of the fragmentation
is different, though, it's e2e.

But let's turn back to Bernard's original problem.
He said "I'd like the protocol to run over TCP, so
that we can handle large certificate payloads without
fragmentation. In practice, fragmentation of
IKE cert payloads has turned out to be a headache..."

So, let's assume our setup is (a) PIC to node 1 in
a corporate network followed by (b) IKE+IPSEC
to a node 2 in a corporate network. PIC has long
payloads, and so does IKE where certs are used.
Then we also assume there's a broken router somewhere
that doesn't do fragment filtering correctly. So,
what would be the effect of providing improved
TCP PIC? Step a could then be accomplished, but
no communication could be established because
Step b would break at the router.

In conclusion, it seems that TCP PIC isn't useful
until IKE runs over TCP too. In the mean time
we have to ensure our routers and firewalls
do the right thing. TCP PIC doesn't help.  But,
Bernard, is the problem the same in PIC as it is
in IKE cert payloads, or is it bigger? If we rarely
hit the problem in IKE but would hit it all the time
in PIC, then it might make sense think more about it.

Jari

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 31 Oct 2001 06:35:47 -0800 (PST)

> PPPoE (I certainly don't), but there's a lot of it out there on DSL 

From what I've seen, the issue is due to large cert payloads, so that the
fragmentation occurs at the endpoint, not in the middle of the network. 

> intentional fragmentation at some rational threshhold?

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.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 31 Oct 2001 06:40:09 -0800 (PST)

> in PIC, then it might make sense think more about it.

It depends on how big the cert payloads are. The particular circumstances
I've seen occur with certificate chains. You are correct that IKE will
also fragment -- but often the IKE negotiation will occur on a specialized
VPN box that can can include the right fragment filtering functionality,
whereas the PIC node seems more likely to be a host that will need a
filtering router in front of it.

---

From: Markus Stenberg <[email-masked]>
Date: 31 Oct 2001 19:15:18 +0200

> "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 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: Bernard Aboba <[email-masked]>
Date: Wed, 31 Oct 2001 10:18:29 -0800 (PST)

>  won't even go to.. nor user configuration :P)

Going to minimum MTU all the time is not a good strategy, I'd agree. Not
sure that PMTU discovery would be so bad though -- could be made fairly
simple. For example, set the DF bit, and if fragmentation is encountered
move down in large increments. In any of these cases, you'd need the
"continuation" capability, though.  

> much, but my cert chains have been mostly on short side.

The problem is very common among organizations that have deployed
LDAP-based directories. 

IT organizations often have sophisticated directory structures, and the
chain of trust is reflective of their organizational hierarchy. So the
Swedish branch office would be under Europe, which is part of Products
Group, which is within the Automotive Division, and this results in a long
cert chain. 

>  compatible' term to differentiate between broken and working firewalls.

Not easy to do when *most* existing routers do not support fragment
filtering very well. Remember, fragments don't necessary have a
header/port present, so you have keep state in order to handle this
correctly. 

> and others (like us, it seems) are mostly concerned in getting SOMETHING
> working by kludging around existing crap out there.

Yup. Have been working on IPsec since 1996 now, and am still struggling to
get a wide spread cert-based deployment going. At this point, believe it
or not, the IKE fragmentation issue is probably a bigger headache than
getting the PKI infrastructure up, and even deploying smartcards and
directories.

---

From: "Scott Fanning" <[email-masked]>
Date: Wed, 31 Oct 2001 13:04:05 -0800

Just another data point. I have seen some fragmentation issues even with
large (4k) key sizes. I agree that this is a real issue.

Scott

---

From: "Yaron Sheffer" <[email-masked]>
Date: Thu, 1 Nov 2001 01:35:56 +0200

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

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

-Markus