Mark Duffy wrote: > Consider a hypothetical device that has 2 conventional interfaces and also > implements an overlay network using IPsec to implement a single virtual > interface. The device does not have any IPsec policy (SPD) active on the > conventional interfaces (all packets are "pass"). A forwarding decision > (e.g. L3 routing) is made in the overlay context to send a particular > packet out via the virtual interface. The SPD associated with the virtual > interface is consulted and it contains a single entry with wildcard > selectors (match all packets) that says apply tunnel mode IPsec to all > packets and send them to remote peer p1 (addressed in the non-overlay > space). An SA is negotiated using IKE, if it does not already exists. The > packet is encapsulated in a tunnel mode IPsec packet whose destination > address is p1. That packet is then processed as a "new" packet by the L3 > forwarding in the non-overlay context. L3 forwarding selects one of the > conventional interfaces as the exit interface and the packet is sent. In this example the "interface" is a do-nothing pseudo construct that serves no other purpose than holding a tunnel mode SA (see section 3.2 of our ID for a discussion). This approach requires a different pseudo interface for each SA, and each SA associated with such an interface MUST be tunnel mode. Network interfaces are characterized by the encapsulation the perform (e.g. Ethernet, etc.) The pseudo interface you propose does not perform such on operation by itself, but depends on IPsec to perform the required encapsulation, and only functions correctly when restrictions on the contents of its SA are enforced. This seems awfully complicated. Also note that the destinction between tunnel mode and transport mode begins to dissappear, since you tunnel mode SAs MUST be associated with non-encapsulating pseudo-interfaces, while transport mode SA MUST be associated with regular interfaces. Encapsulation is a function of the interface, not one of IPsec. Lars -- Lars Eggert <larse@isi.edu> Information Sciences Institute http://www.isi.edu/larse/ University of Southern California
S/MIME Cryptographic Signature