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

[Stephen Kent <kent@bbn.com>]

At 13:14 -0400 7/22/03, Michael C. Cambria wrote:
>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?

that was not my intent. so yes, the entry in the table could be for a
virtual interface, or for a physical interface.

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

I did not intend that one looped back to step 1 after applying the 
new header. Also, in transport mode the header may differ only in the 
value of the next protocol field. So, yes, one could loop back to 
step 1, OR one could perform another lookup which might have the same 
effect as goig to step 1 or might use a different table entirely.

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

There has been no discussion of a virtual interface having IPsec 
enabled or not. Rather the SPD for a VID has entries that specify 
what to do with all traffic, which would translate into the 
equivalent statement ONLY for some possible configurations of an SPD. 
remember, an SPD has entries that cover ALL possible traffic, not 
just traffic to which IPsec is applied.

Steve