Tero, regarding "If you don't know how to handle fragmented IKE payloads then your implementation is broken and it should be fixed."
The case isn't that we don't know how to handle them - its that fragmented packets are less reliable across the Internet, so we would really like to avoid them. It's such an issue that at least the Windows TCP stacks always enable the DF bit for PTMU detection.
The three problems I've seen in end-to-end IPSec are:
1. router/gw/fw filtering that don't handle fragments well (even core LAN routers due to bugs in OS version that took a long time track down)
2. flow-based QOS not having port info and
3. fragments can timeout in the reassembly queue when the receiver is really busy.
In almost all IKE implementations there is no path MTU discovery, and no way to reduce the size of the UDP payload because you can't interoperable send payloads in different exchanges. So I would always expect fragmentation when you exchange certs, PKCS #7 chains, CRLs in-band & CRPs for real PKI systems.
It does strike me that primarily UDP based services usually do define a TCP option to ensure traffic can get through reliably - e.g. DNS, Kerberos, LDAP. I wasn't around during the UDP or TCP debate, so I don't know why TCP 500 wasn't also an option to handle retransmissions, avoid fragmentation, do keep-alives, backoff, DOS prevention, etc. Do you remember ?
I see it is already reserved...
isakmp 500/tcp isakmp
isakmp 500/udp isakmp
-----Original Message-----
From: Tero Kivinen [mailto:kivinen@ssh.fi]
Sent: Tuesday, September 26, 2000 7:51 PM
To: Brian Swander
Cc: William Dixon; kaijun gu; Scott Fanning; IPsec List
Subject: RE: CERT_REQ_PAYLOAD usage
Brian Swander writes:
> Unless I'm missing something, it seems pretty hacky to send multiple end
> entity cert chains. Say my peer sends me 3 CRPs for different roots,
> root A,B,C. I have 3 cert chains that chain to these roots. Chain1:
> A0,A1,A Chain2: B0,B1,B2,B Chain3: C0,C1,C where A0, B0, and C0 are
> the end entity certs.
>
> Say I send all of these certs in random order (A0,B1,A1,B0,C0 etc).
> Now, the peer has to pick out the chains, and piece them back together.
Yes. So what? If you are using real certificate manager that takes
care of that that is not an issue. As the IKE is currently defined you
have to do that anyways.
> Worse yet, I also have to send 3 sig payloads since in general A0,B0 and
> C0 will all have different private keys. There is no way in IKE to map
No. If those certificates does not share the private key then you only
send ONE chain. If they all share private key then you can send
multiple chains. You SHOULD NOT send multiple certificates matching
your ID payload that have different private key. You MAY send multiple
certificates matching your ID payload if they have same private key.
> the chain to the sig payload, so IKE has to guess what the chains are,
> guess what the end entity certs are, and go with trial and error to find
> the correct sig payloads.
Or you could simple find out all certificates matching the ID payload
and try to verify the signature with all of them. This might also be
the case when you have overlapping validity periods while you get a
new certificate to replace old one.
The other end might already have your old certificate in its
certificate cache, and you are using the new certificate when you
create the SIG, thus the other end might end up checking the signature
with wrong public key.
> Thus, sending a single chain and a single sig payload seem to me to be
> the only reasonable alternative. Of course, if we mandated that people
> sent an individual chain as its own PKCS7 and that all end entity certs
> MUST have the basic constraint saying that they are end entity, and
> defined some way in IKE to map PKCS blobs to sig payloads (maybe with
> mandatory payload ordering), then perhaps we could build an
> interoperable way to send multiple chains. But as William points out,
> we'd still have the problem of fragmented IKE payloads.
What is the problem with fragmented IKE payloads? You have to be able
to process them anyways, as there might be some ppp lines that has MTU
of 128 bytes between you and the other end. If you don't know how to
handle fragmented IKE payloads then your implementation is broken and
it should be fixed.
--
kivinen@ssh.fi Work : +358 303 9870
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/