[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 2401bis issues (possible) resolution



At 15:27 -0700 10/13/03, Joe Touch wrote:
>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.

For IPsec we define hosts are ultimate source and sinks of packets, 
which is not quite the same. Security gateways are intermediary 
devices, typically fronting for a set of hosts on a LAN or enterprise 
net.  A bump in the wire (BITW) is a self-contained implementation, 
typically serving one device (host or router) located on an interface 
between that device and a network. the bump in the stack (BITS) 
implementation option is a retrofit approach to adding IPsec to a 
host, where the OS does not offer IPsec natively.

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

OK.

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

Your indented text matches my intent.  I'll leave it to the list to 
decide whether the transport mode support ought to be a MUST, a MAY, 
or a SHOULD.

Steve