Subject: Re: revised IPsec processing model

From: Mark Duffy <[email-masked]>
Date: Fri, 01 Aug 2003 10:29:31 -0400

At 03:22 PM 7/31/2003 -0400, Stephen Kent wrote:
>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.

Well of course a device can select an SPD in any way it wants; the issue 
here is about whether the IPsec standard sanctions it or not.  With the 
proposed model of 2401bis it might be debatable whether certain behaviors 
comply, as it would depend on how liberal one is in defining "interface" 
and "forwarding function".  If 2401bis makes it clear that these terms may 
be widely construed, then I agree that the proposed model is flexible 
enough at least for the devices I am envisioning.

>   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 think maybe you did.  My suggestion in a nutshell is not to remove 
specification but to modify it thus:

  1.  Say that the SPD is selected by an "SPD selection function" rather 
than by a "forwarding function".  If we are considering that the 
"forwarding function" may be arbitrary anyway, this wording change seems to 
me to be no more than being honest with ourselves.

  2.  Explicitly recognize that the forwarding function that chooses an 
outgoing IP interface (i.e. for bypassed packets and for packets that have 
just been encrypted or just been decrypted) need not be the same function 
as the SPD selection function.

The important *results* of those two points are that: outgoing packets A 
and B may be treated under different SPDs but be sent out the same IP 
interface, and outbound packets C and D may be treated under the same SPD 
but be sent out different interfaces.  (And similarly for inbound packets.)

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

I would propose to say nothing about the nesting of SAs.  I agree with you 
that the standard must be clear on how implementations behave, but I think 
the issue here is one level above the IPsec protocol itself, dealing 
instead with multiple applications of the protocol.  Consider placing 2 
security gateways in "series" so that the AH or ESP packets emitted by the 
first are considered as plaintext or subscriber packets by the second, and 
nested into another SA.  Each SG is just doing a vanilla thing but the 
network administrator has created nested SAs.  What difference should it 
make to the standard whether someone combines both those SGs into one device?

--Mark

>Steve

---

From: Mark Duffy <[email-masked]>
Date: Fri, 01 Aug 2003 11:20:45 -0400

Hi Scott,

What you describe below is by my understanding the model not only of 
Steve's 2401bis proposal but also the (arguably more limiting) model of rfc 
2401.  And yes, I think it does not permit the processing required for my 
example.

In the 2401 model, the SPD associated with an interface controls IPsec on 
that interface as follows:  It specifies whether outgoing packets SENT out 
that interface should be dropped, bypassed, or have IPsec applied, and 
whether incoming packets RECEIVED on that interface should be dropped, 
bypassed, or must have arrived with IPsec protection.

My example requires that this be turned inside-out in a sense.  To make the 
example work, the SPD associated with one of the LAN (aka subscriber) 
interfaces controls whether incoming packets RECEIVED on that interface 
should be dropped, bypassed, or have IPsec applied, and whether outgoing 
packets SENT out that interface should be dropped, bypassed, or must have 
arrived into the device with IPsec protection.

Again, this was only an example device.  The larger point was to 
demonstrate the generalizing the model to make SPD selection *independent* 
of forwarding decision (i.e. independent of exit interface) enables 
applications of IPsec that are not otherwise possible.  Another example 
that was made earlier in this thread was the case where an SPD should apply 
to a set of interfaces.

Since you have supplied such a nice picture, I'll attempt to edit it to 
represent what I am advocating:

         +----------------------------+    +---------------------+
          | SPD selection   +-------+  |    | packet forwarding   |
         | module          | SPD a |  |    | (routing) module    |
         |                 +-------+  |    |                     |
         |                            |-->---------->            |
          |        /        +-------+  |    |         \           |
         |       -->-----> | SPD b |  |    |          \          |
         |      /          +-------+  |    |           \         |
         +-----/----------------------+    +------------\--------+
           /                                          \
    incoming /                                           \ outgoing
    packet  /                                              | packet
       +----------------+     +----------------+      +-----V----------+
       |   Interface 0  |     |   Interface 1  |      |   Interface n  |
       +----------------+     +----------------+      +----------------+
         ^
  _______/
  incoming
  packet

--Thanks, Mark

At 03:35 PM 7/31/2003 -0700, Scott G. Kelly wrote:
[snip]
>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

---

From: "Scott G. Kelly" <[email-masked]>
Date: Fri, 01 Aug 2003 08:40:07 -0700

Hi Mark,

I'm doing my best to try to understand, but email is a difficult medium
for conveying complex ideas, so please bear with me while I try to sort
this out. Given the following picture

~               +---------------+
~               |               |             +------+
~ [host a]------|[if0]     [if1]|_____________|      |
~               |  |         |  |_____________| SGW2 |---[host b]
~               |[spd0]   [spd1]| tunnel      |      |
~               +---------------+             +------+

I think you're saying that you want the policy rule causing traffic
from host a to host b to be tunneled to live in spd0 instead of spd1. Is
this right?

Scott

---

From: Stephen Kent <[email-masked]>
Date: Fri, 1 Aug 2003 16:49:58 -0400

