Re: revised IPsec processing model: Q: VID and forwarding function

[Stephen Kent <kent@bbn.com>]

At 9:09 -0700 7/19/03, Ricky Charlet wrote:
>Hello,
>
>	I'm trying to understand the motivations for VIDs and 
>explicit forwarding function separation. Currently, I am guessing 
>(based on your first paragraph) that these new features enable 
>PPVPNs and/or overlay networks. If so, how so? If not, what new 
>functionality is enabled by these features?

There was a long series of off-list and post-WG meetings discussions 
involving folks had expressed concern over how to modify IPsec 
processing to better accommodate PPVPNs and overlay nets. The grouops 
included  Mark Duffy, Greg Lebovitz, and Joe Touch I developed this 
model and vetted it with this group some months ago.  You are right, 
of course, that we need to explain how the use of a VID and a 
forwarding function helps in these circumstances. Let me try to 
provide a top level explanation.

PPVPNs and overlay nets use virtual interfaces in hosts or in network 
aggregation devices as part of creating virtual nets out of virtual 
links. So I think it's natural to introduce VIDs as a way to refer to 
these interfaces, at least within IPsec. I was told that it is 
necessary to allow for a full packet lookup in selecting the VID, 
hence the description of that lookup function. There was a desire to 
use the VID to select the appropriate SPD, to preserve the 
SPD-per-interface model that we already had, and which seems to be 
useful in some number of contexts.  The model in 2401 was ambiguous 
about whether one performed a forwarding lookup before or after SPD 
selection, which was not good for a standard. I'll defer to the folks 
mentioned above to add their own views about the ways and extent to 
which this model satisfies their basic requirements.

>	This one is an editorial quesiton: I wonder about a 
>particular phrase in the paragraph which begins "- virtual 
>interface:" There is a clause which says "or one virtual interface 
>may map to multiple virtual interfaces.". I suppose from the 
>intended parallelism of the sentence that it perhaps should have 
>read "or one virtual interface may map to multiple physical 
>interfaces."

Whoops! I did mean to say one virtual interface may map to multiple 
physical interfaces.  Sorry for the typo.


>	Also, the last paragraph implies a loop behavior for IPsec processing:
>   1. consult forwarding function to get VID
>   2. do IPsec processing as per VIDs SPD
>   3. go to 1.

I added the last paragraph to try to accommodate folks who do want to 
loop through IPsec more than once, something I personally have 
assurance concerns about. But, you are right that the description was 
too vague, and needs an exit condition. I was assuming that when a 
packet had completed the IPsec crypto processing, that the VID would 
be used to lookup an entry in another table, different from the one 
used to make the packet->VID assignment. This table would direct the 
packet to the right virtual interface, based on the VID carried 
through the IPsec processing. This last forwarding function could 
cause a loop for additional processing, or could cause the packet to 
exit the device. I assumed that it is the responsibility of the local 
admin to ensure that the table does not result in a non-terminating 
loop. As I noted, there is no way in IKE to negotiate the management 
of this table, to cause multiple passes through IPsec processing, 
which is one reason I am not excited about the option. However, 
manual configuration could be used.

Note that after a packet passes through IPsec (not bypass traffic), 
it will be changed, and so it is easy to imagine that a different VID 
will be returned the second time through, if there is any loop. For 
example, the next protocol field would be AH or ESP, not TCP or UPD.

>	The exit condition for this loop is not specified. Let's 
>consider outbound processing for an example. If the forwarding 
>function is aware of only routing information (i.e. it is separated 
>from security policy decisions) then it seems to me that this loop 
>will get stuck:
>   1. forwarding function says exit VID is X
>   2. spd says this packet is allowed to pass
>   3. go to 1.
>
>	Certainly as implementors, we could all thing of our own 
>little ways to break this loop. But shouldn't we have uniform 
>guidance?

My observation is that step 3 above is not what would necessarily 
happen, because a separate forwarding function should be used after 
IPsec processing.

Steve