Re: [IPsec] IPsec maintenance/extensions WG?

["balaji raghavan" <[e-mail]>]

To flog the dead(?) horse once more ... :)

The effects of ESP(v3) and AH updates( RFC 4302 and RFC 4303) , for
example ESN and TFC enhancements on Pfkey have to be also considered
.. Though RFC 4718 does clarify the effects of these enhancements on
IKEv2 operation it does leave out pfkey related matters.

Although i do agree that the pfkey API specification does fall out of
the scope of IETF,  for the sake of interop doesn't it atleast warrant
mention in the WG forum ?

-Regards
Balaji

On Tue, Apr 22, 2008 at 10:15 PM, Dan McDonald <[e-mail]> wrote:
> On Tue, Apr 22, 2008 at 03:54:42PM -0400, Chinh Nguyen wrote:
>  > Joy Latten wrote:
>  >
>  > > This may be a moot topic, if so please ignore, but are there any
>  > > plans to improve/extend pfkey for ikev2? Just wondering. :-)
>
>  There's been prodding by some to produce PF_KEYv3.  I've had no cycles, but I
>  do have interest in helping produce a 430x-happy PF_KEYv3.
>
>
>  > There are certainly a number of pfkey issues. For example, linux & bsd
>  > have slightly different implementation of pfkey. Now, this is a impl.
>  > issue not a standards issue but it highlights the fact that people are
>  > wishing to extend pfkey. These extensions typically never made it past
>  > draft, and have since expired.
>
>  Yes - and the BSD and Linux extensions (based on the KAME/WIDE work) are very
>  VERY different than, say, the ones produced in what is now OpenSolaris.  When
>  we opened up OpenSolaris, I blogged about it here:
>
>         http://blogs.sun.com/danmcd/entry/pf_key_in_solaris_or
>
>  Part of that divergence is my fault - when I co-wrote 2367, I was fighting
>  internal IPsec battles at Sun (old-timers on this list know EXACTLY what I'm
>  talking about).  I didn't consider the needs of an actual KMd writer, and I
>  was resistant to anything that to my mind would favor IKEv1 vs. another
>  future KM protocol.  I'd like to think anyone could build JFK, IKEv2, or
>  anything else on top of PF_KEY, as that was the point of PF_KEY in the first
>  place.  2367 as published had several weaknesses, which various extension
>  efforts fixed in their own way.
>
>
>  > A second one is that if you were to attempt to convert an "IKEv2" child
>  > SA to pfkey format, you will find that there are no IANA numbers
>  > assigned to the ipsec side for ENCR_NULL_AUTH_AES_GMAC and
>  > AUTH_AES_[128|192|256]_GMAC
>  > (http://www.iana.org/assignments/ikev2-parameters). This assumes that
>  > pfkey is using the values from
>  > http://www.iana.org/assignments/isakmp-registry, which is true for linux.
>
>  And what's worse --> IKEv2/430x uses slightly different values than
>  IKEv1/240x for algorithms like the SHA-2 family.  Check this out:
>
>  From http://www.iana.org/assignments/ikev2-parameters  -- we have:
>
>      For Transform Type 3 (Integrity Algorithm),
>      defined Transform IDs are:
>      Number    Name                                Reference
>      ------    ---------------------------------   ---------
>           0    NONE                                [RFC4306]
>           1    AUTH_HMAC_MD5_96                    [RFC2403]
>           2    AUTH_HMAC_SHA1_96                   [RFC2404]
>           3    AUTH_DES_MAC                        [RFC4306]
>           4    AUTH_KPDK_MD5                       [RFC1826]
>           5    AUTH_AES_XCBC_96                    [RFC3566]
>           6    AUTH_HMAC_MD5_128                   [RFC4595]
>           7    AUTH_HMAC_SHA1_160                  [RFC4595]
>           8    AUTH_AES_CMAC_96                    [RFC4494]
>           9    AUTH_AES_128_GMAC                   [RFC4543]
>          10    AUTH_AES_192_GMAC                   [RFC4543]
>          11    AUTH_AES_256_GMAC                   [RFC4543]
>          12    AUTH_HMAC_SHA2_256_128              [RFC4868]
>          13    AUTH_HMAC_SHA2_384_192              [RFC4868]
>          14    AUTH_HMAC_SHA2_512_256              [RFC4868]
>
>  But from RFC 4868 we have:
>
>    For IKE Phase 2 negotiations, IANA has assigned the following
>    authentication algorithm identifiers:
>
>    HMAC-SHA2-256:  5
>
>    HMAC-SHA2-384:  6
>
>    HMAC-SHA2-512:  7
>
>
>  So it's DIFFERENT between IKEv1 and IKEv2, and we really would like to keep
>  PF_KEY independent, yet optimized.  This used to be simple, now it's quite
>  hard.  OpenSolaris uses 5-7 for SHA2 in PF_KEY, but when we switch to a fully
>  430x-happy IPsec, we need to consider what to do.
>
>  There are two distinct PF_KEY lists too,  the original one --
>  [e-mail] (Bcc:ing the keeper of that list), and one on vpnc.org.
>
>
>  I think PF_KEY falls outside this or any followup IETF group -- after all the
>  IETF isn't supposed to do APIs last time I checked.  OTOH, there's plenty of
>  fertile ground for feedback into PF_KEYv3.  As I'm learning the hard way how
>  much two implementations have diverged (I'm bringing up racoon2 on
>  OpenSolaris) - I believe there's an opportunity to get it right.  I just hope
>  it doesn't get bloated beyond usability.
>
>  Dan
>
>
> _______________________________________________
>  IPsec mailing list
>  [e-mail]
>  https://www.ietf.org/mailman/listinfo/ipsec
>
_______________________________________________
IPsec mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ipsec