At 10:29 -0400 8/1/03, Mark Duffy wrote:
>>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.
>
>Well of course a device can select an SPD in any way it wants; the 
>issue here is about whether the IPsec standard sanctions it or not. 
>With the proposed model of 2401bis it might be debatable whether 
>certain behaviors comply, as it would depend on how liberal one is 
>in defining "interface" and "forwarding function".  If 2401bis makes 
>it clear that these terms may be widely construed, then I agree that 
>the proposed model is flexible enough at least for the devices I am 
>envisioning.

I agree that we should make sure the text does not convey the wrong impression.

>>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?
>
>  1.  Say that the SPD is selected by an "SPD selection function" 
>rather than by a "forwarding function".  If we are considering that 
>the "forwarding function" may be arbitrary anyway, this wording 
>change seems to me to be no more than being honest with ourselves.

the reason for adding the lookup was to provide a forwarding 
function, i.e., selection of the output interface for the simple 
case, or the next (virtual) interface in fancier cases. So I do not 
think it appropriate to consider renaming the function to say that it 
is for SPD lookup. The SPD is selected because it is bound to an 
interface not the other way around.

>  2.  Explicitly recognize that the forwarding function that chooses 
>an outgoing IP interface (i.e. for bypassed packets and for packets 
>that have just been encrypted or just been decrypted) need not be 
>the same function as the SPD selection function.

As I said above, the whole point of the lookup was to select the 
interface, and the SPD has always been bound to an interface. I'm not 
sure why you want to reverse the meaning here.

>The important *results* of those two points are that: outgoing 
>packets A and B may be treated under different SPDs but be sent out 
>the same IP interface, and outbound packets C and D may be treated 
>under the same SPD but be sent out different interfaces.  (And 
>similarly for inbound packets.)

yes, the can be sent to the same interface, after IPsec processing, 
using the second lookup.

>>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.
>
>I would propose to say nothing about the nesting of SAs.  I agree 
>with you that the standard must be clear on how implementations 
>behave, but I think the issue here is one level above the IPsec 
>protocol itself, dealing instead with multiple applications of the 
>protocol.  Consider placing 2 security gateways in "series" so that 
>the AH or ESP packets emitted by the first are considered as 
>plaintext or subscriber packets by the second, and nested into 
>another SA.  Each SG is just doing a vanilla thing but the network 
>administrator has created nested SAs.  What difference should it 

The difference arises at the device where the two SAs must be 
coordinated, else inbound packets drop on the floor, or outbound 
packets fail to be protected as desired. I can be persuaded that we 
ought to say nothing about requiring support for nesting, but since 
we used to mandate such support, we cannot just be silent on the 
issue. Also, since I think a good standard lets users know what they 
can and cannot expect to achieve when communicating between 
implementations produced by different vendors, what do you propose 
that we say in this context?

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 1 Aug 2003 17:33:21 -0400

Scott,

Thanks for trying to construct the diagram. It's something I need to 
do for the ID, but have not done yet.

There are some enhancements I would make to the diagram.

Outbound

	1. for outbound traffic *from the application or the 
protected net) the interface lookup (forwarding function) is the 
first step
	2. then the packet goes to the SPD cache for the selected interface
	3.after processing (bypass or IPsec), there is a second 
lookup, to allow for looping, or for folks like Mark who want to 
separate SPD selection from the output (or next) interface selection
	4. either the packet exits now, or it goes back for another pass

Inbound
	1. demux traffic into one of 3 classes: IKE, IPsec (AH/ESP) 
AND addressed to this device, or NOT AH/ESP
	2a. if IKE, then vector to the IKE processor
	2b. if AH/ESP and for us, then lookup in the SAD (only one 
per implementation) and process accordingly
	2c. if not AH/ESP for us, or just not for us, then lookup in 
inbound bypass cache
	3. for the 2b case, after AH/ESP processing, the inbound SPD 
check is done based on SAD data, not a lookup in the SPD. then, for 
those internal looping fans, one can add yet another lookup to decide 
what interface this is delivered to, e.g., the application, the 
protected LAN, or back to step 1.

Steve

---

From: Mark Duffy <[email-masked]>
Date: Sat, 02 Aug 2003 14:55:54 -0400

At 04:49 PM 8/1/2003 -0400, Stephen Kent wrote:
[snip]
>> "forwarding function" may be arbitrary anyway, this wording change seems 
>> to me to be no more than being honest with ourselves.
>
>the reason for adding the lookup was to provide a forwarding function, 
>i.e., selection of the output interface for the simple case, or the next 
>(virtual) interface in fancier cases. So I do not think it appropriate to 
>consider renaming the function to say that it is for SPD lookup. The SPD 
>is selected because it is bound to an interface not the other way around.
>
>
>> outgoing IP interface (i.e. for bypassed packets and for packets that 
>> have just been encrypted or just been decrypted) need not be the same 
>> function as the SPD selection function.
>
>interface, and the SPD has always been bound to an interface. I'm not sure 
>why you want to reverse the meaning here.

Yes the SPD has always been bound to an interface, but that doesn't mean it 
must always be so, and the model would be more flexible if it were not so 
required.  However, maybe this is just too big a change to ask.

[snip]

