Re: revised IPsec processing model

[Joe Touch <touch@ISI.EDU>]

Stephen Kent wrote:

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

Having just participated in one such meeting in the U.K., at least one 
major vendor is prescribing our model as a preferred solution.

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

I certainly appreciate, as you have observed, that our perspective is 
end-system based. You have also noted:

> ...I am not knowledgeable enough about the details of host
 > implementations to have provided an answer like this.

It would be useful at least if this proposal could be vetted with a 
working implementation on both a router and an end host before being 
considered as such a major modification to the architecture.

-----------

One other question:

What happens to packets when the IPsec-time forwarding lookup differs 
from the forwarding that actually happens when the packet would be emitted?

I.e., it seems possible that if I had weak or no encryption on one link, 
that it might be possible to leak such packets out onto a link that I 
needed strong protection on. If this is not the case, a specific example 
would help.

Joe