Re: [IPsec] NUDGE: Starting work on our new charter items

2012-01-30 Thread Paul Hoffman
On Jan 29, 2012, at 5:11 PM, Stephen Hanna wrote:

 Sorry to be late in responding. I've been working with other
 Juniper folks to figure out which of us should volunteer to
 edit the P2P VPN problem statement. But never mind about that.
 
 I am willing to edit the P2P VPN problem statement document.
 I know that we need to have a draft promptly and get some serious
 discussion going on the email list before IETF 83. There are
 plenty of interesting questions related to requirements that
 we'll want to discuss on the list and in person at IETF 83.
 
 Praveen Sathyanarayan from Juniper has already committed to
 write an Informational RFC documenting our current solution.
 And I think it's premature to start work on the common
 solution before we've agreed on the problem statement or
 at least nailed down the main issues. Don't you agree?

Indeed. But we need to be sure there is enough interest in even nailing down 
the main issues. So, thank you for your willingness to edit the problem 
statement: that gets it going.

How many people here will commit publicly to review drafts of the problem 
statement and contribute ideas such as this should be a requirement and that 
thing there should not be a requirement?

--Paul Hoffman

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt

2012-01-30 Thread Stephen Kent

At 4:39 PM +0800 1/29/12, zong.zaif...@zte.com.cn wrote:

Hi Stephen, Tricci:

Sorry that I didn't respond this email on time due to the chinese 
spring festival. I would like to thank Stephen first for reviewing 
the draft and giving me your suggestions.


no problem. Happy New Year.

From reading Stephen's email, if my understanding is correct, you 
assumed that SeGW will pass some information to the core network in 
order that the core network can verify the notarized FAP 
information? And you think that the information exchange betwen SeGW 
and the core network is a big change to IKE, is this correct 
understanding of your email?


not quite. I was wrong to suggest that the SecGW sent the signed data 
directly to the core network. The data that the SecGW signs is 
presented by the FAP to the core network. My principle concern is 
that it is inappropriate to use an
IKE payload to transport data to be signed, and then the signed data, 
when the consumer of this data is not IPsec. IKE payloads are used to 
convey data needed to create and manage SAs, including key material, 
data for authentication, etc. This signed data appears to be for 
authorization decisions effected by some element of the core network, 
outside of the IPsec SA itself.


I understand that this configuration based assumption may have some 
limits, I think that to generate a cert by the SeGW and send it to 
the FAP and then from the FAP to the core network is a good 
implementation option. Perhaps I should make the CP flexible enough 
to adapt to all the implementation options. If you have any good 
idea on how the CP should be designed, could you kindly give me your 
suggestion?


I don't want to suggest design options for you, as I am not familiar with
the environment in which you are working. Also, lots of flexibility 
may not be a good ideas in a secruity context. I'm merely suggesting 
that using IKE payloads seems inappropriate for what I believe you 
are trying to do, based on reading one very brief document.


Steve
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec