RE: SOI QUESTION: 3.1 DoS protection

["Hallam-Baker, Phillip" <pbaker@verisign.com>]

> Basically, with avoiding sending large stuff like certificates
> until the cookie has been returned, it allows a fairly simple way that
> implementations can be organized in order to avoid attackers swamping
> memory with needing-to-be-reassembled packets.

The protocol should provide the option of referencing the
key authentication data independently of the key exchange.

Moving certificates in-band is sometimes necessary but it
should not be the default, particularly if you want to use
UDP as a transport.

In most VPN examples the IPSEC gateway can either be 
pre-populated with certificates or obtain them from a 
certificate location service (directory or XKMS).

In XML Signature we developed the KeyInfo structure to
serve as a very flexible structure that would allow any 
key authentication mechanism to be referenced.


Exchanging certificate chains is very limiting, it requires
the client to anticipate the roots of trust of the server.
I can't see how PGP could be used in that circumstance and 
it would be very painful to try to use X.509 cross-certificates.

In XML Signature the KeyInfo can specify a URL that
provides a retrieval location for the key authentication info.

This could be profitably adapted to IPSEC with a couple of 
tweaks to make very sure we stay within our UDP packet size
'budget'.

The retreival method structure would have 3 fields as follows:

1) LOCATOR  	URL of the key authentication information
2) KEY_DIGEST	One way function of the key parameter values
3) TYPE		One way function of the KeyInfo URL that
			specifies the type of key information

I am attempting to save IANA cycles here by re-using the 
existing W3C registry of KeyInfo parameter types.

The Key_DIGEST may well be unnecessary, however some folk
may prefer to be able to instantly verify that the info
they get from the location service is that intended by
the presenting party (avoid certain DoS modes).

A typical locator URL should take up no more then 64 bytes.
e.g. http://certs.company.test/cert/q2502qawoiu20a9350w9==

If this was a real squeeze compression could be added.

So the total locator package would be only 
64 + 20 + 20 + packing = 110 bytes total


Once again certs inband have their place, however they should
not be the only mechanism.

IKEv2 is a good opportunity to take advantage of progress in
the PKI space.

I believe that the larger requirement that IKEv2 should address
is filling in the gaps that have led to IPSEC being limited
to stovepipe VPN deployment.

I think the time has come to set out a comprehensive statement
on how an Internet wide IPSEC deployment could be achieved.
I believe that certificates are likely to have a role in such
a deployment, however we should also anticipate that DNSSEC and
XKMS would play substantial roles as well.

		Phill