>>>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.
>>
>>I would propose to say nothing about the nesting of SAs.  I agree with 
>>you that the standard must be clear on how implementations behave, but I 
>>think the issue here is one level above the IPsec protocol itself, 
>>dealing instead with multiple applications of the protocol.  Consider 
>>placing 2 security gateways in "series" so that the AH or ESP packets 
>>emitted by the first are considered as plaintext or subscriber packets by 
>>the second, and nested into another SA.  Each SG is just doing a vanilla 
>>thing but the network administrator has created nested SAs.  What 
>>difference should it make to the standard whether someone combines both 
>>those SGs into one device?
>
>The difference arises at the device where the two SAs must be coordinated, 
>else inbound packets drop on the floor, or outbound packets fail to be 
>protected as desired. I can be persuaded that we ought to say nothing 
>about requiring support for nesting, but since we used to mandate such 
>support, we cannot just be silent on the issue. Also, since I think a good 
>standard lets users know what they can and cannot expect to achieve when 
>communicating between implementations produced by different vendors, what 
>do you propose that we say in this context?

No matter what the standard says, it will be possible for someone to apply 
the standard twice, or n times, in succession to a packet and the 
probability approaches 1 that someone will do so.

I'd propose that the standard should say that the requirement to support 
nesting (as it existed in 2401) has been removed.  And I would just stop 
there.  If folks really feel it is necessary to say more, I would add a 
statement acknowledging that it is possible to apply the standard 
iteratively to a given packet and that this will have the effect of 
"nesting" SAs.

--Mark

---

From: Mark Duffy <[email-masked]>
Date: Sat, 02 Aug 2003 14:31:17 -0400

Yes Scott, that is exactly right.
But again, this was just an example of one situation where one would want 
to decouple the choice of SPD from the choice of exit interface.

--Mark

At 08:40 AM 8/1/2003 -0700, Scott G. Kelly wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hi Mark,
>

---

From: Stephen Kent <[email-masked]>
Date: Mon, 4 Aug 2003 14:11:23 -0400

Mark,

>Yes the SPD has always been bound to an interface, but that doesn't 
>mean it must always be so, and the model would be more flexible if 
>it were not so required.  However, maybe this is just too big a 
>change to ask.

If we want to consider that change, we should have folks on both side 
of the debate comment.

>No matter what the standard says, it will be possible for someone to 
>apply the standard twice, or n times, in succession to a packet and 
>the probability approaches 1 that someone will do so.

agreed, but non-complaint behavior should be something we can 
objectively identify. a standard for which one cannot describe a 
non-compliant implementation is not a useful standard (and, or 
course, the conevrse is true too!)

>I'd propose that the standard should say that the requirement to 
>support nesting (as it existed in 2401) has been removed.  And I 
>would just stop there.  If folks really feel it is necessary to say 
>more, I would add a statement acknowledging that it is possible to 
>apply the standard iteratively to a given packet and that this will 
>have the effect of "nesting" SAs.

I'm happy to say that we have removed the requirement re nesting, and 
also say that one can offer the feature via appropriate configuration 
of SPDs and forwarding tables within an implementation, but that 
there is no IKE support for this and thus care must be exercised in 
enabling this capability.

Steve

---

From: Joe Touch <[email-masked]>
Date: Mon, 04 Aug 2003 13:36:44 -0700

Hi, all,

Stephen Kent wrote:
> Mark,
> 
> responses inline to your comments:
> 
>     <SNIP>
> 
>> 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.
> 
> 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.

FYI, we call it forwarding since it would do what IP forwarding does. 
However, note that IP forwarding, as we have pointed out before, 
involves more than finding the outgoing interface.

Consider a system:

                 c
               /
	a----b
               \
                 d

Where a packet comes from 'a' and goes many hops downstream of 'c' or 
'd', where c,d are the nexthops from b. It is possible that c and d are 
on the same LAN as b, e.g., an FDDI ring or ethernet switch at a POP.

In that case, regardless of whether c or d is chosen, the packet will 
have the same outgoing interface. Outgoing interface alone will be 
insufficient to support dynamic routing.

As we have observed before, IP forwarding specifies both the outgoing 
interface and the next-hop IP address; both are required to specify the 
appropriate database.

However, as our ID points out, this is a cumbersome solution compared to 
the alternatives.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 04 Aug 2003 14:00:45 -0700

Stephen Kent wrote:

> At 13:36 -0700 8/4/03, Joe Touch wrote:
> 
>> Hi, all,
>>
>> Stephen Kent wrote:
>>
>>> Mark,
>>>
>>> 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.
>>
>>
>> 'd', where c,d are the nexthops from b. It is possible that c and d 
>> are on the same LAN as b, e.g., an FDDI ring or ethernet switch at a POP.
>>
>> interface and the next-hop IP address; both are required to specify 
>> the appropriate database.
>>
>> However, as our ID points out, this is a cumbersome solution compared 
>> to the alternatives.
> 
> 
> Joe,
> 
> Cumbersome is in the eye of the beholder :-).
> 
> The other folks who participated in the discussions, who are vendors, 
> did not seem to agree with the overlay net model you & Lars proposed. 

Having just participated in one such meeting in the U.K., at least one 
major vendor is prescribing our model as a preferred solution.

