Re: revised IPsec processing model

[Stephen Kent <kent@bbn.com>]

At 13:36 -0700 8/4/03, Joe Touch wrote:
>Hi, all,
>
>Stephen Kent wrote:
>>Mark,
>>
>>responses inline to your comments:
>>
>>     <SNIP>
>>
>>>Regarding the virtual interface and the forwarding function:
>>>
>>>A close reading shows that the "forwarding function" may be an 
>>>arbitrary function of the packet (and hopefully of 
>>>meta-information about the packet, such as where it was received 
>>>from).  However, the term itself is fairly loaded and will suggest 
>>>destination-address-based IP forwarding to many readers. 
>>>Moreover, 2401bis should IMO permit a separation between where a 
>>>packet is forwarded to, and what SPD is applied to it.  This for 
>>>example to support a device that has one uplink to the Internet 
>>>and provides protection for different LANs using different SPDs: 
>>>in this case the SPD to use for outbound processing might be 
>>>implied by the interface the packet came in on rather than by the 
>>>interface it goes out on.
>>
>>The intent is that the forwarding function can use any data from 
>>the packet. I'm open to suggestions for other names for the 
>>function, but I think Joe Touch suggested this one, and he 
>>definitely intended it to cover the broader set of possible inputs.
>
>FYI, we call it forwarding since it would do what IP forwarding 
>does. However, note that IP forwarding, as we have pointed out 
>before, involves more than finding the outgoing interface.
>
>Consider a system:
>
>                 c
>               /
>	a----b
>               \
>                 d
>
>Where a packet comes from 'a' and goes many hops downstream of 'c' 
>or 'd', where c,d are the nexthops from b. It is possible that c and 
>d are on the same LAN as b, e.g., an FDDI ring or ethernet switch at 
>a POP.
>
>In that case, regardless of whether c or d is chosen, the packet 
>will have the same outgoing interface. Outgoing interface alone will 
>be insufficient to support dynamic routing.
>
>As we have observed before, IP forwarding specifies both the 
>outgoing interface and the next-hop IP address; both are required to 
>specify the appropriate database.
>
>However, as our ID points out, this is a cumbersome solution 
>compared to the alternatives.

Joe,

Cumbersome is in the eye of the beholder :-).

The other folks who participated in the discussions, who are vendors, 
did not seem to agree with the overlay net model you & Lars proposed. 
Also, that model seems narrowly focused on end system, vs. SG or 
BITW, implementations.  It is preferable to have a simple model that 
is generally applicable, and that's what we have strived to achieve.

Steve