Subject: revised IPsec processing model

From: Stephen Kent <[email-masked]>
Date: Thu, 17 Jul 2003 14:48:15 -0400

Folks,

Here is the new, proposed processing model for IPsec.  Comments 
welcome, of course.

Steve

------

The current IPsec subscriber traffic processing model, as defined in 
2401, is imprecise in several respects, and it does not accommodate 
some significant deployment use that have arisen, e.g., PPVPNs. 
Also, just as we have created the extended sequence number facility 
for AH and ESP to accommodate high speed (10Gb/s and beyond) 
implementations, there are changes one can make to the processing 
model to better accommodate traffic classification (for outbound 
traffic).  Finally, there are some simplifications one can make to 
the mode, consistent with the overall push for implementation 
simplification.

We first look at outbound traffic, which is where most of the 
proposed changes are visible, then examine inbound traffic 
processing. The focus here is on subscriber traffic, with some 
discussion of IKE traffic.

Several concepts underlie the proposed model:

- virtual interface: every IPsec device has at least one virtual 
interface, which may correspond to one physical interface (the common 
case). Multiple virtual interfaces may map to a single physical 
interface, e.g., for overlay nets, or one virtual interface may map 
to multiple virtual interfaces. The choice of a one-to-one, 
many-to-one, or one-to-many mapping for virtual to physical 
interfaces is a local matter, which each implementer is free to 
select apropos to the environment on which IPsec is implemented. 
Every virtual interface has an ID (VID), a purely local identifier, 
which is used with the forwarding function defined below, to select 
the virtual interface to which outbound traffic is directed. The VID 
is NOT technically a selector, because it does not need to appear in 
an SPD; rather it is used to select an appropriate SPD.

- forwarding function: to provide a clear separation between 
forwarding (routing) and security decisions, an explicit forwarding 
function is added. This function can be trivial, in the case where 
there is only one interface (virtual or physical). It may be complex 
if there are multiple interfaces and if the implementation elects to 
offer a more sophisticated form of route selection. The spec makes no 
assumptions about the internal operation of the function, other than 
to say that the whole packet is passed to it and the output is a VID. 
In turn, the VID is used to select the appropriate SPD.

	- SPD: the SPD is largely the same as currently defined. 
Instead of being defined on a per interface basis, it is now per 
virtual interface, and is labeled with a VID, as specified above. The 
new SPD will differ in terms of the selectors allowed (consistent 
with IKEv2). Rather than referring to separate SPDs for inbound vs. 
outbound traffic (pre interface) we will talk in terms of entries in 
each SPD being directional, i.e., there are separate inbound and 
outbound entries for each SPD for each virtual interface. This makes 
sense because the inbound and outbound entries are really linked.

	- SPD caches: the current processing model refers to 
searching the SPD for each outbound packet to determine how to 
process it, and to check inbound traffic after IPsec processing, to 
ensure that traffic arriving on an SA is consistent with the 
selectors defined when the SA was created. This is a potentially time 
consuming search process, in both directions, because of the need to 
search the SPD entries in the order specified by the administrator or 
user who created them. The search process also is ambiguous as 
currently defined, with regard to processing inbound packets.  To 
simplify the process, and to allow for very fast SA lookups, we 
introduce the notion of an outbound SPD cache (on a per virtual 
interface basis), and the caching of inbound SPD entries in two 
places. Since SPD entries may overlap, one cannot safely cache these 
entries in general. Simple caching might result in a match against a 
cache entry whereas a search of the SPD would have resulted in a 
match against a different entry. But, if we decorrelate the SPD, then 
the resulting entries can safely be cached. For outbound traffic, 
each cached entry maps to an SA, or indicates that matching traffic 
should be bypassed or discarded. For inbound traffic, the SPD cache 
serves as the reference for the selectors to be matched against 
arriving packets, or defines traffic to be bypassed or discarded. An 
algorithm for decorrelation was published as an ID some time ago, and 
I think there is at least one paper on the topic published as well. 
2401bis will not mandate a specific algorithm, but will include an 
example in an appendix.

With these concepts in mind, we can describe the revised model. First 
we examine outbound traffic processing.  (There is no separate 
discussion of fragment processing for now, as we await the WG 
decisions of several pending proposals re fragmentation.)

1. when a packet arrives from a subscriber interface, invoke the 
forwarding lookup function.

2. match the packet headers against the SPD cache specified by the 
VID from step 1

3a. if there is a match, then process the packet as specified by the 
matching cache entry, i.e., bypass, discard, or apply AH or ESP in 
the specified mode. If IPsec processing is applied, there is a link 
from the SPD cache entry to the relevant SAD entry (specifying the 
algorithms, keys, SPI, etc.). IPsec processing is as previously 
defined, for tunnel or transport modes and for AH or ESP, as 
specified.

3b. if no match, search the SPD that corresponds to this cache. If 
the SPD calls for bypass or discard, create a new outbound and 
inbound cache entries. If the SPD entry calls for creation of an SA 
(pair), the key management mechanism (e.g., IKEv2) is invoked to 
create the SA. If SA creation succeeds, a new outbound cache entry is 
created, along with an SAD entry, otherwise the packet is discarded, 
and an error is logged, and may be signaled. (A packet that triggers 
an SPD lookup MAY be discarded by the implementation, or it may be 
buffered and then processed against the newly created cache entry, if 
one is created.) The SAD entry contains the inbound selector values 
linked to the SPD entry used to create the inbound SA, to support 
checking of received traffic.

4. The VID assigned to the packet in step 1 (the forwarding lookup) 
is used to select the interface to which the packet is directed, 
after the specified processing (if any) is applied in step 3.

Inbound processing is somewhat different from outbound processing, 
largely because we use of SPIs to map IPsec traffic to SAs, vs. 
performing a lookup based on traffic selector values. However, we 
still have to perform traffic selector lookups for non-IPsec inbound 
traffic, to determine whether this traffic is to be discarded or 
bypassed. Thus an inbound IPsec cache is used to quickly process this 
traffic. The description below does not include reassembly 
processing, while we await a WG decision on the possibility of 
rejecting fragments for SAs from specified sources.

1. When a packet arrives, it is tagged with a VID. This ID may be 
directly mapped from a physical interface, or a lookup function may 
be invoked to assign a VID, analogous to what is offered for outbound 
traffic in step 1 above. Note that there is no need to tag a packet 
with a VID if it is an IPsec packet directed to the IPsec 
implementation. This is because there is only one SAD which applies 
to all traffic, regardless of the interface. However, because SPDs 
are per-interface, entries for bypass or discard traffic might be 
specific to the interface via which the inbound traffic is received. 
If there is no need to treat inbound traffic differently depending on 
the interface upon which it arrived, the VID may be a constant.

2. examine the header to determine if it is addressed to the IPsec 
implementations, and if so, if it appears to be for a key management 
protocol. If so, direct the packet to key management processing.