> Also, that model seems narrowly focused on end system, vs. SG or BITW, 
> implementations.  It is preferable to have a simple model that is 
> generally applicable, and that's what we have strived to achieve.

I certainly appreciate, as you have observed, that our perspective is 
end-system based. You have also noted:

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

It would be useful at least if this proposal could be vetted with a 
working implementation on both a router and an end host before being 
considered as such a major modification to the architecture.

-----------

One other question:

What happens to packets when the IPsec-time forwarding lookup differs 
from the forwarding that actually happens when the packet would be emitted?

I.e., it seems possible that if I had weak or no encryption on one link, 
that it might be possible to leak such packets out onto a link that I 
needed strong protection on. If this is not the case, a specific example 
would help.

Joe

---

From: Stephen Kent <[email-masked]>
Date: Mon, 4 Aug 2003 16:48:41 -0400

At 13:36 -0700 8/4/03, Joe Touch wrote:
>>>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.
>>
>>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.
>
>FYI, we call it forwarding since it would do what IP forwarding 
>does. However, note that IP forwarding, as we have pointed out 
>before, involves more than finding the outgoing interface.
>
>Consider a system:
>
>                 c
>               /
>	a----b
>               \
>                 d
>
>Where a packet comes from 'a' and goes many hops downstream of 'c' 
>or 'd', where c,d are the nexthops from b. It is possible that c and 
>d are on the same LAN as b, e.g., an FDDI ring or ethernet switch at 
>a POP.
>
>In that case, regardless of whether c or d is chosen, the packet 
>will have the same outgoing interface. Outgoing interface alone will 
>be insufficient to support dynamic routing.
>
>As we have observed before, IP forwarding specifies both the 
>outgoing interface and the next-hop IP address; both are required to 
>specify the appropriate database.
>
>However, as our ID points out, this is a cumbersome solution 
>compared to the alternatives.

Joe,

The other folks who participated in the discussions, who are vendors, 
did not seem to agree with the overlay net model you & Lars proposed. 
Also, that model seems narrowly focused on end system, vs. SG or 
BITW, implementations.  It is preferable to have a simple model that 
is generally applicable, and that's what we have strived to achieve.

Steve

---

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

At 14:00 -0700 8/4/03, Joe Touch wrote:
>>The other folks who participated in the discussions, who are 
>>vendors, did not seem to agree with the overlay net model you & 
>>Lars proposed.
>
>Having just participated in one such meeting in the U.K., at least 
>one major vendor is prescribing our model as a preferred solution.

OK.

>>BITW, implementations.  It is preferable to have a simple model 
>>that is generally applicable, and that's what we have strived to 
>>achieve.
>
>I certainly appreciate, as you have observed, that our perspective 
>is end-system based. You have also noted:
>

After that exchange, two folks with knowledge of host OS internals, 
and who are implementors of IPv6 and IPsec, confirmed that they saw 
no problems with the proposed processing model via messages to the 
list. Two individuals have told me privately, in the last few weeks, 
that their implementations are equivalent to the processing model, in 
person or in e-mails.  I do not agree that there needs to be working 
examples before we proceed with a new version of 2401, although I 
think I am hearing that there will be several in the near future.

>-----------
>
>One other question:
>
>What happens to packets when the IPsec-time forwarding lookup 
>differs from the forwarding that actually happens when the packet 
>would be emitted?
>
>I.e., it seems possible that if I had weak or no encryption on one 
>link, that it might be possible to leak such packets out onto a link 
>that I needed strong protection on. If this is not the case, a 
>specific example would help.

If I understand correctly, your concern is that there could be a 
mismatch between an SPD lookup that maps a packet to a interface that 
is deemed implicitly secure and thus does not warrant IPsec 
protection, but a later forwarding decision that puts the packet out 
over a link that does warrant protection.  Is that right?

I certainly agree that this would be a "bad thing" and one must 
configure the SPDs and the forwarding tables to avoid the problem. If 
we allow the first forwarding table to select the appropriate SPD, 
then we have to rely on that forwarding function to operate 
correctly, IF we allow any sensitive traffic to be emitted without 
IPsec protection on ANY link. Otherwise, the first forwarding lookup 
could map the traffic to an SPD that allowed bypass such traffic for 
a specific interface, but then the traffic could be emitted via a 
different interface, thus defeating the intent of the policy 
specification.

Also, if the SPD does allow bypassing of any sensitive traffic, then 
the post IPsec processing forwarding lookup also must function 
properly, lest the same bad effect take place despite the correct 
functioning of the first lookup (and the correct config of the 
corresponding SPD).  Frankly, this is why I worry about anything 
other than the trivial case with one SPD and no per-interface 
distinctions about what classes of traffic to protect.  If the WG 
feels that we do not require per-interface SPDs, as Mark suggested, I 
am happy to make that change. But I note that Mark did call for 
multiple SPDs (just not tied to an interface by the first forwarding 
function), and I see the same opportunity for security problems due 
to lookup errors in that case as well.

I think the fundamental problem here is the opportunity to emit 
traffic without appropriate protection, due to a mismatch between 
what an SPD says and what a forwarding function does.  This is 
ultimately a config management problem, made worse by a desire to 
support fancier access controls and fancier forwarding options.

Steve

---

