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

["Michael C. Cambria" <mcc@fid4.com>]

Stephen Kent wrote:
> 
> At 9:09 -0700 7/19/03, Ricky Charlet wrote:

[deleted]

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

This text change could be read to rule out the possibility of a virtual
interface mapping to another virtual interface (e.g. overlay on an
overlay)?  Is this the goal?

> >       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'm confused by what you say above.  To me the exit of the loop was
clear.  Your reference to looking up an entry in _another_ table is what
I don't understand.

For tunnel mode, after Step 3, there will be an new IP header.  This
header is used in Step 1 to obtain a new VID.  

This VID will either have IPsec enabled or not.  If not, IPsec is done,
loop exited.  If IPsec is enabled, the new IP header must match an entry
in this VID's SPD.  The matching entry will either drop, bypass or apply
IPsec.  For drop or bypass the loop ends.  For apply, we do loop again,
but at some point, we hit a VID that has a bypass policy or that doesn't
have IPsec enabled at all.

Where would the other table you refer to exist?

Thanks,
MikeC