In response to some of the list of issues and questions raised at the IBM VPN interoperability workshop:
> 9. Should the order of protocols dictate the order of security
> association or should AH, ESP, IPComp always be processed in a
> certain order? Most vendors agreed with the latter
If we consider that a fixed order is assumed, and that we will never support ESP and ESP, there are only 4 kinds of bundles possible: IPCOMP+ESP, IPCOMP+AH, ESP+AH, and IPCOMP+ESP+AH.
We should conceptually think of bundles as a single SA that provides multiple services. This means that all three services expire at the same time and are re-keyed at the same time. Further, when being negotiated, they all functionally use the same encapsulation (even though implementations may consider the outer headers as always being in transport mode). This means that a gateway always offers tunnel mode for all three services, since the bundle as a whole is in tunnel mode.
Therefore, for the current version version of IPSec, make the following statements:
1) The order of application of services, from inner header to outer, MUST be IPCOMP, ESP and AH when more than one service is present.
2) The encapsulation mode of all services offered MUST match that encapsulation mode of the bundle as a whole.
3) The order of the services in the ANDed offer is not required to be any particular order. Responders may change the order when selecting the bundle.
4) The entire bundle expires when any one of the services within the bundle expires.
For IPSecond:
In order to reduce any ambiguity of implementation, I would suggest that we consider picturing these four combinations as their own protocols, with a single header that contains only the necessary information: 1 SPI, one sequence number, one next header field and one payload length field, each formatted based on the services it provides.
A closer examination suggests that this 'super' header could be identical to the AH protocol header, since it already is a superset of the header information of all other headers.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Payload Len | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Authentication Data (variable, 0 for IPCOMP+ESP) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The advantages of the use of this header are:
1) reduced ambiguity about application and negotiation of services.
2) reduced network bandwidth.
3) possible reduction in packet servicing time.
All that remains is the specification of how authentication services are negotiated if ESP with authentication is allowed when used with AH. And it's pretty easy to argue that this could be disallowed.
> 12. Does ESP-NULL require padding (the ESP doc says 4-byte alignment,
> ESP-NULL doc says 1-byte alignment). The consensus was that ESP is
> 4-byte aligned.
There is no ambiguity. ESP in general requires 4 byte padding or a multiple of 4. ESP-NULL has a block length of 1. Since the padding used for a particular combination of ESP and an encryption algorithm is the lowest common multiple of 4 (from ESP) and the block length of the cipher, the result is that ESP with the NULL cipher uses a padding of 4 (or 8, or 12, ...)
An example given at the workshop was for a cipher of block length 6. This would result in padding of 12 (or 24, or 36, ... ) bytes.
> 16. If an initiator requests an SA with only a single IP address as
> the destination, but the responder has a local policy of a subnet
> (instead of a single IP address), should it fail the negotiation?
> Some vendors were doing this.
Yes, it should fail. Because then the initiator could then request another SA for the next IP address in the range the responder wanted to use in the first place. And then the next one. So you end up with a whole bunch of SAs that you don't need, and you may end up with a management issue that you didn't want. If your system is configured for a subnet, than that's probably what the administrator wants.
> 25. Someone pointed out that the ID payload is redundant if we are
> doing RSA_SIG authentication, since the certificate already has the
> identity.
I wouldn't necessarily agree with this. The certificate may contain alternate names, of which the one used in phase 1 negotiation should be one, yes? The name used in phase 1 negotiation is for policy, meaning what the person is allowed to do. The certificate is used for authentication, meaning: is the person really the person they say they are?
---
Tim Jenkins TimeStep Corporation
tjenkins@timestep.com http://www.timestep.com
(613) 599-3610 x4304 Fax: (613) 599-3617