From: Joe Touch <[email-masked]>
Date: Mon, 04 Aug 2003 16:39:30 -0700

Stephen Kent wrote:

> mismatch between an SPD lookup that maps a packet to a interface that is 
> deemed implicitly secure and thus does not warrant IPsec protection, but 
> a later forwarding decision that puts the packet out over a link that 
> does warrant protection.  Is that right?

Yes.

> configure the SPDs and the forwarding tables to avoid the problem. 

IPsec can have no control over the forwarding tables.

Other than ensuring that one can -never- configure two tunnels with one 
being weaker, there doesn't seem to be a solution that is enforceable 
within IPsec using this architecture.

> If we 
> allow the first forwarding table to select the appropriate SPD, then we 
> have to rely on that forwarding function to operate correctly, IF we 
> allow any sensitive traffic to be emitted without IPsec protection on 
> ANY link.

I'm considering a case where the forwarding table isn't malicious; the 
trick is that this model (using forwarding inside IPsec) requires that 
there be a lock between doing a forwarding lookup and emitting the packet.

A forwarding table must be able to change, e.g., that's the definition 
of dynamic routing.

> Otherwise, the first forwarding lookup could map the traffic 
> to an SPD that allowed bypass such traffic for a specific interface, but 
> then the traffic could be emitted via a different interface, thus 
> defeating the intent of the policy specification.

That's the problem I'm worried about.

> Also, if the SPD does allow bypassing of any sensitive traffic, then the 
> post IPsec processing forwarding lookup also must function properly, 
> lest the same bad effect take place despite the correct functioning of 
> the first lookup (and the correct config of the corresponding SPD).  

Aggred - but again, it's not malicious behavior, but normal operation 
that might cause this.

> Frankly, this is why I worry about anything other than the trivial case 
> with one SPD and no per-interface distinctions about what classes of 
> traffic to protect.  If the WG feels that we do not require 
> per-interface SPDs, as Mark suggested, I am happy to make that change. 
> But I note that Mark did call for multiple SPDs (just not tied to an 
> interface by the first forwarding function), and I see the same 
> opportunity for security problems due to lookup errors in that case as 
> well.

Agreed. Note that this is not a problem with the solution we propose, 
because the routing table is involved exactly once for each packet for us.

> I think the fundamental problem here is the opportunity to emit traffic 
> without appropriate protection, due to a mismatch between what an SPD 
> says and what a forwarding function does.  This is ultimately a config 
> management problem, made worse by a desire to support fancier access 
> controls and fancier forwarding options.

Agreed - except that, as above, I don't see how to configure dynamic 
routing except across two _identically protected_ tunnels. That is a 
requirement that severely limits the utility of such a solution, IMO.

Joe

---

From: Mark Duffy <[email-masked]>
Date: Mon, 04 Aug 2003 23:39:43 -0400

Hi all,

I'm a bit mystified about this line of discussion.  The change that Steve 
has proposed in the processing model is IMO a clarification (in that the 
packet forwarding decision that takes place in an IP device is explicitly 
recognized) and a generalization (in that it recognizes that an 
implementation *may* make more than one "forwarding" decision on a packet, 
an implementation *may* pass a packet through more than one SPD and IPsec 
treatment, and the "forwarding" function used is beyond the scope of 
IPsec.)  There is nothing in this that *requires* any implementation to 
take advantage of any of that.  So I would expect that if the RFC 2401 
model is sufficient for a given purpose, the proposed one should be also.  No?

There is always the risk of misconfiguring the device (any configurable 
IPsec device) and thereby compromising security.  I agree that as 
flexibility of a device goes up (e.g. from 1 SPD per box to one per 
interface, or to more complex behaviors) the risk of misconfiguration 
generally goes up.  But the benefits of using the device also go up.  This 
tradeoff between functionality and risk is for those deploying equipment to 
make.  (Obviously, anyone would be ill-advised to manufacture or deploy 
devices that perform improperly as with the hypothetical race conditions 
described below.)

Mark

At 04:39 PM 8/4/2003 -0700, Joe Touch wrote:

>>If I understand correctly, your concern is that there could be a mismatch 
>>between an SPD lookup that maps a packet to a interface that is deemed 
>>implicitly secure and thus does not warrant IPsec protection, but a later 
>>forwarding decision that puts the packet out over a link that does 
>>warrant protection.  Is that right?
>
>Yes.
>
>>I certainly agree that this would be a "bad thing" and one must configure 
>>the SPDs and the forwarding tables to avoid the problem.
>
>>If we allow the first forwarding table to select the appropriate SPD, 
>>then we have to rely on that forwarding function to operate correctly, IF 
>>we allow any sensitive traffic to be emitted without IPsec protection on 
>>ANY link.
>
>A forwarding table must be able to change, e.g., that's the definition of 
>dynamic routing.
>
>>Otherwise, the first forwarding lookup could map the traffic to an SPD 
>>that allowed bypass such traffic for a specific interface, but then the 
>>traffic could be emitted via a different interface, thus defeating the 
>>intent of the policy specification.
>
>>post IPsec processing forwarding lookup also must function properly, lest 
>>the same bad effect take place despite the correct functioning of the 
>>first lookup (and the correct config of the corresponding SPD).
>
>Aggred - but again, it's not malicious behavior, but normal operation that 
>might cause this.
>
>>traffic to protect.  If the WG feels that we do not require per-interface 
>>SPDs, as Mark suggested, I am happy to make that change. But I note that 
>>Mark did call for multiple SPDs (just not tied to an interface by the 
>>first forwarding function), and I see the same opportunity for security 
>>problems due to lookup errors in that case as well.
>

