Subject: [karp] Question: splitting RAPD discussion from policy framework discussion in draft-atwood-karp-aapm-rp

From: Sam Hartman <[email-masked]>
Date: Wed, 31 Jul 2013 08:18:21 -0400

Hi.  During the presentation of our draft, I asked Steve Kent whether he
thought it would be valuable to split the discussion of the conseptual
database similar to aspects of the IPsec PAD and SPD from the broader
policy framework.  He said yes.  I said it would be valuable to get
feedback from others about whether this split is useful.  The chairs
asked me to ask on the list.
7

---

From: Stephen Kent <[email-masked]>
Date: Thu, 01 Aug 2013 07:50:57 -0400

I asked that we consider this split because I support adoption of the
discussion of the SPD/PAD-like mechanisms, but do not support the broader,
rather high level policy framework text.

So, count me as one vote for the split.

Steve

> _______________________________________________
> karp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/karp
>

---

From: Russ Housley <[email-masked]>
Date: Thu, 1 Aug 2013 08:13:54 -0400

I agree that it would be valuable to tackle the "broader policy framework."

Russ

---

From: Sam Hartman <[email-masked]>
Date: Thu, 01 Aug 2013 08:51:33 -0400

>>>>> "Russ" == Russ Housley <[email-masked]> writes:

    Russ> I agree that it would be valuable to tackle the "broader
    Russ> policy framework."  Russ

Do you think it would be helpful to split them into a separate document?

---

From: Russ Housley <[email-masked]>
Date: Thu, 1 Aug 2013 08:53:38 -0400

> Do you think it would be helpful to split them into a separate document?

Yes please.

Russ

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 1 Aug 2013 19:05:22 +0000

Great and headed response Steve.

>> support adoption of the discussion of the SPD/PAD-like mechanisms

Conceptually this is critical for IKEv2 integration of RPs and KARP discussions focused 
less on this. 

Though http://datatracker.ietf.org/doc/draft-ietf-karp-crypto-key-table/?include_text=1 
is important for RP integration with IKEv2 but it's not sufficient unless you solve the 
RP policy is given to IKE. At best crypto-tables can be seen as SAD (for some RPs).

FWIW, this is one of the main reasons Gatekeeper was introduced 
http://datatracker.ietf.org/doc/draft-chunduri-karp-using-ikev2-with-tcp-ao/
and presented in earlier IETF meetings. This essentially is the repository of 
the pair wise RP policy to be presented for IKEv2. With out this an IKEv2 responder can't 
get a comprehensive view of what SA it should negotiate, for which traffic selectors and for
which RP.

>> but do not support the broader, rather high level policy framework text.

+10

Also I feel, should not mix RKMP (KMP for pair wise RPs) and MRKMP (KMP for group keying RPs) 
and attempt to create a high level policy frame work. I believe, this can severely complicate things 
rather than helping in actual implementation and usage.

This is what I propose:

1. Policy framework for pair-wise RPs which use RFC 5996 [IKEv2]
           - It's been in the discussion for quite a while in KARP and 
             the draft I mentioned above
2. Policy framework for group keying RPs which use variant of IKEv2 
   (any draft close to publication which can get us there??)
3. We should try to use PAD as is (most of it) to leverage existing IKEv2 code base

-- 
Uma C. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Kent
Sent: Thursday, August 01, 2013 4:51 AM
To: [email-masked]
Subject: Re: [karp] Question: splitting RAPD discussion from policy framework discussion in draft-atwood-karp-aapm-rp

I asked that we consider this split because I support adoption of the discussion of the SPD/PAD-like mechanisms, but do not support the broader, rather high level policy framework text.

Steve

> Hi.  During the presentation of our draft, I asked Steve Kent whether 
> he thought it would be valuable to split the discussion of the 
> conseptual database similar to aspects of the IPsec PAD and SPD from 
> the broader policy framework.  He said yes.  I said it would be 
> valuable to get feedback from others about whether this split is 
> useful.  The chairs asked me to ask on the list.
> 7