3a. If the packet is addressed to the IPsec implementation and AH or 
ESP is specified as the protocol, lookup the packet using the SPI in 
the SAD. Remember that each SAD entry now includes 2-bits to specify 
which fields are used to determine a match (unicast vs. multicast). 
If there is no match, discard the traffic, logging the error as 
specified by local management controls. If there is a match in the 
SAD, apply AH or ESP as specified, using the SAD entry selected 
above. Then match the packet against the inbound selectors in the SAD 
entry, to verify that the received packet is appropriate for the SA 
via which it was received. If there is a mismatch, log the error and 
signal it if a signaling mechamism is available and enabled.

3b. If the packet is not addressed to the implementation, or if the 
traffic is not AH or ESP, lookup the packet header in the inbound 
(discard/bypass) SPD cache for this (virtual) interface. If there is 
a match and the packet is to be discarded or bypassed, do so. If 
there is no match, lookup the packet in the inbound SPD (for the 
interface in question) and create an appropriate inbound and an 
outbound cache entry. (No SAs are created in response to receipt of a 
packet that requires IPsec; only bypass or discard entries can be 
created this way.)

This processing model is simpler and less vague than the old model, 
and it offers the potential for higher speed processing of traffic. 
It does, however, remove some functionality.  For example, there is 
no provision for SA bundles. It would be easy to include support for 
the simple AH+ESP combination that IKEv1 was able to negotiate, and 
that 2401 mandates, if that combination is still viewed as needed. 
However, IKEv1 was not able to negotiate any other nested protocol 
combinations and I don't think IKEv2 has addressed this problem 
either, especially the notion of adding new SAs to create an SA 
"bundle." So, I suggest we remove the requirement to support SA 
bundles, unless the WG feels strongly otherwise.

There is also no provision within this processing model to support 
nested SAs, i.e., all IPsec processing is performed in one pass. 
However, after the packet is emitted, it could be redirected through 
the IPsec module via local, virtual interfaces and use of the 
forwarding lookup function, to cause more than one layer of IPsec 
headers to be applied or removed. Note that to accomplish this, 
multiple entries would have to be created, in distinct SPDs, each 
specifying a layer of IPsec processing to be applied. However, IKE 
still lacks a means to negotiate this, so I suspect that only manual 
configuration, or some key management mechanism not yet defined for 
IPsec, would be needed to take advantage of this approach.

---

From: [email-masked]
Date: Fri, 18 Jul 2003 13:57:58 +0900

>Here is the new, proposed processing model for IPsec.  Comments 

	the text is a bit unclear whether it is talking about transport mode
	or tunnel mode.

	"virtual interface" is for tunnel mode only, am i right?  if so,
	you can now remove tunnel mode from FFC2401 - there are bunch of
	tunnel specification available (like RFC2893, RFC1853, RFC2003)
	and tunnel mode will be replaced by "transport mode + tunnelling".
	i love to see the change.

	if "virtual interface" is used also for transport mode, it will be
	incompatible with IPv6 linklocal address (by changing inbound interface
	for a packet, i.e.  m->m_pkthdr.rcvif in BSD, you change the scope
	zone).  therefore i object to apply "virtual interface" concept
	to transport mode.

itojun

---

From: Stephen Kent <[email-masked]>
Date: Fri, 18 Jul 2003 03:28:12 -0400

>	zone).  therefore i object to apply "virtual interface" concept

There is no plan to remove tunnel mode from the spec. The plan was to 
apply this model for both transport and tunnle modes.

Steve

---

From: [email-masked]
Date: Fri, 18 Jul 2003 16:35:37 +0900

>apply this model for both transport and tunnle modes.

	in that case, i would like to express concern w/ IPv6 linklocal address
	(the latter paragraph of mine).

itjoun

---

From: Mark Baugher <[email-masked]>
Date: Fri, 18 Jul 2003 07:43:30 -0700

>apply this model for both transport and tunnle modes.

As recommended by Ferguson and Schneier?

Mark

---

From: Stephen Kent <[email-masked]>
Date: Fri, 18 Jul 2003 18:01:34 -0400

At 7:43 -0700 7/18/03, Mark Baugher wrote:
>>There is no plan to remove tunnel mode from the spec. The plan was 
>>to apply this model for both transport and tunnle modes.
>

If I understand your question, the answer is no. Long ago this WG 
decided that the paper you cite had several errors, probably a result 
of the authors not being protocol experts.  their critique of IKE v1 
was much more credible than the corresponding comments re ESP and AH. 
The list discussed the possibility of simplifying IPsec by dropping 
either tunnel or transport mode, and there was some support for that 
notion, but the support was divided between those who wanted to drop 
tunnel mode, and those who wanted to drop transport mode.  so, unless 
directed by the WG chairs, we plan to continue support for both modes.

However, consistent with the introduction of the forwarding function 
and virtual interfaces, and with the growing practice of using IPsec 
as a lower layer 3 security protocol (vs. upper layer 3, where IP 
lives), we do intened to relax the restriction on when to use 
transport mode, along with appropriate warnings.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 18 Jul 2003 18:01:34 -0400

>	(the latter paragraph of mine).

Could you elaborate a bit more on the nature of the problem? Your 
paragraph above was not enough for me, since I don't understand what 
IPv6 does in this regard absent Ipsec.  Also, in which of the IPv6 
specs is the behavior you are describing defined?

Thanks,

Steve

---

From: [email-masked]
Date: Sat, 19 Jul 2003 19:59:27 +0900

>specs is the behavior you are describing defined?

	RFC2460/2373.  draft-ietf-ipv6-scoping-arch-00.txt will also give you
	more information.

	with IPv6, there are not-universally-unique address defined in RFC2373.
	one of them is link-local address (the other one, site-local address,
	is going away so i will omit site-local from the discussion).
	link-local address range is fe80::/10, and address under it is unique
	on a certain link only.  for instance, the following situation is
	legal:

	fe80::1
	  |
	==+===== ether segment1
	  |
	your machine
	  |
	==+===== ether segment2
	  |
	fe80::1

	i.e. you are seeing the same address (fe80::1) on the different link
	your machine is attached to.  to disambiguate these machines, socket
	API (RFC2553) has additional field, sin6_scope_id, in sockaddr_in6.
	specifying 128bit address (fe80::1) is not enough, you have to specify
	which link you are talking about (textual notation is
	"fe80::1%segment1").

	now, many implementations use interface to identify link.  BSD-based
	implementation normally disambiguates incoming packet by
	m->m_pkthdr.rcvif.

	by introducing "virtual interface" and switching m->m_pkthdr.rcvif
	based on the virtual interface, you will become unable to identify
	peer correctly - after IPsec processing, both "fe80::1%segment1" and
	"fe80::1%segment2" would become "fe80::1%ipsec".  providing 1-by-1
	mapping between virtual interface and real interface does not provide
	a solution, since you will now see non-IPsec traffic as sent from
	"fe80::1%segment1" and IPsec traffic as sent from "fe80::1%ipsec1",
	and upper layer will get confused.