---

From: Stephen Kent <[email-masked]>
Date: Tue, 5 Aug 2003 09:52:14 -0400

At 16:39 -0700 8/4/03, Joe Touch wrote:
>>>link, that it might be possible to leak such packets out onto a 
>>>link that I needed strong protection on. If this is not the case, 
>>>a specific example would help.
>>
>>mismatch between an SPD lookup that maps a packet to a interface 
>>that is deemed implicitly secure and thus does not warrant IPsec 
>>protection, but a later forwarding decision that puts the packet 
>>out over a link that does warrant protection.  Is that right?
>
>Yes.
>

I cam see how you might come to that conclusion in some contexts, but 
it certainly is not true in all contexts. For example, some vendors 
of BITW and SG IPsec products provide a unified management interface 
that allows a sys admin to configure the forwarding tables and the 
SPDs together, to avoid the sort of problems we both agree are a 
concern.

>Other than ensuring that one can -never- configure two tunnels with 
>one being weaker, there doesn't seem to be a solution that is 
>enforceable within IPsec using this architecture.

This is definitely not true, as stated. What I think you mean to say 
is that IF we specify two or more entries in multiple SPDs for the 
same class of traffic (e.g., the same selector sets) AND they have 
different security properties (e.g., IPsec protection vvs. bypass) 
THEN an error in the lookup that selects an SPD (and virtual 
interface) or in the lookup that selects the ultimate outbound 
interface, could result in a security breach. But, to get into this 
situation we have to have several precursor conditions satisfied, and 
I expect that in many environments the configurations will not be so 
complex as to facilitate these sorts of problems.

>
>>If we allow the first forwarding table to select the appropriate 
>>SPD, then we have to rely on that forwarding function to operate 
>>IPsec protection on ANY link.
>
>I'm considering a case where the forwarding table isn't malicious; 
>the trick is that this model (using forwarding inside IPsec) 
>requires that there be a lock between doing a forwarding lookup and 
>emitting the packet.
>
>A forwarding table must be able to change, e.g., that's the 
>definition of dynamic routing.

But not all routing is dynamic.  My first hop router may be fixed in 
many contexts, because I have only one choice to exit my LAN. In many 
cases where the choice of first hop router is not known in advance, 
e.g., in my hotel room, I may have only only interface to deal with 
and thus avoid the security problems in that fashion.

>
>>Otherwise, the first forwarding lookup could map the traffic to an 
>>SPD that allowed bypass such traffic for a specific interface, but 
>corresponding SPD).

>
>Aggred - but again, it's not malicious behavior, but normal 
>operation that might cause this.

If normal behavior in common circumstances would cause this to 
happen, then the configuration is inherently insecure. If that 
possibility can be detected by a config admin tool, then the admin 
can be warned.

>
>>Frankly, this is why I worry about anything other than the trivial 
>>case with one SPD and no per-interface distinctions about what 
>>classes of traffic to protect.  If the WG feels that we do not 
>>require per-interface SPDs, as Mark suggested, I am happy to make 
>>that change. But I note that Mark did call for multiple SPDs (just 
>>not tied to an interface by the first forwarding function), and I 
>>see the same opportunity for security problems due to lookup errors 
>>in that case as well.
>
>Agreed. Note that this is not a problem with the solution we 
>propose, because the routing table is involved exactly once for each 
>packet for us.

I don't see how this problem is avoidable in any context where you 
maintain that a table used for forwarding is outside the scope of the 
security boundary.  Could you elaborate, without merely referring to 
your ID?

>requirement that severely limits the utility of such a solution, IMO.

First, we probably do not agree on the extent to which dynamic 
routing is always going to be a factor here.  Second, there are means 
to provide security for routing data. For example, in high assurance 
contexts where IPsec-like protection is to be employed, it is 
appropriate to use S-BGP to ensure that the ability to advertise 
prefixes for the hosts "behind" a security device is done securely, 
i.e., the advertisements are authorized.

Steve

---

From: Joe Touch <[email-masked]>
Date: Mon, 11 Aug 2003 11:15:15 -0700

Mark Duffy wrote:

> Hi all,
> 
> I'm a bit mystified about this line of discussion.  The change that 
> Steve has proposed in the processing model is IMO a clarification (in 
> that the packet forwarding decision that takes place in an IP device is 
> explicitly recognized) and a generalization (in that it recognizes that 
> an implementation *may* make more than one "forwarding" decision on a 
> packet, an implementation *may* pass a packet through more than one SPD 
> and IPsec treatment, and the "forwarding" function used is beyond the 
> scope of IPsec.)  There is nothing in this that *requires* any 
> implementation to take advantage of any of that.  So I would expect that 
> if the RFC 2401 model is sufficient for a given purpose, the proposed 
> one should be also.  No?

