Subject: [IPsec] PFP flag in rfc 4301

From: Joy Latten <[email-masked]>
Date: Tue, 26 Feb 2008 14:45:23 -0600

The rfc 4301 describes Populate-from-Packet feature.
I could not readily determine if it is something SPD
or IPsec implementation MUST have or SHOULD have?

regards,
Joy
_______________________________________________
IPsec mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ipsec

---

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 26 Feb 2008 12:59:55 -0800

Hi Joy,

In my view as PFP is not a signaled element, we do not support PFP is
the implementation does not require it. It is a local matter of a
particular application.

RFC4301 states:
   The form of the database and its interface are outside the
   scope of this specification. However, this section specifies minimum
   management functionality that must be provided, to allow a user or
   system administrator to control whether and how IPsec is applied to
   traffic transmitted or received by a host or transiting a security
   gateway.

So in my view depending on the implementation you could or not support PFP.

Thanks,
Vishwas

---

From: Stephen Kent <[email-masked]>
Date: Tue, 26 Feb 2008 21:45:24 -0500

>or IPsec implementation MUST have or SHOULD have?

PFP is part of the description of an SPD entry. 4301 does not mandate 
a specific SPD entry format, BUT it does require that a compliant 
implementation be able to operate as though the SPD is implemented as 
defined in the SPD model. So, for example,if your implementation 
offers as way to configure the SPD to trigger creation of a different 
SA for each TCP connection between the same 2 IP addresses, a feature 
that PFP allows, then you would be probably be compliant. If not, 
then you are not.

Steve

P.S. Vishwas's observation that "In my view as PFP is not a signaled 
element, we do not support PFP is the implementation does not require 
it." is not correct.  Many aspects of the SPD/SAD model defined in 
4301 are not signalled explicitly. The criteria for conformance is 
how the implementation  behaves, not only as seen by a peer, but also 
as seen by a user/app.
_______________________________________________
IPsec mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ipsec

---

From: Dan McDonald <[email-masked]>
Date: Tue, 26 Feb 2008 21:58:25 -0500

> that PFP allows, then you would be probably be compliant. If not, 

<plug>

Those in the audience who wish to see an example, please check out the "sa
unique" keyword pair in OpenSolaris's ipsecconf(1M) command, and look for
"unique" in various bits of IPsec SPD code in the OpenSolaris kernel.

</plug>

Dan

---

From: Yoav Nir <[email-masked]>
Date: Wed, 27 Feb 2008 10:29:37 +0200

> how the implementation  behaves, not only as seen by a peer, but also

That is correct, but it is possible for a particular implementation  
not to offer all the rich configurability suggested by RFC 4301. For  
example, you can have the traffic selectors pre-configured, and always  
use those subnets. In RFC 4301 terms, you can have all the PFP flags  
set to false, and not allow the user to configure them.  That is a  
user interface consideration that does not harm interoperability.

Just as you don't usually allow users to configure the nonce size in  
IKE.
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Stephen Kent <[email-masked]>
Date: Wed, 27 Feb 2008 04:00:47 -0500

At 10:29 AM +0200 2/27/08, Yoav Nir wrote:
>...

Yes, but such an implementation would be non-compliant with 4301. The 
reason we mandate that an enumerated list features be manageable is 
to ensure a certain minimum functionality. When I checked on early 
IPsec implementations at Interop one year, several did not allow all 
five traffic selectors to be specified for SPD entries. They were 
clearly non-compliant. The Microsoft implementation did not allow the 
SPD entries to be manually sorted; they defined their own notion of 
"more specific/general" to impose a total ordering on the SPD. That 
was also non-compliant, as it clearly limited the set of policies a 
user (or admin) could define.

Steve

---

From: Joy Latten <[email-masked]>
Date: Wed, 27 Feb 2008 10:08:47 -0600

> how the implementation  behaves, not only as seen by a peer, but also 

Ok, thanks. This helps with understanding how to read and interpret
the rfc and hopefully implement correctly. :-)

regards,
Joy

---

From: "Vishwas Manral" <[email-masked]>
Date: Wed, 27 Feb 2008 11:00:36 -0800

Hi Stephen,

I sort of agree with Yaov here. IETF should work towards getting
inter-operable implementations over the wire. If a vendor does not
need some fields in the SPD and can still give the same and correct
external behavior that should not be prevented (like in the PFP case).

It is now up to the customer to see if the SPD local information is
good enough for him. We should not dictate the behavior within a
device - I do not see why the behavior would be non-compliant to
RFC4301 - as you yourself state there are implementations that support
the external behavior but not the internal structures. By limiting the
definition unnecessarily we are excluding a lot of implementations
from being compliant. This seems to be the popular refrain in most
other protocols in the IETF on which I have worked on too.

Thanks,
Vishwas

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 27 Feb 2008 13:16:04 -0600

> other protocols in the IETF on which I have worked on too.

I think it's perfectly reasonable for the IETF to include some local
interface requirements.  In fact, we do that in a number of places.

I think requiring PFP support is perfectly OK and even desirable.

Finally, there's no IETF compliance police, and no IETF compliance
testing.  There is interop testing (to move to a spec from Draft
Standard to Standard), but its purpose is not to establish compliance by
implementations, rather it is to establish that for any one required
feature of the protocol there are two or more interoperable
implementations.  Of course, there can be consortia and other third
parties to establish compliance with RFCs and STDs, but they need not
(do not) have formal relationships with the IETF.  But then, nothing
stops your competitors (and customers) from advertising accurate
compliance information.

Nico
--

---

From: Stephen Kent <[email-masked]>
Date: Wed, 27 Feb 2008 19:37:06 -0500

>external behavior that should not be prevented (like in the PFP case).

Interoperability is the primary focus of most IETF standards, but not 
the only one. In the case of IPsec there was agreement by the WG that 
it was appropriate to mandate support for certain features even if 
they were not visible to a peer.  Also, if one defines "external 
behavior" to include the features seen by an admin or user trying to 
manage SAs, then PFP qualifies. It is up to a user/admin, not a 
vendor, to decide which features to turn on; a vendor is obligated to 
offer the features. Look at the PKIX specs for analogies re what a 
compliant CA or client MUST be able to do, vs. what a specific CA or 
user (client) may choose to make use of.

>other protocols in the IETF on which I have worked on too.

The implementation is non-compliant because the vendor decided o 
behalf of the user which of the mandated features of the SPD it 
though was important.

RFC 4301 does NOT mandate use of any specific internal structures; 
however, if there is an external management feature that is enabled 
by the model in 4301 and an implementation if not able to offer that 
feature to a (local) user/admin, then the implementation is 
non-compliant, for the reasons cited above.

Compliance is not a popularity contest. If it were, all Microsoft and 
Cisco products would be compliant, by definition of the massive 
market share each of these vendors represents.

Steve