itojun

---

From: Bill Sommerfeld <[email-masked]>
Date: Sat, 19 Jul 2003 11:22:55 -0400

> 	and upper layer will get confused.

Maybe we just need a name other than "virtual interface" for the ipsec
entity.

I understood the proposal as for a new kind of entity, the
"2401-bis-ipsec-virtual-interface" which is different from the
"real" interface as seen by IP.

If you needed to record the 2401-bis-vif in packet metadata in
addition to the physical interface, you'd put it in a parallel field
to the BSD/KAME m->m_pkthdr.rcvif.

					- Bill

---

From: Ricky Charlet <[email-masked]>
Date: Sat, 19 Jul 2003 09:09:42 -0700

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?

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

	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.

	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?

---
Ricky Charlet
[email-masked]
510.324.3163

On Thursday, July 17, 2003, at 11:48 AM, Stephen Kent wrote:

> some significant deployment use that have arisen, e.g., PPVPNs. Also, 
> just as we have created the extended sequence number facility for AH 
> and ESP to accommodate high speed (10Gb/s and beyond) implementations, 
> there are changes one can make to the processing model to better 
> accommodate traffic classification (for outbound traffic).  Finally, 
> there are some simplifications one can make to the mode, consistent 
> with the overall push for implementation simplification.
>
> We first look at outbound traffic, which is where most of the proposed 
> changes are visible, then examine inbound traffic processing. The 
> focus here is on subscriber traffic, with some discussion of IKE 
> traffic.
>
> interface, e.g., for overlay nets, or one virtual interface may map to 
> multiple virtual interfaces. The choice of a one-to-one, many-to-one, 
> or one-to-many mapping for virtual to physical interfaces is a local 
> matter, which each implementer is free to select apropos to the 
> environment on which IPsec is implemented. Every virtual interface has 
> an ID (VID), a purely local identifier, which is used with the 
> forwarding function defined below, to select the virtual interface to 
> which outbound traffic is directed. The VID is NOT technically a 
> selector, because it does not need to appear in an SPD; rather it is 
> used to select an appropriate SPD.
>
> 	- SPD: the SPD is largely the same as currently defined. Instead of 
> being defined on a per interface basis, it is now per virtual 
> interface, and is labeled with a VID, as specified above. The new SPD 
> will differ in terms of the selectors allowed (consistent with IKEv2). 
> Rather than referring to separate SPDs for inbound vs. outbound 
> traffic (pre interface) we will talk in terms of entries in each SPD 
> being directional, i.e., there are separate inbound and outbound 
> entries for each SPD for each virtual interface. This makes sense 
> because the inbound and outbound entries are really linked.
>
> 	- SPD caches: the current processing model refers to searching the 
> SPD for each outbound packet to determine how to process it, and to 
> check inbound traffic after IPsec processing, to ensure that traffic 
> arriving on an SA is consistent with the selectors defined when the SA 
> was created. This is a potentially time consuming search process, in 
> both directions, because of the need to search the SPD entries in the 
> order specified by the administrator or user who created them. The 
> search process also is ambiguous as currently defined, with regard to 
> processing inbound packets.  To simplify the process, and to allow for 
> very fast SA lookups, we introduce the notion of an outbound SPD cache 
> (on a per virtual interface basis), and the caching of inbound SPD 
> entries in two places. Since SPD entries may overlap, one cannot 
> safely cache these entries in general. Simple caching might result in 
> a match against a cache entry whereas a search of the SPD would have 
> resulted in a match against a different entry. But, if we decorrelate 
> the SPD, then the resulting entries can safely be cached. For outbound 
> traffic, each cached entry maps to an SA, or indicates that matching 
> traffic should be bypassed or discarded. For inbound traffic, the SPD 
> cache serves as the reference for the selectors to be matched against 
> 2. match the packet headers against the SPD cache specified by the VID 
> from step 1
>
> matching cache entry, i.e., bypass, discard, or apply AH or ESP in the 
> specified mode. If IPsec processing is applied, there is a link from 
> the SPD cache entry to the relevant SAD entry (specifying the 
> defined, for tunnel or transport modes and for AH or ESP, as > specified.
>
> 3b. if no match, search the SPD that corresponds to this cache. If the 
> SPD calls for bypass or discard, create a new outbound and inbound 
> cache entries. If the SPD entry calls for creation of an SA (pair), 
> the key management mechanism (e.g., IKEv2) is invoked to create the 
> SA. If SA creation succeeds, a new outbound cache entry is created, 
> along with an SAD entry, otherwise the packet is discarded, and an 
> error is logged, and may be signaled. (A packet that triggers an SPD 
> lookup MAY be discarded by the implementation, or it may be buffered 
> and then processed against the newly created cache entry, if one is 
> created.) The SAD entry contains the inbound selector values linked to 
> the SPD entry used to create the inbound SA, to support checking of 
> received traffic.
>
> 4. The VID assigned to the packet in step 1 (the forwarding lookup) is 
> used to select the interface to which the packet is directed, after 
> the specified processing (if any) is applied in step 3.
>
> traffic. The description below does not include reassembly processing, 
> while we await a WG decision on the possibility of rejecting fragments 
> for SAs from specified sources.
>
> directly mapped from a physical interface, or a lookup function may be 
> invoked to assign a VID, analogous to what is offered for outbound 
> implementation. This is because there is only one SAD which applies to 
> all traffic, regardless of the interface. However, because SPDs are 
> per-interface, entries for bypass or discard traffic might be specific 
> to the interface via which the inbound traffic is received. If there 
> is no need to treat inbound traffic differently depending on the 
> interface upon which it arrived, the VID may be a constant.
>
> which fields are used to determine a match (unicast vs. multicast). If 
> there is no match, discard the traffic, logging the error as specified 
> by local management controls. If there is a match in the SAD, apply AH 
> or ESP as specified, using the SAD entry selected above. Then match 
> the packet against the inbound selectors in the SAD entry, to verify 
> that the received packet is appropriate for the SA via which it was 
> received. If there is a mismatch, log the error and signal it if a 
> signaling mechamism is available and enabled.
>
> (discard/bypass) SPD cache for this (virtual) interface. If there is a 
> match and the packet is to be discarded or bypassed, do so. If there 
> is no match, lookup the packet in the inbound SPD (for the interface 
> in question) and create an appropriate inbound and an outbound cache 
> entry. (No SAs are created in response to receipt of a packet that 
> requires IPsec; only bypass or discard entries can be created this 
> way.)
>
> and it offers the potential for higher speed processing of traffic. It 
> does, however, remove some functionality.  For example, there is no 
> provision for SA bundles. It would be easy to include support for the 
> simple AH+ESP combination that IKEv1 was able to negotiate, and that 
> 2401 mandates, if that combination is still viewed as needed. However, 
> IKEv1 was not able to negotiate any other nested protocol combinations 
> and I don't think IKEv2 has addressed this problem either, especially 
> the notion of adding new SAs to create an SA "bundle." So, I suggest 
> we remove the requirement to support SA bundles, unless the WG feels 
> strongly otherwise.
>

---

From: Bill Sommerfeld <[email-masked]>
Date: Sat, 19 Jul 2003 12:30:22 -0400

> multiple physical interfaces."

That was my read of the sentance as well (actually I didn't even
notice the word substitution).  The case of single-vif to multiple
physical interfaces is interesting for simplifying management (i.e.,
when all interfaces really are connected to the "the same" net, or
when you have the traditional "red" vs "black" trusted vs untrusted
net but multiple links to one or both are present for any number of
reasons).

Note also that in the case of layer-2 multiplexing (vlans, atm virtual
circuits, etc.,), one layer's virtual interface is the next layer's
physical interface.

Perhaps we should use a term like "policy enforcement point" rather
than "virtual interface"?

					- Bill

---

From: Michael Richardson <[email-masked]>
Date: Fri, 18 Jul 2003 12:26:10 +0200

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "itojun" == itojun  <[email-masked]> writes:
    >>> incompatible with IPv6 linklocal address (by changing inbound
    >>> interface for a packet, i.e.  m->m_pkthdr.rcvif in BSD, you change
    >>> the scope zone).  therefore i object to apply "virtual interface"
    >>> concept to transport mode.

    >> apply this model for both transport and tunnle modes.

    itojun> in that case, i would like to express concern w/ IPv6 linklocal
    itojun> address (the latter paragraph of mine).

  There is a disconnect here.

  Having a "virtual interface" model, does not mean that you have to have
an actual virtual address. 

]                   At IETF57 in Wien, Austria                  |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] printk("Just another Debian GNU/Linux using, kernel hacking, security guy");[

---

From: Russ Housley <[email-masked]>
Date: Fri, 18 Jul 2003 11:29:49 -0400

Steve:

It looks good to me.

I do not know if this is draft text for 2401bis.  If it is, then I do have 
a concern about the use of terms like "IPsec packet" and "non-IPsec 
traffic."  In this discussion, on AH and ESP are considered.  IKE packets 
are not addressed at all in this discussion, and they are at a different 
layer.  I would like to avoid confusion by using "AH and ESP packets"  or 
"Layer 3 IPsec packets" to ensure that we are clear.

Russ

---

From: Markus Friedl <[email-masked]>
Date: Sat, 19 Jul 2003 16:25:05 +0200

> 	and upper layer will get confused.

I don't think the 'virtual interface' needs to replace the
m_pkthdr.rcvif.  The virtual interface can just be attached as some
kind of mbuf tag.

However, I don't see a difference between having the VID
as a special selectors in a single SPD and having mutiple SPDs
selected by VID.

-m

---

From: Francis Dupont <[email-masked]>
Date: Mon, 21 Jul 2003 16:40:49 +0200

In your previous mail you wrote:

=> some comments:

   interface, ...

=> with scoped addresses, all the physical interfaces must belong
to the same zone. In the case of link-local addresses, this means
there is a one-to-one built-in mapping between interfaces which
support link-local addresses (almost all in IPv6) and some kind of
virtual interfaces. BTW, this can answer to Itojun's concern.
   
   - forwarding function: to provide a clear separation between 
   forwarding (routing) and security decisions, ...

=> it is not clear whether the forwarding function applies only
to forwarded packets (i.e., packets forwarded by a router) or
this is only the "routing" part of the ip_output() procedure.

   
=> can you define what is a subscriber interface? I am afraid the
model applies only to routers, i.e., what to do with genuine traffic?

Thanks

[email-masked]

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 21 Jul 2003 10:33:52 -0400

> However, I don't see a difference between having the VID as a
> special selectors in a single SPD and having multiple SPDs selected
> by VID.

Indeed.  There's not a whole lot of difference in terms of end
result..

					- Bill

---

From: Stephen Kent <[email-masked]>
Date: Mon, 21 Jul 2003 12:04:39 -0400

>net but multiple links to one or both are present for any number of

Your text is an accurate reflection of the sort of notions that 
motivated the virtual/physical interface mapping I mentioned.

>than "virtual interface"?

I am not absolutely wedded to the term "virtual interface" but it is 
primarily a routing construct and so I hesitate to use the term you 
mention above.  I fear that "policy" is too generic a term these days 
to be a useful modifier anymore.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 21 Jul 2003 11:26:41 -0400

>as a special selectors in a single SPD and having mutiple SPDs

You are correct that one could choose to implement a single SPD in 
which the VID was another "selector." However, I avoided presenting 
this as the basic model for at least two reasons that I can recall 
now:

	- in 2401 we talked in terms of per interface SPDs, so it is 
more consistent with the old model to talk in terms of per-virtual 
interface SPDs

	- we have generally reserved the term "selector" for data 
items extracted from packet headers.  the VID is not part of a packet 
header.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 21 Jul 2003 11:27:51 -0400

>to the BSD/KAME m->m_pkthdr.rcvif.

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

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 21 Jul 2003 10:52:55 -0400

>	and upper layer will get confused.

Thanks for the additional info. As Bill & Markus pointed out, the VID 
is not the same as an address, in the sense discussed above. It is an 
identifier largely internal to IPsec. Does Bill's suggestion of how 
to accommodate the VID address your concerns?

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 21 Jul 2003 10:21:16 -0400

At 11:29 -0400 7/18/03, Russ Housley wrote:
>Steve:
>
>It looks good to me.
>
>I do not know if this is draft text for 2401bis.  If it is, then I 
>do have a concern about the use of terms like "IPsec packet" and 
>"non-IPsec traffic."  In this discussion, on AH and ESP are 
>considered.  IKE packets are not addressed at all in this 
>discussion, and they are at a different layer.  I would like to 
>avoid confusion by using "AH and ESP packets"  or "Layer 3 IPsec 
>packets" to ensure that we are clear.
>
>Russ

Russ,

yes, this is 2401bis candidate text. Good point re use of the phrase 
"IPsec traffic"  I will change it to "ESP/AH traffic" going forward.

Steve

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Tue, 22 Jul 2003 11:04:19 +0900

>to accommodate the VID address your concerns?

	i see, i guess we need to find some term other than "virtual interface".

	my another concern is that the text talks too much about implementation
	details - for instance, SPD cache implementation could vary by
	implementation to implementation.  with our implementation we cache
	SPD on connected tcp/udp control block (inpcb).
	maybe put less (but sufficient) text in 2401bis, and add VID and caching
	details as appendix?

itojun

---

From: Stephen Kent <[email-masked]>
Date: Mon, 21 Jul 2003 22:19:01 -0400

>	maybe put less (but sufficient) text in 2401bis, and add VID 

There is no need to focus on caching in a host, because you can use 
the tcp/udp blocks, as you note. But for BITS, BITW, and security 
gateways, caching is critical and thus requires discussion.  I will 
revise the text to make clear this distinction.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 21 Jul 2003 22:20:15 -0400

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.

>   2. do IPsec processing as per VIDs SPD

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

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 22 Jul 2003 06:46:38 -0400

> to be a useful modifier anymore.

"naming is hard".

In a fit of whimsy, I propose "IPsec tollbooth"

							- Bill

---

From: "Michael C. Cambria" <[email-masked]>
Date: Tue, 22 Jul 2003 13:14:13 -0400

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

[deleted]

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

> 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

---

From: Mark Duffy <[email-masked]>
Date: Thu, 24 Jul 2003 13:09:33 -0400

Hi Steve, and thank you.  I think this is a good direction to go in, though 
I think it should be taken a little further.  Comments embedded below.

Thanks, Mark

At 02:48 PM 7/17/2003 -0400, Stephen Kent wrote:
>Folks,
>
>Here is the new, proposed processing model for IPsec.  Comments welcome, 
>of course.
>
>Steve
>
>------
>
>The current IPsec subscriber traffic processing model, as defined in 2401, 
>is imprecise in several respects, and it does not accommodate some 
>significant deployment use that have arisen, e.g., PPVPNs. Also, just as 
>we have created the extended sequence number facility for AH and ESP to 
>accommodate high speed (10Gb/s and beyond) implementations, there are 
>changes one can make to the processing model to better accommodate traffic 
>classification (for outbound traffic).  Finally, there are some 
>simplifications one can make to the mode, consistent with the overall push 
>for implementation simplification.
>
>changes are visible, then examine inbound traffic processing. The focus 
>here is on subscriber traffic, with some discussion of IKE traffic.
>
>case). Multiple virtual interfaces may map to a single physical interface, 
>e.g., for overlay nets, or one virtual interface may map to multiple 
>virtual interfaces. The choice of a one-to-one, many-to-one, or 
>one-to-many mapping for virtual to physical interfaces is a local matter, 
>which each implementer is free to select apropos to the environment on 
>which IPsec is implemented. Every virtual interface has an ID (VID), a 
>purely local identifier, which is used with the forwarding function 
>defined below, to select the virtual interface to which outbound traffic 
>is directed. The VID is NOT technically a selector, because it does not 
>need to appear in an SPD; rather it is used to select an appropriate SPD.
>
>- forwarding function: to provide a clear separation between forwarding 
>(routing) and security decisions, an explicit forwarding function is 
>added. This function can be trivial, in the case where there is only one 
>interface (virtual or physical). It may be complex if there are multiple 
>interfaces and if the implementation elects to offer a more sophisticated 
>form of route selection. The spec makes no assumptions about the internal 
>operation of the function, other than to say that the whole packet is 
>passed to it and the output is a VID. In turn, the VID is used to select 
>the appropriate SPD.

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.