This "clarification" highlights an undesirable interaction between 
dynamic routing and IPsec. While we wouldn't want that interaction to be 
'required', highlighting it alone is insufficient if the interaction has 
undesirable consequences.

> IPsec device) and thereby compromising security. 

Agreed; however, what we've been talking about is a properly configured 
device. Unless

	a) all tunnels with overlapping traffic selectors must have
	identical security

	or

	b) IPsec is not run in conjunction with dynamic routing

 > I agree that as
> generally goes up.  But the benefits of using the device also go up.  
> This tradeoff between functionality and risk is for those deploying 
> equipment to make.  (Obviously, anyone would be ill-advised to 
> manufacture or deploy devices that perform improperly as with the 
> hypothetical race conditions described below.)

These 'race' conditions are the result of normal operation, not 
misconfiguration or misimplementation.

Joe

>>> not tied to an interface by the first forwarding function), and I see 
>>> the same opportunity for security problems due to lookup errors in 
>>> that case as well.
>>
>>

---

From: Joe Touch <[email-masked]>
Date: Mon, 11 Aug 2003 11:08:27 -0700

Stephen Kent wrote:

> I cam see how you might come to that conclusion in some contexts, but it 
> certainly is not true in all contexts. For example, some vendors of BITW 
> and SG IPsec products provide a unified management interface that allows 
> a sys admin to configure the forwarding tables and the SPDs together, to 
> avoid the sort of problems we both agree are a concern.

An implementation may certainly control both the SPDs and forwarding
tables in concert. However, short of specifying that in 2401bis, it
would not be required, and thus open a substantial security hole.

> This is definitely not true, as stated.  What I think you mean to say is
> that IF we specify two or more entries in multiple SPDs for the same 
> class of traffic (e.g., the same selector sets) 

That's assumed when we're talking about dynamic routing; otherwise, the
traffic doesn't go out two different SAs depending on the routing table ;-)

> AND they have different 
> security properties (e.g., IPsec protection vvs. bypass) THEN an error 
> in the lookup that selects an SPD (and virtual interface) or in the 
> lookup that selects the ultimate outbound interface, could result in a 
> security breach.

The remainder is basically what I said. And (again) this isn't an
'error'; it's normal operation _whenever_ the routing table changes
under constant packet load.

> But, to get into this situation we have to have several
> precursor conditions satisfied, and I expect that in many environments 
> the configurations will not be so complex as to facilitate these sorts 
> of problems.

I believe I have given an entirely reasonable set of configurations that
are desired for those using dynamic routing. It would rarely be the case
that two alternate forwarding tunnels would have _exactly_ the same
security properties.

> But not all routing is dynamic.

Agreed. If the proposed solution is limited to static routing
environments, sure, fine - there's still the issue of the missing 
next-hop info (which hasn't been addressed yet), but no  issue of 
leakage. However all my issues with this solution have presumed
the primary reason for its use, or at least a major reason, is to
support dynamic routing.

...
...
> If normal behavior in common circumstances would cause this to happen, 
> then the configuration is inherently insecure. 

Or the mechanism. ;-)

> If that possibility can 
> be detected by a config admin tool, then the admin can be warned.

That puts the reliability of security in a tool that needs to look at
more than the SPD, i.e., confirming that IPsec isn't a 'closed bottle'.

> security boundary.  Could you elaborate, without merely referring to 

In our solution, a packet A is forwarded to an encapsulation interface
where it is wrapped B(A) and the result [header=B] is indexed in an SPD
and the result is forwarded.

Dynamic routing, in this case, determines whether A is wrapped with B or
another header (e.g., C). The encryption step - whether involving
routing lookups to resolve the SPD or not - relies on routing table 
entries and SPD entries that are, by _construction_, static, _even in a 
dynamically-routed environment_ (the entries at issue are internal to 
the node, by the way in which we create 'tunneled IPsec traffic' - see 
our ID for those details).

It seems easier to control the interaction between forwarding and IPsec
in the above, notably because dynamic routing would affect only the A->B 
or A->C step.

And as a result, typical changes in the dynamic routing do not affect
whether packets using different paths could go to the incorrect next-hop.

Note that under this solution:

	1. the routing table doesn't determine security policy,
	only IPsec does

	2. correct configuration of the tunnels _does_ involve
	coordianted configuration of the encapsulation and
	encryption steps, but isn't compromised by expected
	routing table changes

> First, we probably do not agree on the extent to which dynamic routing 
> is always going to be a factor here. 

Agreed. We're certainly focusing on support for dynamic routing, or at
least the impact of dynamic routing on any IPsec configuration. The key
issue is that dynamic routing is often enabled independently of IPsec;
coupling them together and describing the constraints is, I believe, a
significant issue that probably warrants a separate document (e.g, our
ID ;-)

However, if your proposed solution precludes dynamic routing altogether, 
it may not be a viable alternative.

> Second, there are means to provide 
> security for routing data. For example, in high assurance contexts where 
> IPsec-like protection is to be employed, it is appropriate to use S-BGP 
> to ensure that the ability to advertise prefixes for the hosts "behind" 
> a security device is done securely, i.e., the advertisements are 
> authorized.

