Re: 2401bis issues (possible) resolution

[Joe Touch <touch@ISI.EDU>]

Stephen Kent wrote:

> Joe,
> 
> You are right that 2401 makes a clear distinction between SG and host 
> implementations in terms of required mode to be supported.  However it 
> is not appropriate to require that an SG must also act like an IPsec host.
> 
> We distinguish 4 types of IPsec implementation contexts: SG, BITW, BITS, 
> and native host.  the latter is special for several reasons, e.g.,  in 
> that context it is reasonable to have access to the name of the target 
> for an IPsec SA, as expressed by a user, whereas all other 
> implementations can expect to have access only to addresses.  As a 
> result, the form of SPD entries that a host must support is broader than 
> the form that an SG (or BITS/BITW) must support. So, if only for that 
> reason, it would not be appropriate to make a broad assertion that SGs 
> must also support the functions of an IPsec host.

We define a host as a source or sink of packets. Other aspects - packet 
handling, etc., follow from this simple definition. This definition is 
certainly more terse than, e.g., sec 1.1.1 of RFC1122, but seems to be 
consistent as far as we have been able to discern.

We're not sure whether this defintion affects the need for other aspects 
of IPsec 'host' support. That support may not be needed for gateway 
'source or sink' services - e.g., mobile IP, multicast tunnels, GRE 
tunnels, IPIP tunnels, etc. But it would be needed if the gateway runs 
any IPsec transport-mode secured services that make it look like a 
traditional host (e.g., SNMP) But that's a completely different issue, 
one that the document is already sufficiently clear on.

> What we proposed to say is something like SGs MAY support transport 
> mode, and MUST support tunnel mode, which would support the IP-in-IP or 
> GRE tunneling over transport mode SAs, as well as 2401's mandated tunnel 
> mode use.

The commas in this are ambiguous. Is the following consistent with what 
you mean?

	SGs MAY support transport mode, and MUST support tunnel mode.
	Transport mode would support IP-in-IP or GRE tunneling
	over transport mode SAs.

Given that IP-in-IP is proposed standard and is used both for mobile IP 
and multicast, we still feel a SG MUST (or at least SHOULD) implement 
transport mode, though we appreciate that it might not be a full 'host' 
in other respects.

Joe