So I would propose that instead of a "forwarding function" we have a "SPD 
selection function" that is done on a per-packet basis.  Like the 
forwarding function described above this function is a local matter for the 
IPsec implementation.  It might be a mapping from interface to SPD (RFC2401 
model), or any other function of the packet fields and packet 
meta-information.  With this change the concept of virtual interface could 
be dropped entirely (my preference, since the SPDs would not necessarily 
correspond to the logical IP network interfaces that the term suggests to 
me) or the virtual interface could be considered as a highly abstract thing 
that is one-to-one with an SPD but has no particular relationship to where 
the packet is forwarded, making the VID into an "SPD identifier".

>         - SPD: the SPD is largely the same as currently defined. Instead 
> of being defined on a per interface basis, it is now per virtual 
> Rather than referring to separate SPDs for inbound vs. outbound traffic 
> (pre interface) we will talk in terms of entries in each SPD being 
> directional, i.e., there are separate inbound and outbound entries for 
> each SPD for each virtual interface. This makes sense because the inbound 
> and outbound entries are really linked.

Yes, that's great.  In fact, aren't the inbound and outbound entries 
actually constrained to be symmetrical reflections of one another, at least 
if IKE is to be used?

>         - SPD caches: the current processing model refers to searching 
> the SPD for each outbound packet to determine how to process it, and to 
> was created. This is a potentially time consuming search process, in both 
> directions, because of the need to search the SPD entries in the order 
> specified by the administrator or user who created them. The search 
> process also is ambiguous as currently defined, with regard to processing 
> inbound packets.  To simplify the process, and to allow for very fast SA 
> lookups, we introduce the notion of an outbound SPD cache (on a per 
> virtual interface basis), and the caching of inbound SPD entries in two 
> cache entry whereas a search of the SPD would have resulted in a match 
> against a different entry. But, if we decorrelate the SPD, then the 
> resulting entries can safely be cached. For outbound traffic, each cached 
> entry maps to an SA, or indicates that matching traffic should be 
> bypassed or discarded. For inbound traffic, the SPD cache serves as the 
> reference for the selectors to be matched against arriving packets, or 
> defines traffic to be bypassed or discarded. An algorithm for 
> decorrelation was published as an ID some time ago, and I think there is 
> at least one paper on the topic published as well. 2401bis will not 
> mandate a specific algorithm, but will include an example in an appendix.