Certainly. However, that would require that this document, beyond adding
forwarding as an explicit step, further describe the scope under which
IPsec could be deployed in dynamically routed environments at all. IMO, 
since there are ways of making security independent of expected routing 
changes while allowing alternate paths for the same packet, further 
limiting the scope of IPsec can and should be avoided.

Joe

---

From: Stephen Kent <[email-masked]>
Date: Mon, 11 Aug 2003 18:17:34 -0400

At 14:45 -0700 8/11/03, Joe Touch wrote:
>Stephen Kent wrote:
>
>>Joe,
>>
>>I believe the bottom line here is that you view situations where 
>>dynamic routing will affect the choice of an SPD as common, whereas 
>>many of us view them as relatively rare.  We each have our own 
>>models of common vs. rare operation and there is probably no point 
>>inn debating further which is more common in what context and/or at 
>>what time (now vs. future).
>
>Steve,
>
>An IP security architecture ought to support IP, which includes 
>dynamic routing. Dynamic routing necessarily involves overlapping 
>traffic selectors; it is a disservice to assert this is a mere 
>'difference of opinions'.
>
>>As I revise the processing model to take into account the comments 
>>I have received, I will try to reword it to be as clear as possible 
>>about the security implications associated with different 
>>assumptions about routing tables and the extent to which they may 
>>change without secure intermediation, as the security implications 
>>of such changes.
>
>That is a good first step, but I remain concerned about whether this 
>realization/clarification warrants other, more significant changes.
>
>Joe

Joe,

I have had considerable experience developing IP layer security 
technology over the last 25 years.  The dynamic routing concerns you 
cite have rarely arisen in those systems, but then they also didn't 
tend to have the equivalent of multiple SPDs. More recently dynamic 
routing has become an issue for some systems of this sort, and the 
need to ensure the security of routing data that will be used in a 
way that might affect security is something that I have personally 
emphasized. One need not even have multiple SPDs or overlapping 
selectors for this to be a concern.

In revising the processing model I will try to accurately reflect these issues.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 11 Aug 2003 16:29:07 -0400

Joe,

I believe the bottom line here is that you view situations where 
dynamic routing will affect the choice of an SPD as common, whereas 
many of us view them as relatively rare.  We each have our own models 
of common vs. rare operation and there is probably no point inn 
debating further which is more common in what context and/or at what 
time (now vs. future).

As I revise the processing model to take into account the comments I 
have received, I will try to reword it to be as clear as possible 
about the security implications associated with different assumptions 
about routing tables and the extent to which they may change without 
secure intermediation, as the security implications of such changes.

Steve

---

From: Joe Touch <[email-masked]>
Date: Mon, 11 Aug 2003 14:45:37 -0700

Stephen Kent wrote:

> Joe,
> 
> I believe the bottom line here is that you view situations where dynamic 
> routing will affect the choice of an SPD as common, whereas many of us 
> view them as relatively rare.  We each have our own models of common vs. 
> rare operation and there is probably no point inn debating further which 
> is more common in what context and/or at what time (now vs. future).

Steve,

An IP security architecture ought to support IP, which includes dynamic 
routing. Dynamic routing necessarily involves overlapping traffic 
selectors; it is a disservice to assert this is a mere 'difference of 
opinions'.

> have received, I will try to reword it to be as clear as possible about 
> the security implications associated with different assumptions about 
> routing tables and the extent to which they may change without secure 
> intermediation, as the security implications of such changes.

Joe

---

From: [email-masked] (Joshua D. Guttman)
Date: 11 Aug 2003 21:44:20 -0400

Stephen Kent <[email-masked]> writes:

>   I have received, I will try to reword it to be as clear as
>   possible about the security implications associated with different

It might be useful to consider the methods described in
"Authentication and Confidentiality via IPsec" (ESORICS, 2000) by
myself, Amy Herzog, and Javier Thayer.  That way people could
establish that certain security goals depend only on specific aspects
of a network's IPsec configuration.  In this case, one knows whether
those goals could be undermined by changes in routing tables.

The paper is available at http://www.ccs.neu.edu/home/guttman, and the
abstract is below.  

More work along this line has been done, including some
implementations to analyze configurations.  Another paper will be
available shortly.

        Joshua 

The IP security protocols (\ipsec) may be used via security gateways
that apply cryptographic operations to provide security services to
datagrams, and this mode of use is supported by an increasing number
of commercial products.  In this paper, we formalize the types of
authentication and confidentiality goal that {\ipsec} is capable of
achieving, and we provide criteria that entail that a network with
particular {\ipsec} processing achieves its security goals.

This requires us to formalize the structure of networks using
{\ipsec}, and the state of packets relevant to {\ipsec} processing.
We can then prove confidentiality goals as invariants of the
formalized systems.  Authentication goals are formalized in the manner
of~\cite{Schneider96}, and a simple proof method using ``unwinding
sets'' is introduced.  We end the paper by explaining the network
threats that are prevented by correct {\ipsec} processing.   

-- 
	Joshua D. Guttman		<[email-masked]>
	MITRE, Mail Stop S119		Office:	+1 781 271 2654
	202 Burlington Rd.		Fax:	+1 781 271 8953
	Bedford, MA 01730-1420 USA	Cell:	+1 781 526 5713