Subject: Re: pf_policy -- what is it?

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 27 Mar 2001 16:05:26 -0500

> Is this perhaps related to PF_KEY extensions, to
> cover policy (or to get rid of policy as I did
> once upon time in a now-expired I-D)? 

Policy does not belong in PF_KEY.

> Or a new PF interface for conveying policy to a kernel?

Yes.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 28 Mar 2001 00:00:19 +0300

Hi. I couldn't make it to the IPSP WG meeting
last monday due to some other meetings, but
I noticed the following item in Luis Sanchez's
"next steps" discussion:

 >- Publish PF_POLICY draft

May I ask what this is, in more detail? I can't
find anything related to in the look that I have
taken to the archives, nor did I find anything
from relating to this from the internet drafts
directory.

Is this perhaps related to PF_KEY extensions, to
cover policy (or to get rid of policy as I did
once upon time in a now-expired I-D)? Or a
new PF interface for conveying policy to a
kernel? Or something else?

Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 28 Mar 2001 00:37:30 +0300

>> Or a new PF interface for conveying policy to a kernel?

Aa. Do you have any more details? Is
there anything written on this subject yet?
Any requirements? What's the plan? Anything?

[One conclusion that I've personally come
to is that kernels shouldn't know too much
of policy; only the necessary parts. For
instance, I they should know which traffic
patterns should trigger key management actions,
but they do not necessarily need to to know
proposal lists sent in km protocols etc.]

Jari

---

From: "Luis A. Sanchez" <[email-masked]>
Date: Tue, 27 Mar 2001 20:09:43 -0600

> Any requirements? What's the plan? Anything?

One step at the time. No, we don't have a first draft written yet. Bill
Sommerfeld is the draft editor. The goal is to begin discussion of this
work in this list. So, if you have done any work in this area please
share this with the list. The plan is to have a first draft written
before London.

> proposal lists sent in km protocols etc.]

- Agree.

---

From: "Luis A. Sanchez" <[email-masked]>
Date: Tue, 27 Mar 2001 20:04:17 -0600

Jari,

PF_POLICY would be a new socket protocol family used by privileged
policy applications to communicate with an operating system's policy
management internals.  PF_KEY is analogous to PF_ROUTE and PF_KEY.

Luis

---

From: Jari Arkko <[email-masked]>
Date: Wed, 28 Mar 2001 17:15:25 +0300

Luis A. Sanchez wrote:

> share this with the list. 

Well, I haven't really worked exactly on this
problem, but I have done some previous work
on a related area. Namely, I had this idea
about what should be in the kernel and what
not, and based on that I modified the PF_KEY
protocol in manner. I realize the PF_KEY as
such isn't interesting in this discussion, but
the model behind may be.

The draft is expired but can be accessed
at [1]. The basic idea was that kernels only
store policy information regarding traffic
patterns, and then use _opaque references_
to some policy identifiers, that are then
treated on a higher level, in policy and
key management apps. Only they would know
about things like proposal lists and so on.
The traffic patterns on the other hand,
_have_ to be known by the kernel, otherwise
they can't match a packet and decide what to
do.

The draft was partially also grown from
frustration to current PF_KEY (RFC 2367)
which doesn't completely support all features
needed in IPsec, and extending it to do
e.g. bundles seems to lead to a complicated
design unless something drastic such as
removal of policy information from it and the
kernel is done.

I think the discussion of what exactly should
go to the kernel through this PF_POLICY is
the first priority item in designing PF_POLICY.
Maybe some of the ideas above could be reused
here; in any case I'd be happy to participate
in the discussion.

Jari

[1]
http://www.arkko.com/publications/draft-arkko-pfkey-reference-00.txt