The discussion of decorrelating the SPD, and maintaining a cache, seems a 
lot like implementation design.  I would introduce these in 2401bis only if 
it significantly simplifies the description of the required behavior (which 
it's not clear to me that it does here).

>With these concepts in mind, we can describe the revised model. First we 
>examine outbound traffic processing.  (There is no separate discussion of 
>fragment processing for now, as we await the WG decisions of several 
>pending proposals re fragmentation.)
>

Per my comment above, I would propose changing this to:

1. when a packet arrives at the IPsec implementation and it is determined 
that the packet is to be protected as an outbound packet, invoke the SPD 
selection function.

>specified mode. If IPsec processing is applied, there is a link from the 
>SPD cache entry to the relevant SAD entry (specifying the algorithms, 
>keys, SPI, etc.). IPsec processing is as previously defined, for tunnel or 
>transport modes and for AH or ESP, as specified.
>
>3b. if no match, search the SPD that corresponds to this cache. If the SPD 
>calls for bypass or discard, create a new outbound and inbound cache 
>entries. If the SPD entry calls for creation of an SA (pair), the key 
>management mechanism (e.g., IKEv2) is invoked to create the SA. If SA 
>creation succeeds, a new outbound

and inbound?

>  cache entry is created, along with an SAD entry, otherwise the packet is 
> discarded, and an error is logged, and may be signaled. (A packet that 
> triggers an SPD lookup MAY be discarded by the implementation, or it may 
> be buffered and then processed against the newly created cache entry, if 
>used to select the interface to which the packet is directed, after the 
>specified processing (if any) is applied in step 3.

I have 2 comments on that.
Per my first comment above, I believe the IP forwarding decision should be 
independent of the SPD selection decision.
Also, for packets that have IPsec applied, in tunnel mode, the IP 
destination address of the new packet may now be different.  It is my 
belief that an IPsec implementation that is also a router should at this 
point perform a new IP forwarding decision, based on the new address.

>Inbound processing is somewhat different from outbound processing, largely 
>because we use of SPIs to map IPsec traffic to SAs, vs. performing a 
>lookup based on traffic selector values. However, we still have to perform 
>traffic selector lookups for non-IPsec inbound traffic, to determine 
>whether this traffic is to be discarded or bypassed. Thus an inbound IPsec 
>cache is used to quickly process this traffic. The description below does 
>not include reassembly processing, while we await a WG decision on the 
>possibility of rejecting fragments for SAs from specified sources.
>
>1. When a packet arrives, it is tagged with a VID. This ID may be directly 
>mapped from a physical interface, or a lookup function may be invoked to 
>assign a VID, analogous to what is offered for outbound traffic in step 1 
>above.

Just as for outbound processing, I urge that the model here should have a 
SPD selection function that is a local matter and may or may not be based 
on arriving and/or departing interface.

>  Note that there is no need to tag a packet with a VID if it is an IPsec 
> packet directed to the IPsec implementation. This is because there is 
> only one SAD which applies to all traffic, regardless of the interface. 
> However, because SPDs are per-interface, entries for bypass or discard 
> traffic might be specific to the interface via which the inbound traffic 
> is received. If there is no need to treat inbound traffic differently 
> depending on the interface upon which it arrived, the VID may be a constant.
>
>3a. If the packet is addressed to the IPsec implementation and AH or ESP 
>is specified as the protocol, lookup the packet using the SPI in the SAD. 
>Remember that each SAD entry now includes 2-bits to specify which fields 
>are used to determine a match (unicast vs. multicast). If there is no 
>match, discard the traffic, logging the error as specified by local 
>management controls. If there is a match in the SAD, apply AH or ESP as 
>specified, using the SAD entry selected above. Then match the packet 
>against the inbound selectors in the SAD entry, to verify that the 
>received packet is appropriate for the SA via which it was received. If 
>there is a mismatch, log the error and signal it if a signaling mechamism 
>is available and enabled.
>
>match and the packet is to be discarded or bypassed, do so. If there is no 
>match, lookup the packet in the inbound SPD (for the interface in 
>question) and create an appropriate inbound and an outbound cache entry. 
>(No SAs are created in response to receipt of a packet that requires 
>IPsec; only bypass or discard entries can be created this way.)
>
>This processing model is simpler and less vague than the old model, and it 
>offers the potential for higher speed processing of traffic. It does, 
>however, remove some functionality.  For example, there is no provision 
>for SA bundles. It would be easy to include support for the simple AH+ESP 
>combination that IKEv1 was able to negotiate, and that 2401 mandates, if 
>that combination is still viewed as needed. However, IKEv1 was not able to 
>negotiate any other nested protocol combinations and I don't think IKEv2 
>has addressed this problem either, especially the notion of adding new SAs 
>to create an SA "bundle." So, I suggest we remove the requirement to 
>support SA bundles, unless the WG feels strongly otherwise.

You won't hear any complaints from me.

>There is also no provision within this processing model to support nested 
>SAs, i.e., all IPsec processing is performed in one pass. However, after 
>the packet is emitted, it could be redirected through the IPsec module via 
>local, virtual interfaces and use of the forwarding lookup function, to 
>cause more than one layer of IPsec headers to be applied or removed. Note 
>that to accomplish this, multiple entries would have to be created, in 
>distinct SPDs, each specifying a layer of IPsec processing to be applied. 
>However, IKE still lacks a means to negotiate this, so I suspect that only 
>manual configuration, or some key management mechanism not yet defined for 

I don't see why IKE as-is could not negotiate this, so long as it allows 
negotiating an SA to protect payload packets that are ESP or AH 
protocol.  It then becomes a local issue of what SPD(s) a packet is 
subjected to as it flows through the IPsec device, and any/all SAs needed 
would be independently negotiated.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 30 Jul 2003 13:15:09 -0400

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

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

>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

---

From: Stephen Kent <[email-masked]>
Date: Wed, 30 Jul 2003 15:33:06 -0400

Mark,

responses inline to your comments:

	<SNIP>

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

The question of one SPD, or an SPD per (virtual) interface is a 
separate matter.  Before introducing virtual interfaces in the 
processing model, we had one SPD per physical interface.  So, I just 
maintained this part of the model going forward, and doing what seems 
to be the obvious, logical extension. So, from a "preserve the status 
quo unless the WG expresses consensus otherwise ..." perspective, I 
will plan to retain the per-virtual interface SPD model for now.

>So I would propose that instead of a "forwarding function" we have a 
>"SPD selection function" that is done on a per-packet basis.  Like 
>the forwarding function described above this function is a local 
>matter for the IPsec implementation.  It might be a mapping from 
>interface to SPD (RFC2401 model), or any other function of the 
>packet fields and packet meta-information.  With this change the 
>concept of virtual interface could be dropped entirely (my 
>preference, since the SPDs would not necessarily correspond to the 
>logical IP network interfaces that the term suggests to me) or the 
>virtual interface could be considered as a highly abstract thing 
>that is one-to-one with an SPD but has no particular relationship to 
>where the packet is forwarded, making the VID into an "SPD 
>identifier".

I don't understand the reasoning here.  We have been told that it is 
inappropriate (unduly restrictive?) to have the SPD embody forwarding 
info, hence the introduction of the forwarding function and the 
embodying of its output in a VID value that can be used both for SPD 
selection and to carry forward with the packet to control where it 
goes after IPsec processing.

>>virtual interface, and is labeled with a VID, as specified above. 
>>The new SPD will differ in terms of the selectors allowed 
>>(consistent with IKEv2). Rather than referring to separate SPDs for 
>>inbound vs. outbound traffic (pre interface) we will talk in terms 
>>of entries in each SPD being directional, i.e., there are separate 
>>inbound and outbound entries for each SPD for each virtual 
>>interface. This makes sense because the inbound and outbound 
>>entries are really linked.
>
>actually constrained to be symmetrical reflections of one another, 
>at least if IKE is to be used?

The entries need not be symmetric in all cases, because SPD entries 
cover ALL traffic: IPsec, bypass, and discard.

>>	<SNIP>
>The discussion of decorrelating the SPD, and maintaining a cache, 
>seems a lot like implementation design.  I would introduce these in 
>2401bis only if it significantly simplifies the description of the 
>required behavior (which it's not clear to me that it does here).

How one performs decorrelation is an implementation detail, but I 
found that I needed to call out a cache explicitly to clarify how 
processing was done. And, we cannot cache entries unless we 
decorrelate them. That's why the description is stated in its current 
form.

>>With these concepts in mind, we can describe the revised model. 
>>First we examine outbound traffic processing.  (There is no 
>>separate discussion of fragment processing for now, as we await the 
>>WG decisions of several pending proposals re fragmentation.)
>>
>1. when a packet arrives at the IPsec implementation and it is 
>determined that the packet is to be protected as an outbound packet, 
>invoke the SPD selection function.

I am not comfortable with this, for several reasons. First, we 
disagree about the use of a function to select an SPD, vs. selecting 
an interface with an SPD.  Second, I found it too difficult to 
explain how to do the processing without introducing caches, 
especially for outbound traffic.

>>	<SNIP>
>>create the SA. If SA creation succeeds, a new outbound
>
>and inbound?

There is no inbound SPD cache for IPsec traffic. The SPD data in put 
in the SAD entry and inbound IPsec traffic is looked up in the SAD.

>Per my first comment above, I believe the IP forwarding decision 
>should be independent of the SPD selection decision.
>destination address of the new packet may now be different.  It is 
>my belief that an IPsec implementation that is also a router should 
>at this point perform a new IP forwarding decision, based on the new 
>address.

No to the first comment. yes to the second, which is why I amended 
the model, in response to other comments, to include a second lookup.

>>still have to perform traffic selector lookups for non-IPsec 
>>inbound traffic, to determine whether this traffic is to be 
>>discarded or bypassed. Thus an inbound IPsec cache is used to 
>>quickly process this traffic. The description below does not 
>>include reassembly processing, while we await a WG decision on the 
>>be invoked to assign a VID, analogous to what is offered for 
>>outbound traffic in step 1 above.
>
>Just as for outbound processing, I urge that the model here should 
>have a SPD selection function that is a local matter and may or may 
>not be based on arriving and/or departing interface.

See my responses to this issue above.

>>  Note that there is no need to tag a packet with a VID if it is an 
>>IPsec packet directed to the IPsec implementation. This is because 
>>there is only one SAD which applies to all traffic, regardless of 
>>the interface. However, because SPDs are per-interface, entries for 
>>bypass or discard traffic might be specific to the interface via 
>>which the inbound traffic is received. If there is no need to treat 
>>inbound traffic differently depending on the interface upon which 
>>it arrived, the VID may be a constant.

The VID may be a constant, and that trivial implementation of the 
lookup function is fine for an implementation that does not support 
multiple virtual interfaces.  There is no intent to mandate such 
support; rather the notion is that IF the device natively supports 
multiple virtual interfaces, THEN this is how IPsec will accommodate 
them.

>>However, after the packet is emitted, it could be redirected 
>>through the IPsec module via local, virtual interfaces and use of 
>>the forwarding lookup function, to cause more than one layer of 
>>IPsec headers to be applied or removed. Note that to accomplish 
>>this, multiple entries would have to be created, in distinct SPDs, 
>>each specifying a layer of IPsec processing to be applied. However, 
>>IKE still lacks a means to negotiate this, so I suspect that only 
>>manual configuration, or some key management mechanism not yet 
>>defined for IPsec, would be needed to take advantage of this 
>>approach.
>
>I don't see why IKE as-is could not negotiate this, so long as it 
>allows negotiating an SA to protect payload packets that are ESP or 
>AH protocol.  It then becomes a local issue of what SPD(s) a packet 
>is subjected to as it flows through the IPsec device, and any/all 
>SAs needed would be independently negotiated.

IKE, as-is, negotiates one pair of SAs at a time, and has not means 
to communicate the intent of one side to bind together different SAs 
negotiated independently, as best I know.  So, rather than saying 
that there might be some magic way to express this through SPD 
entries, I was suggesting that we cleanly abandon it if IKE cannot 
negotiate it. Otherwise we have so many ways to have things not work 
despite successful IKE-level negotiation ...

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 30 Jul 2003 17:11:35 -0400

>virtual interfaces. BTW, this can answer to Itojun's concern.

As I mentioned in my earlier messages, I don't understand the 
internals of an IPv6 host implementation well enough to appreciate 
these issues. I am assuming that the responses from other folks about 
how to interpret the VID concept in this context will suffice.

>this is only the "routing" part of the ip_output() procedure.

I do tend to think in terms of BITW/BITS and SG implementations of 
IPsec, so that prejudice may be showing here. The intent of the 
forwarding function, in a host environment and absent IPsec, would be 
to select the interface to which the packet would be forwarded. So, I 
think this maps to the "routing part ..." as you noted above.

>model applies only to routers, i.e., what to do with genuine traffic?

I was thinking in terms of the interface via which an outbound packet 
is initially received. so, in a host, this is the interface form 
which upper layer protocols present packets to the IP layer. In a SG, 
it the the interface hat connects to the network that we think of as 
being "behind" the security gateway.

Steve

---

From: Mark Duffy <[email-masked]>
Date: Thu, 31 Jul 2003 14:44:32 -0400

Thanks Steve.
I have a further comment on just two items, below.

--Mark

>>forwarding function described above this function is a local matter for 
>>the IPsec implementation.  It might be a mapping from interface to SPD 
>>(RFC2401 model), or any other function of the packet fields and packet 
>>meta-information.  With this change the concept of virtual interface 
>>could be dropped entirely (my preference, since the SPDs would not 
>>necessarily correspond to the logical IP network interfaces that the term 
>>suggests to me) or the virtual interface could be considered as a highly 
>>abstract thing that is one-to-one with an SPD but has no particular 
>>relationship to where the packet is forwarded, making the VID into an 
>>"SPD identifier".
>
>info, hence the introduction of the forwarding function and the embodying 
>of its output in a VID value that can be used both for SPD selection and 
>to carry forward with the packet to control where it goes after IPsec 
>processing.

It is the "used both for..." part of that that I am resisting.

My opinion is that the proposed forwarding function and virtual interface 
concepts are helpful, but do not go far enough in generalizing the IPsec 
model.  What I would hope to see 2401bis embrace is a model where packets 
enter an IPsec device, some device-specific logic selects an SPD to apply, 
and then the IPsec and bypassed packets are forwarded out an interface 
chosen by some separate device-specific logic, for example IP longest 
matching prefix forwarding.

Let me give an example of a hypothetical yet reasonable device that is not 
readily accomodated by the 2401bis model as proposed.  Suppose we have a 
security gateway sort of device that has 3 LAN interfaces that it is 
protecting i.e. "protected networks" and 2 WAN interfaces to the Internet 
i.e. "uplinks."  Plaintext packets are sent and received on the protected 
network interfaces, and a mix of plaintext and IPsec packets are sent and 
received on the uplinks.  Suppose that a separate SPD is to be used for 
each protected network interface.  Consider the case of packets arriving 
from the protected network interfaces.  The SPD to be applied needs to be 
selected based on the interface the packet srrived _from_, not the 
interface the packet (either bypassed, or encapsulated in IPsec) will be 
forwarded _to_.

One could explain that in terms of the proposed model by saying that the 
incoming packets are sent by a "forwarding function" (based on the 
protected interface they were received from) to one of 3 virtual 
interfaces, and that each of those virtual interfaces has an SPD 
associated.  Then, after packets are encapsulated or bypassed, there is 
another forwarding function that chooses the outgoing uplink.  IMO however 
such an explanation would be a contortion.

>>>However, after the packet is emitted, it could be redirected through the 
>>>IPsec module via local, virtual interfaces and use of the forwarding 
>>>lookup function, to cause more than one layer of IPsec headers to be 
>>>applied or removed. Note that to accomplish this, multiple entries would 
>>>have to be created, in distinct SPDs, each specifying a layer of IPsec 
>>>processing to be applied. However, IKE still lacks a means to negotiate 
>>>this, so I suspect that only manual configuration, or some key 
>>>management mechanism not yet defined for IPsec, would be needed to take 
>>>advantage of this approach.
>>
>IKE, as-is, negotiates one pair of SAs at a time, and has not means to 
>communicate the intent of one side to bind together different SAs 
>negotiated independently, as best I know.  So, rather than saying that 
>there might be some magic way to express this through SPD entries, I was 
>suggesting that we cleanly abandon it if IKE cannot negotiate it. 
>Otherwise we have so many ways to have things not work despite successful 
>IKE-level negotiation ...

My point was that depending on the specific functions of IPsec devices, and 
depending on their configuration, the nesting of SAs might "just happen" 
and that even though IKE would not be used to bind the SAs together, the 
whole thing would "just work".  I don't see any reason for 2401bis to 
explicitly disallow this, as this would not be requiring any specific 
support from 2401bis or from IKE.

For example, packets might be forwarded via a virtual interface with an 
associated SPD.  That SPD causes certain packets to be encapsulated in 
tunnel mode IPsec packets of SA sa-1 addressed to IPsec peer p-1.  Those 
IPsec packets (as well as other packets) are subjected to another 
forwarding decision to select the correct outgoing physical link towards 
their destination, such as p-1.  Suppose that that outgoing interface also 
has an associated SPD that causes AH and ESP (and other) packets to be 
encapsulated in IPsec SA sa-2.  So, some packets might be sent out 
encapsulated in sa-1. some in sa-2, some in sa-1 nested withing sa-2, and 
some sent unencapsulated.  But sa-1 and sa-2 have no particular 
relationship to one another.

--Mark

---

From: Stephen Kent <[email-masked]>
Date: Thu, 31 Jul 2003 15:22:43 -0400

Mark,

I've trimmed the message to keep it readable, since I think we agree 
on the facts, just not what to do as a result :-).

So we agree that there is a way to achieve source-based SPD 
selection, and to provide independent forwarding, but you don't think 
the mechanism is not elegant.  If I understand your suggestion, 
though, you would remove all specification of this functionality, and 
I don't think we have a useful spec if we do that.  Did I 
misunderstand what you were suggesting here?

I agree that one could manage to configure SPDs so that nested SA 
could result.   But, it's probably hard for most folks to do this, 
and without explicit, support in IKE, if this fails the results will 
be hard to diagnose. Also, because one would have to effect two IKE 
negotiations to create both sets of SAs, there are timing issues that 
could arise that also would result in possibly confusing behavior.

It's easy to have 2401bis not say that nesting of SAs is prohibited. 
It's harder to say that that nesting MUST or MAY be supported, and 
how. What do you think should be said here? My concern, in part, is 
that if we say nothing, then users don't know what to expect re 
functionality, nor do they have any sense of whether two 
implementations by two different vendors will support this sort of 
nesting. That's not a good thing for a standard.

Steve

---

From: "Scott G. Kelly" <[email-masked]>
Date: Thu, 31 Jul 2003 15:35:43 -0700

I have a few comments on this (interspersed below...)

Mark Duffy wrote:
| It is the "used both for..." part of that that I am resisting.
|
| My opinion is that the proposed forwarding function and virtual
| interface concepts are helpful, but do not go far enough in generalizing
| the IPsec model.  What I would hope to see 2401bis embrace is a model
| where packets enter an IPsec device, some device-specific logic selects
| an SPD to apply, and then the IPsec and bypassed packets are forwarded
| out an interface chosen by some separate device-specific logic, for
| example IP longest matching prefix forwarding.
|
| Let me give an example of a hypothetical yet reasonable device that is
| not readily accomodated by the 2401bis model as proposed.  Suppose we
| have a security gateway sort of device that has 3 LAN interfaces that it
| is protecting i.e. "protected networks" and 2 WAN interfaces to the
| Internet i.e. "uplinks."  Plaintext packets are sent and received on the
| protected network interfaces, and a mix of plaintext and IPsec packets
| are sent and received on the uplinks.  Suppose that a separate SPD is to
| be used for each protected network interface.  Consider the case of
| packets arriving from the protected network interfaces.  The SPD to be
| applied needs to be selected based on the interface the packet srrived
| _from_, not the interface the packet (either bypassed, or encapsulated
| in IPsec) will be forwarded _to_.

Steve can correct me if I've misinterpreted the model, but what you are
saying here doesn't square with my understanding of the model. Here is
how I understand it (and have implemented it in a previous life):

~                   +-----------------+
~                   | packet from an  |
~                   |  application    |
~                   +-------+---------+
~                           | outgoing
~                           V packet
~            +----------------------------------------------+
~            |      packet forwarding (routing) module      |
~            |
~            |  +-->----->------+
~            +-/-----------------\---------------------------+
~   incoming  /                   \ outgoing
~   packet   /                     | packet
~      +----------------+     +----V-----------+      +----------------+
~      |   Interface 0  |     |   Interface 1  |      |   Interface n  |
~      |    +-------+   |     |    +-------+   |      |    +-------+   |
~      |    | SPD 0 |   |     |    | SPD 1 |   | ...  |    | SPD n |   |
~      |    +-------+   |     |    +-------+   |      |    +-------+   |
~      +----------------+     +----------------+      +----------------+
~        ^
_______/
incoming
packet1

Note that these interfaces may be physical *or* logical. In this model,
packets coming in from the network are first evaluated according to the
policies of the ingress interface. Assuming the packet is allowed to
continue (i.e. it is not discarded), the next step is to perform a
forwarding lookup. If the packet is locally destined, it will be passed
up to the appropriate internal consumer. If not, the egress interface
must be determined according to the forwarding lookup (which will be
longest prefix match), and then the policy of the egress interface will
be examined to determine what to do next. In the case of internally
generated (outbound) packets, the local application hands them to the
stack, which first does a forwarding lookup to determine the egress
interface, and then the policies of that interface are applied.

Why doesn't this model permit the processing you want?

Scott