headers
Mark Duffy | 1 Aug 2003 16:29

Re: revised IPsec processing model

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.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Mark Duffy | 1 Aug 2003 17:20

Re: revised IPsec processing model

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:
(Continue reading)

Permalink | Reply | 2 comments |
headers
Scott G. Kelly | 1 Aug 2003 17:40

Re: revised IPsec processing model


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
Permalink | Reply | 0 comments |
headers
Internet-Drafts | 1 Aug 2003 17:23
Picon
Favicon

I-D ACTION:draft-ietf-ipsec-ui-suites-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Protocol Working Group of the IETF.

	Title		: Cryptographic Suites for IPsec
	Author(s)	: P. Hoffman
	Filename	: draft-ietf-ipsec-ui-suites-03.txt
	Pages		: 5
	Date		: 2003-7-31
	
The IPsec, IKE, and IKEv2 protocols rely on security algorithms to
provide privacy and authentication between the initiator and responder.
There are many such algorithms available, and two IPsec systems cannot
interoperate unless they are using the same algorithms. This document
specifies optional suites of algorithms and attributes that can be used
to simplify the administration of IPsec when used in manual keying mode,
with IKE version 1, or with IKEv2.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ui-suites-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ipsec-ui-suites-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Charlie_Kaufman | 1 Aug 2003 21:10
Picon

Proposed resolution to Issue 1


(apologies if this is a duplicate. I sent this two days ago and it never
came back to me from the list).

      --Charlie

Issue 1 notes that it is not clear when a newly created SA can be used. I
propose adding the following text to the end of Section 2.8:

There are timing windows - particularly in the presence of lost packets -
where endpoints may not agree on the state of an SA. The responder to
a CREATE_CHILD_SA MUST be prepared to accept messages on an SA before
sending its response to the creation request, so there is no ambiguity
for the initiator. The initiator may begin sending on an SA as soon as
it processes the response. The initiator, however, cannot receive on a
newly created SA until it receives and processes the response to its
CREATE_CHILD_SA request. How, then, is the responder to know when it is
OK to send on the newly created SA?
.sp
From a technical correctness and interoperability perspective, the
responder MAY begin sending on an SA as soon as it sends its response
to the CREATE_CHILD_SA request. In some situations, however, this could
result in packets unnecessarily being dropped, so an implementation MAY
want to defer such sending.
.sp
The responder can be assured that the initiator is prepared to receive
messages on an SA if either (1) it has received a cryptographically valid
message on the new SA, or (2) the new SA rekeys an existing SA and it
receives an IKE request to close the replaced SA. When rekeying an SA,
the responder SHOULD continue to send requests on the old SA until it
(Continue reading)

Permalink | Reply | 1 comment |
headers
Stephen Kent | 1 Aug 2003 22:49
Picon

Re: revised IPsec processing model

At 10:29 -0400 8/1/03, Mark Duffy wrote:
>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.

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

>>   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:
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stephen Kent | 1 Aug 2003 23:33
Picon

Re: revised IPsec processing model

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Duffy | 2 Aug 2003 20:55

Re: revised IPsec processing model

At 04:49 PM 8/1/2003 -0400, Stephen Kent wrote:
[snip]
>>>   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.
>
>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.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mark Duffy | 2 Aug 2003 20:31

Re: revised IPsec processing model

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,
>
>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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Richardson | 4 Aug 2003 17:19
Picon

MS IPR on ikev2-08


http://www.ietf.org/ietf/IPR/microsoft-ipr-draft-ietf-ipsec-ikev2.txt

claims something. I can't figure out what it is. Section 7 says nothing
about the specifics either. I thought that IDs were supposed to list what
the specific area was, but not who was claiming things.

A royalty-free, RAND license that is *field specific*, is generally believed
to be incompatible with the GPL.

]      Out and about in Ottawa.    hmmm... beer.                |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr <at> sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy");  [
Permalink | Reply | 0 comments |

Gmane