From tso@zteusa.com Wed Feb 1 00:49:32 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 233DB21F8581 for ; Wed, 1 Feb 2012 00:49:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.662 X-Spam-Level: X-Spam-Status: No, score=-0.662 tagged_above=-999 required=5 tests=[AWL=1.176, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYhAIf5r1dW8 for ; Wed, 1 Feb 2012 00:49:30 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id EFC9321F8577 for ; Wed, 1 Feb 2012 00:49:29 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 566905521606; Wed, 1 Feb 2012 16:24:04 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 5467.36512999; Wed, 1 Feb 2012 16:49:19 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q118nC4d082656; Wed, 1 Feb 2012 16:49:12 +0800 (GMT-8) (envelope-from tso@zteusa.com) In-Reply-To: References: To: Stephen Kent MIME-Version: 1.0 X-KeepSent: D9B99304:EA2EA371-88257997:002EE1D2; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: tso@zteusa.com Date: Wed, 1 Feb 2012 00:46:46 -0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-02-01 16:49:13, Serialize complete at 2012-02-01 16:49:13 Content-Type: multipart/alternative; boundary="=_alternative 003072C088257997_=" X-MAIL: mse01.zte.com.cn q118nC4d082656 Cc: ipsec@ietf.org, zong.zaifeng@zte.com.cn Subject: Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 08:49:32 -0000 This is a multipart message in MIME format. --=_alternative 003072C088257997_= Content-Type: text/plain; charset="US-ASCII" Dear Stephen, Sincerely thanks for your patient to provide us so much inputs for this draft. Now I understand of your consideration of the cert approach. But I must confess that it is still not clear to me how are we going to use the cert as your suggested to address our problem. Since ZaiFeng is back from holiday. I will leave it to you and her to discuss further on this subject. Truly appreciate your kind advice, always. Cheers. Tricci Stephen Kent 01/30/2012 07:00 AM To tso@zteusa.com cc ipsec@ietf.org, zong.zaifeng@zte.com.cn, tso@zteusa.com Subject Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt At 9:31 PM -0800 1/26/12, tso@zteusa.com wrote: ... Tricci > Fully agree with you that, we need to make a proposal to be consistent with IETF standards. In addition, I am also hoping you would agree that, as the solution is proposed to fix a generic issue for Femto network, we need to also consider the impact of the final solution towards the Femto's existing deployment as long as we did not break IKE. Would this be acceptable to you? yes, so long as the proposed solution makes good use of existing IETF standards, or proposes new ones where existing standards are not applicable. ... Tricci > The reason that we choose the words "notarization" because the design of this proposal is to have a trusted-party (i.e. SeGW) of the target network (i.e. Mobile Core Network) to notarize the untrusted-party (i.e. FAP) so that the untrusted-party can leverage the trusted-party's notarized signature to be present to the target network to gain its trust and confident on the identity of the untrusted party as well as the info presented by the untrusted party to the target network. This approach is very similar to today notarization process in the legal process. There is an analogy to notarization in the legal sense, but in the technical context, the function performed by the SecGW is highly analogous to that of a CA or AA. Tricci > However, if you truly feel strongly against this word, we don't really have strong opinion on this one. We respect your expertise to suggest the better wording for us. I think it is preferable to use terms that relate to existing, very relevant security technologies, when one makes a technical proposal such as this. Tricci > One important aspect that I would like to clarify is that, in our perspective, the info that is carried by the IKE is not really an opaque. In our perspective, the info is just not defined by IETF, but by the network/SDO which is responsible to utilize such solution to define the content of the info. If you think that it is necessary, we can add the note to the draft to specify that, whichever the network solution or SDO that chooses to use this solution must indicate what are the info which will be conveyed between the two IKE peers in advance. For example, if 3GPP decides to use this IKE feature as described in this draft to mitigate the FAP security issue, 3GPP should specify what and how the info is carried by the CP. If different technologies carry different data in the same IKE payload, that is questionable. The content of a payload should be evident from the payload ID. And the content should be defined in an IETF doc, if it is not vendor-specific. ... Tricci > It is important to point out that, the SeGW does NOT pass on the CP info to the Mobile core network. What was described in the draft is that: Tricci > (1) FAP (i.e. IKE-initiator) includes the "Client Notarized Info" in the CP-Request during the mutual authentication exchange to SeGW (i.e. IKE-Responder) the SecGW sends the signed data to the FAP, which passes it to the core network. So the SecGW is passing the data to the core network via the FAP. I was not clear in my comment. Tricci > (2) Once the SeGW authenticates the FAP (i.e. successful authentication), the SeGW will then notarize the info to derive "Server Notarized Signature" (algorithm is determined by network operator or standard SDO) which will then be included in the CP-Reply to the FAP. again, this seems to be a case where the full spec of what is being carried by IKE should be defined in RFCs. Using IKE to transport arbitrary data, specified by other SDOs, is questionable. Tricci > (3) FAP will then include this Server Notarized Signature info in its own control signaling communication with the mobile core network which deploys the SeGW. The FAP's signaling contains the SeGW's Notarized Signature and they are encapsulated within the IPsec tunnel. Hence, SeGW is NOT involved in passing the CP's info to the Mobile Core Network. see my reply above. ... Tricci > If I understand your proposal correctly, you suggested to have the SeGW to generate the additional cert to be used by the FAP to present to the target network, isn't it? Tricci > Unfortunately, this approach does not address the issue that we are trying to resolve. First of all, both FAP and SeGW already have their own certs to support their mutual authentication. Secondly, the new cert that you proposed will not contain the "specific" info that we require for the SeGW to certify/notarize for the FAP such that the FAP can present the certified/notarized info to the target mobile core network. how can you say that a new cert, the content of which I did not describe, will not contain the "specific info" required? the intent of having the SecGW generate a cert for the FAP is to put the appropriate info into it. Tricci > In summary, what we are trying to achieve is to have the SeGW, which is the trusted party of the Mobile Core network, to certify/notarize the "specific" configuration and access control info provided by the FAP to be notarized by the SeGW. This is how the Mobile Core network to verify the FAP's true identity and the associated info provided by the FAP is trust-worthy. Perhaps I don't understand the term "specific" here. The SecGW must understand the data provided by the FAP, otherwise it cannot verify and sign it. Can you provide example of the data that is to be signed, for 3GPP and LTE? Maybe that would help. Tricci > As for your last sentence above saying "That way the SecGW would not have to pass on data to the core network.". Again, please note that SeGW does NOT explicitly pass the CP info to the Mobile Core Network, it is the FAP to include the notarized signature in its signaling which is part of the IPsec payload to be sent to the Mobile Core network. Yes, I understand. ... Tricci > I hope that you can understand that what you described above is NOT what we proposed. Thank you for your comments. I understand that you propose using a single IKE payload to transport arbitrary data, data that will differ based on network context, and that the IKE entities at the SecGW and the FAP are NOT the consumers of this info. That seems like a bad use of IKE. Steve -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 003072C088257997_= Content-Type: text/html; charset="US-ASCII" Dear Stephen,

Sincerely thanks for your patient to provide us so much inputs for this draft.  

Now I understand of your consideration of the cert approach.  But I must confess that it is still not clear to me how are we going to use the cert as your suggested to address our problem.

Since ZaiFeng is back from holiday.  I will leave it to you and her to discuss further on this subject.  

Truly appreciate your kind advice, always.  Cheers.
Tricci



Stephen Kent <kent@bbn.com>

01/30/2012 07:00 AM

To
tso@zteusa.com
cc
ipsec@ietf.org, zong.zaifeng@zte.com.cn, tso@zteusa.com
Subject
Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt





At 9:31 PM -0800 1/26/12, tso@zteusa.com wrote:
...

Tricci > Fully agree with you that, we need to make a proposal to be consistent with IETF standards.  In addition, I am also hoping you would agree that, as the solution is proposed to fix a generic issue for Femto network, we need to also consider the impact of the final solution towards the Femto's existing deployment as long as we did not break IKE.  Would this be acceptable to you?  

yes, so long as the proposed solution makes good use of existing IETF standards,
or proposes new ones where existing standards are not applicable.

...

Tricci > The reason that we choose the words "notarization" because the design of this proposal is to have a trusted-party (i.e. SeGW) of the target network (i.e. Mobile Core Network) to notarize the untrusted-party (i.e. FAP) so that the untrusted-party can leverage the trusted-party's notarized signature to be present to the target network to gain its trust and confident on the identity of the untrusted party as well as the info presented by the untrusted party to the target network. This approach is very similar to today notarization process in the legal process.  

There is an analogy to notarization in the legal sense, but in the technical context, the function performed by the SecGW is highly analogous to that of a CA or AA.

Tricci > However, if you truly feel strongly against this word, we don't really have strong opinion on this one.  We respect your expertise to suggest the better wording for us.

I think it is preferable to use terms that relate to existing, very relevant security technologies, when one makes a technical proposal such as this.

 Tricci > One important aspect that I would like to clarify is that, in our perspective, the info that is carried by the IKE is not really an opaque.  In our perspective, the info is just not defined by IETF, but by the network/SDO which is responsible to utilize such solution to define the content of the info.   If you think that it is necessary, we can add the note to the draft to specify that, whichever the network solution or SDO that chooses to use this solution must indicate what are the info which will be conveyed between the two IKE peers in advance.  For example, if 3GPP decides to use this IKE feature as described in this draft to mitigate the FAP security issue,  3GPP should specify what and how the info is carried by the CP.    

If different technologies carry different data in the same IKE payload, that
is questionable. The content of a payload should be evident from the payload ID. And the content should be defined in an IETF doc, if it is not vendor-specific.

 ...

Tricci > It is important to point out that, the SeGW does NOT pass on the CP info to the Mobile core network.  What was described in the draft is that:
Tricci > (1) FAP (i.e. IKE-initiator) includes the "Client Notarized Info" in the CP-Request during the mutual authentication exchange to SeGW (i.e. IKE-Responder)

the SecGW sends the signed data to the FAP, which passes it to the core network. So the SecGW is passing the data to the core network via the FAP. I was not clear in my comment.

Tricci > (2) Once the SeGW authenticates the FAP (i.e. successful authentication), the SeGW will then notarize the info to derive "Server Notarized Signature" (algorithm is determined by network operator or standard SDO) which will then be included in the CP-Reply to the FAP.  

again, this seems to be a case where the full spec of what is being carried by IKE should be defined in RFCs. Using IKE to transport arbitrary data, specified by other SDOs, is questionable.

Tricci > (3) FAP will then include this Server Notarized Signature info in its own control signaling communication with the mobile core network which deploys the SeGW.  The FAP's signaling contains the SeGW's Notarized Signature and they are encapsulated within the IPsec tunnel.  Hence, SeGW is NOT involved in passing the CP's info to the Mobile Core Network.

see my reply above.


...

Tricci > If I understand your proposal correctly, you suggested to have the SeGW to generate the additional cert to be used by the FAP to present to the target network, isn't it?  
Tricci > Unfortunately, this approach does not address the issue that we are trying to resolve.  First of all, both FAP and SeGW already have their own certs to support their mutual authentication.  Secondly, the new cert that you proposed will not contain the "specific" info that we require for the SeGW to certify/notarize for the FAP such that the FAP can present the certified/notarized info to the target mobile core network.

how can you say that a new cert, the content of which I did not describe, will not contain the "specific info" required? the intent of having the SecGW generate a cert for the FAP is to put the appropriate info into it.

Tricci > In summary, what we are trying to achieve is to have the SeGW, which is the trusted party of the Mobile Core network, to certify/notarize the "specific" configuration and access control info provided by the FAP to be notarized by the SeGW.  This is how the Mobile Core network to verify the FAP's true identity and the associated info provided by the FAP is trust-worthy.  

Perhaps I don't understand the term "specific" here. The SecGW must understand the data provided by the FAP, otherwise it cannot verify and sign it. Can you provide example of the data that is to be signed, for 3GPP and LTE? Maybe that would help.

Tricci > As for your last sentence above saying "That way the SecGW would not have to pass on data to the core network.".  Again, please note that SeGW does NOT explicitly pass the CP info to the Mobile Core Network, it is the FAP to include the notarized signature in its signaling which is part of the IPsec payload to be sent to the Mobile Core network.

Yes, I understand.

...

Tricci > I hope that you can understand that what you described above is NOT what we proposed.  Thank you for your comments.

I understand that you propose using a single IKE payload to transport arbitrary data, data that will differ based on network context, and that the IKE entities at the SecGW and the FAP are NOT the consumers of this info. That seems like a bad use of IKE.

Steve 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 003072C088257997_=-- From tso@zteusa.com Wed Feb 1 01:01:40 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE4021F877C; Wed, 1 Feb 2012 01:01:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_DOUBLE_IP_LOOSE=0.76] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nx7pIoyROk6G; Wed, 1 Feb 2012 01:01:39 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id D5F3521F877E; Wed, 1 Feb 2012 01:01:37 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 56690433787882; Wed, 1 Feb 2012 16:35:35 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 27725.1725263410; Wed, 1 Feb 2012 17:01:16 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q1191J8p039350; Wed, 1 Feb 2012 17:01:19 +0800 (GMT-8) (envelope-from tso@zteusa.com) In-Reply-To: <000001cce005$2833bf40$789b3dc0$%pothulam@huawei.com> References: <000001cce005$2833bf40$789b3dc0$%pothulam@huawei.com> To: dharmanandana.pothulam@huawei.com MIME-Version: 1.0 X-KeepSent: 3557A2A2:F048A779-88257997:002B69A0; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: tso@zteusa.com Date: Wed, 1 Feb 2012 00:58:54 -0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-02-01 17:01:22, Serialize complete at 2012-02-01 17:01:22 Content-Type: multipart/alternative; boundary="=_alternative 00318F1988257997_=" X-MAIL: mse02.zte.com.cn q1191J8p039350 Cc: ipsec@ietf.org, ipsec-bounces@ietf.org, zong.zaifeng@zte.com.cn Subject: Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 09:01:40 -0000 This is a multipart message in MIME format. --=_alternative 00318F1988257997_= Content-Type: text/plain; charset="US-ASCII" Dear Dharmanandana, Thank you for your clarification. Yes, as YinXing's understanding, once the FAP and SeGW are mutually authenticated, the SeGW will then notarize the info that was provided by FAP (in Client_Notarized_Info) into a form of signature, and the signature will then be fed back to the FAP. In the Femto architecture, there is a direct interface between the FAP and the Mobile Core Network. The signaling path between the FAP and the Mobile Core Network is protected by the IPsec tunnel that was established between the FAP and SeGW. The FAP will then imbedded the SeGW's notarized signature into FAP signaling communication with the Mobile Core Network of which the signaling is part of the IPSec payload. Hence, it is totally transparent to the SeGW. The notarized signature is just containing some FAP's specific configuration info - i.e. NOT every single packet between the FAP and the Mobile Core Network will be notarized. It is a very small specific configuration info regarding to FAP which is specific to the particular mobile technology (i.e. 3GPP, 3GPP2, WiMAX etc.) and the corresponding mobile operator. Hoping that I was able to answer your question clearly. As ZaiFeng is back from her holiday. I will leave the rest of further question back to her. Sincerely thanks for your kind attention to this draft. Cheers. Tricci Dharmanandana Reddy Pothula Sent by: ipsec-bounces@ietf.org 01/31/2012 02:43 AM Please respond to dharmanandana.pothulam@huawei.com To tso@zteusa.com cc ipsec@ietf.org, ipsec-bounces@ietf.org, zong.zaifeng@zte.com.cn Subject Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt Hi Tricci, Thanks for your explanation. I get your point why notarized signature required, but my question is not about notarizing every packet. Let me ask my question in different way, Is FAP sends notarized signature in every IPSec packet to core network? As I understand from the draft that before accepting every IPSec packet, core network validate the notarized signature. Where is this notarized signature placed in every IPSec packet? Thanks, Dharmanandana Reddy Pothula From: tso@zteusa.com [mailto:tso@zteusa.com] Sent: Wednesday, January 25, 2012 1:26 PM To: dharmanandana.pothulam@huawei.com Cc: ipsec@ietf.org; ipsec-bounces@ietf.org; zong.zaifeng@zte.com.cn; tso@zteusa.com Subject: Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipse cme-ikev Dear Dharmanandana, I hope that I address you correctly. If not, please pardon my ignorance. As this week is spring festival, ZaiFeng is not available. Hence, I would like to respond to you on behalf of her. Could you please kind see my responses to you inline below. Many thanks. Tricci 5pt;font-family:"Arial","sans-serif"'>Dharmanandana Reddy Sent by: ipsec-bounces@ietf.org 01/24/2012 04:04 AM Please respond to dharmanandana.pothulam@huawei.com To zong.zaifeng@zte.com.cn cc ipsec@ietf.org Subject Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt Hi Zaifeng, I have following questions and concerns about your proposed solution "The FAP will then send the FAP information together with the corresponding SeGW notarized signature to its mobile operator's core network. The core network verifies the FAP information by validating the SeGW notarized signature prior to the acceptance of the information". Is every ip packet carries SeGW notarized signature after server sends notarized signature to the client? if not, what's the point in returning notarized signature to the client? I believe yes, if so, It will increase percentage of overhead per packet and may impact quality of real time voice and video. Tricci > You ask a very legitimate question. May be our draft is not clear enough to explain the main motivation of this draft for target of the attack. Tricci > The main concern is not about the attack for "unauthorized FAP" to send any data to the mobile core network. The main concern is about the attack of the "unauthorized FAP" to send the "false" configuration information (e.g. such as changing the FAP from "Closed" to become "O pen" ;false" access control related information (e.g. allowing a 3GPP UE which is supposed to be allowed to access the FAP and to have the access privileage to the FAP - i.e. CSG info alteration, etc.). Once the FAP's configuration and access control management are authenticated via the support of the notarization by the SeGW, then, the rest of the 3GPP UEs' access to the FAP can follow the existing access control and UE-based authentication/authorization procedures at the UE level's. Tricci > Of course, once the UE is authenticated and to allow access to the FAP, whatever the UE sends is beyond the control of the FAP just as what is happened today for any mobile device. Isn't it? if every ip packet carries SeGW notarized signature, How and where this signature carried inside ip packet? cations inside IPsec packet processing? Is this processing happens outside of IPsec? is it outside scope of this document? It would be great, if some of these aspects are addressed in the draft. Tricci > Since I have already explained to you that, we are not proposing to notarize every single packet sent by FAP. Hence, I don't think that I need to respond to your rest of the questions above. Tricci > THANK YOU for asking a good question. Cheers. Thanks, Dharmanandana Reddy Pothula. & yle='font-size:10.0pt;font-family:"Arial","sans-serif"'> _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. R ecipient bsp;are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system._______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 00318F1988257997_= Content-Type: text/html; charset="US-ASCII" Dear Dharmanandana,

Thank you for your clarification.  

Yes, as YinXing's understanding, once the FAP and SeGW are mutually authenticated, the SeGW will then notarize the info that was provided by FAP (in Client_Notarized_Info) into a form of signature, and the signature will then be fed back to the FAP.  

In the Femto architecture, there is a direct interface between the FAP and the Mobile Core Network.  The signaling path between the FAP and the Mobile Core Network is protected by the IPsec tunnel that was established between the FAP and SeGW.  

The FAP will then imbedded the SeGW's notarized signature into FAP signaling communication with the Mobile Core Network of which the signaling is part of the IPSec payload.  Hence, it is totally transparent to the SeGW.  The notarized signature is just containing some FAP's specific configuration info - i.e. NOT every single packet between the FAP and the Mobile Core Network will be notarized.  It is a very small specific configuration info regarding to FAP which is specific to the particular mobile technology (i.e. 3GPP, 3GPP2, WiMAX etc.) and the corresponding mobile operator.  

Hoping that I was able to answer your question clearly.  

As ZaiFeng is back from her holiday.  I will leave the rest of further question back to her.  

Sincerely thanks for your kind attention to this draft. Cheers.
Tricci




Dharmanandana Reddy Pothula <dharmanandana.pothulam@huawei.com>
Sent by: ipsec-bounces@ietf.org

01/31/2012 02:43 AM
Please respond to
dharmanandana.pothulam@huawei.com
To
tso@zteusa.com
cc
ipsec@ietf.org, ipsec-bounces@ietf.org, zong.zaifeng@zte.com.cn
Subject
Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt





Hi Tricci,
 
Thanks for your explanation. I get your point why notarized signature required, but my question is not about notarizing every packet. Let me ask my question in different way, Is FAP sends notarized signature in every IPSec packet to core network? As I understand from the draft that before accepting every IPSec packet, core network validate the notarized signature. Where is this notarized signature placed in every IPSec packet?
Thanks,
Dharmanandana Reddy Pothula
 
From: tso@zteusa.com [mailto:tso@zteusa.com]
Sent: Wednesday, January 25, 2012 1:26 PM
To: dharmanandana.pothulam@huawei.com
Cc: ipsec@ietf.org; ipsec-bounces@ietf.org; zong.zaifeng@zte.com.cn; tso@zteusa.com
Subject: Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipse cme-ikev
 
Dear Dharmanandana,

I hope that I address you correctly.  If not, please pardon my ignorance.

As this week is spring festival, ZaiFeng is not available.  Hence, I would like to respond to you on behalf of her.  

Could you please kind see my responses to you inline below.  Many thanks.
Tricci


5pt;font-family:"Arial","sans-serif"'>Dharmanandana Reddy <dharmanandana.pothulam@huawei.com>
Sent by: ipsec-bounces@ietf.org

01/24/2012 04:04 AM


Please respond to
dharmanandana.pothulam@huawei.com
To zong.zaifeng@zte.com.cn
cc
ipsec@ietf.org
Subject
Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt

 







Hi Zaifeng,
 
I have following questions and concerns about your proposed solution "The FAP will then send the FAP information together with the corresponding SeGW notarized signature to its mobile operator's core network. The core network verifies the FAP information by validating the SeGW notarized signature prior to the acceptance of the information".
Is every ip packet carries SeGW notarized signature after server sends notarized signature to the client? if not, what's the point in returning notarized signature to the client? I believe yes, if so, It will increase percentage of overhead per packet and may impact quality of real time voice and video.

Tricci > You ask a very legitimate question.  May be our draft is not clear enough to explain the main motivation of this draft for target of the attack.  

Tricci > The main concern is not about the attack for "unauthorized FAP" to send any data to the mobile core network.  The main concern is about the attack of the "unauthorized FAP" to send the "false" configuration information (e.g. such as changing the FAP from "Closed" to become "O pen" ;false" access control related information (e.g. allowing a 3GPP UE which is supposed to be allowed to access the FAP and to have the access privileage to the FAP - i.e. CSG info alteration, etc.).  Once the FAP's configuration and access control management are authenticated via the support of the notarization by the SeGW, then, the rest of the 3GPP UEs' access to the FAP can follow the existing access control and UE-based authentication/authorization procedures at the UE level's.  

Tricci > Of course, once the UE is authenticated and to allow access to the FAP, whatever the UE sends is beyond the control of the FAP just as what is happened today for any mobile device.  Isn't it?  
 
if every ip packet carries SeGW notarized signature, How and where this signature carried inside ip packet? cations inside IPsec packet processing? Is this processing happens outside of IPsec? is it outside scope of this document? It would be great, if some of these aspects are addressed in the draft.
 
Tricci > Since I have already explained to you that, we are not proposing to notarize every single packet sent by FAP.  Hence, I don't think that I need to respond to your rest of the questions above.  

Tricci > THANK YOU for asking a good question.  Cheers.

Thanks,
 
Dharmanandana Reddy Pothula.
 
& yle='font-size:10.0pt;font-family:"Arial","sans-serif"'>  
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
 
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. R
ecipient
bsp;are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system._______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 00318F1988257997_=-- From zong.zaifeng@zte.com.cn Thu Feb 2 00:24:45 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30C0B21F8562; Thu, 2 Feb 2012 00:24:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.248 X-Spam-Level: X-Spam-Status: No, score=-92.248 tagged_above=-999 required=5 tests=[AWL=-2.973, BAYES_40=-0.185, CHARSET_FARAWAY_HEADER=3.2, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r240e5bI9UiJ; Thu, 2 Feb 2012 00:24:44 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1C721F855F; Thu, 2 Feb 2012 00:24:42 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 56690433787882; Thu, 2 Feb 2012 15:59:06 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 5467.1725263410; Thu, 2 Feb 2012 16:24:30 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q128OQgD081675; Thu, 2 Feb 2012 16:24:26 +0800 (GMT-8) (envelope-from zong.zaifeng@zte.com.cn) In-Reply-To: <000001cce005$2833bf40$789b3dc0$%pothulam@huawei.com> To: dharmanandana.pothulam@huawei.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zong.zaifeng@zte.com.cn Date: Thu, 2 Feb 2012 16:21:02 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-02-02 16:24:27, Serialize complete at 2012-02-02 16:24:27 Content-Type: multipart/alternative; boundary="=_alternative 002E2D6D48257998_=" X-MAIL: mse01.zte.com.cn q128OQgD081675 Cc: ipsec@ietf.org, ipsec-bounces@ietf.org, tso@zteusa.com Subject: [IPsec] =?gb2312?b?tPC4tDogUkU6ICBbSVBTZWNdOiBOZXcgVmVyc2lvbiBO?= =?gb2312?b?b3RpZmljYXRpb24gZm9yIGRyYWZ0LXpvbmctaXBzZWNtZS1pa2V2Mi1jcGV4?= =?gb2312?b?dDRmZW10by0wMC50eHQ=?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 08:24:45 -0000 This is a multipart message in MIME format. --=_alternative 002E2D6D48257998_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgRGhhcm1hbmFuZGFuYToNCg0KVGhlIG5vdGFyaXplZCBzaWduYXR1cmUgd2lsbCBub3QgYmUg c2VudCBvaW4gZXZlcnkgSVBTZWMgcGFja2V0LiBJdCB3aWxsIA0KYmUgc2VudCB0byBjb3JlIG5l dHdvcmsgd2hlbiB0aGUgRkFQIHJlZ2lzdGVycyB0byB0aGUgY29yZSBuZXR3b3JrIGluc2lkZSAN CnRoZSBzaWduYWxsaW5nIGJldHdlZW4gdGhlIEZBUCBhbmQgY29yZSBuZXR3b3JrLiBBZnRlciBp dCBpcyByZWdpc3RlcmVkIHRvIA0KdGhlIGNvcmUgbmV0d29yaywgdGhlIEZBUCBpcyBhY3RpdmF0 ZWQgdG8gYWNjZXB0IGF0dGFjaG1lbnQgb2YgbW9iaWxlIA0KdGVybWluYWxzLiBJIHdpc2ggdGhp cyBjbGFyaWZpZXMuIFRoYW5rcyENCg0KQlINClphaWZlbmcNCg0KIA0KDQoNCg0KRGhhcm1hbmFu ZGFuYSBSZWRkeSBQb3RodWxhIDxkaGFybWFuYW5kYW5hLnBvdGh1bGFtQGh1YXdlaS5jb20+IA0K MjAxMi0wMS0zMSAxODo0Mw0Kx+u08Li0ILj4DQpkaGFybWFuYW5kYW5hLnBvdGh1bGFtQGh1YXdl aS5jb20NCg0KDQrK1bz+yMsNCnRzb0B6dGV1c2EuY29tDQqzrcvNDQppcHNlY0BpZXRmLm9yZywg aXBzZWMtYm91bmNlc0BpZXRmLm9yZywgem9uZy56YWlmZW5nQHp0ZS5jb20uY24NCtb3zOINClJF OiBbSVBzZWNdIFtJUFNlY106IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgDQpkcmFmdC16 b25nLWlwc2VjbWUtaWtldjItY3BleHQ0ZmVtdG8tMDAudHh0DQoNCg0KDQoNCg0KDQpIaSBUcmlj Y2ksDQogDQpUaGFua3MgZm9yIHlvdXIgZXhwbGFuYXRpb24uIEkgZ2V0IHlvdXIgcG9pbnQgd2h5 IG5vdGFyaXplZCBzaWduYXR1cmUgDQpyZXF1aXJlZCwgYnV0IG15IHF1ZXN0aW9uIGlzIG5vdCBh Ym91dCBub3Rhcml6aW5nIGV2ZXJ5IHBhY2tldC4gTGV0IG1lIGFzayANCm15IHF1ZXN0aW9uIGlu IGRpZmZlcmVudCB3YXksIElzIEZBUCBzZW5kcyBub3Rhcml6ZWQgc2lnbmF0dXJlIGluIGV2ZXJ5 IA0KSVBTZWMgcGFja2V0IHRvIGNvcmUgbmV0d29yaz8gQXMgSSB1bmRlcnN0YW5kIGZyb20gdGhl IGRyYWZ0IHRoYXQgYmVmb3JlIA0KYWNjZXB0aW5nIGV2ZXJ5IElQU2VjIHBhY2tldCwgY29yZSBu ZXR3b3JrIHZhbGlkYXRlIHRoZSBub3Rhcml6ZWQgDQpzaWduYXR1cmUuIFdoZXJlIGlzIHRoaXMg bm90YXJpemVkIHNpZ25hdHVyZSBwbGFjZWQgaW4gZXZlcnkgSVBTZWMgcGFja2V0Pw0KVGhhbmtz LA0KRGhhcm1hbmFuZGFuYSBSZWRkeSBQb3RodWxhDQogDQpGcm9tOiB0c29AenRldXNhLmNvbSBb bWFpbHRvOnRzb0B6dGV1c2EuY29tXSANClNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAyNSwgMjAx MiAxOjI2IFBNDQpUbzogZGhhcm1hbmFuZGFuYS5wb3RodWxhbUBodWF3ZWkuY29tDQpDYzogaXBz ZWNAaWV0Zi5vcmc7IGlwc2VjLWJvdW5jZXNAaWV0Zi5vcmc7IHpvbmcuemFpZmVuZ0B6dGUuY29t LmNuOyANCnRzb0B6dGV1c2EuY29tDQpTdWJqZWN0OiBSZTogW0lQc2VjXSBbSVBTZWNdOiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIA0KZHJhZnQtem9uZy1pcHNlY21lLWlrZXYgDQogDQpE ZWFyIERoYXJtYW5hbmRhbmEsIA0KDQpJIGhvcGUgdGhhdCBJIGFkZHJlc3MgeW91IGNvcnJlY3Rs eS4gIElmIG5vdCwgcGxlYXNlIHBhcmRvbiBteSBpZ25vcmFuY2UuIA0KDQpBcyB0aGlzIHdlZWsg aXMgc3ByaW5nIGZlc3RpdmFsLCBaYWlGZW5nIGlzIG5vdCBhdmFpbGFibGUuICBIZW5jZSwgSSB3 b3VsZCANCmxpa2UgdG8gcmVzcG9uZCB0byB5b3Ugb24gYmVoYWxmIG9mIGhlci4gICANCg0KQ291 bGQgeW91IHBsZWFzZSBraW5kIHNlZSBteSByZXNwb25zZXMgdG8geW91IGlubGluZSBiZWxvdy4g IE1hbnkgdGhhbmtzLiANClRyaWNjaSANCg0KDQoNCg0KNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIs InNhbnMtc2VyaWYiJz5EaGFybWFuYW5kYW5hIFJlZGR5IA0KPGRoYXJtYW5hbmRhbmEucG90aHVs YW1AaHVhd2VpLmNvbT4gDQpTZW50IGJ5OiBpcHNlYy1ib3VuY2VzQGlldGYub3JnIA0KMDEvMjQv MjAxMiAwNDowNCBBTSANCg0KDQpQbGVhc2UgcmVzcG9uZCB0bw0KZGhhcm1hbmFuZGFuYS5wb3Ro dWxhbUBodWF3ZWkuY29tDQoNCg0KDQpUbw0Kem9uZy56YWlmZW5nQHp0ZS5jb20uY24gDQpjYw0K aXBzZWNAaWV0Zi5vcmcgDQpTdWJqZWN0DQpSZTogW0lQc2VjXSBbSVBTZWNdOiBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yIA0KZHJhZnQtem9uZy1pcHNlY21lLWlrZXYyLWNwZXh0NGZlbXRv LTAwLnR4dA0KIA0KDQoNCg0KDQoNCg0KDQoNCkhpIFphaWZlbmcsIA0KICANCkkgaGF2ZSBmb2xs b3dpbmcgcXVlc3Rpb25zIGFuZCBjb25jZXJucyBhYm91dCB5b3VyIHByb3Bvc2VkIHNvbHV0aW9u ICJUaGUgDQpGQVAgd2lsbCB0aGVuIHNlbmQgdGhlIEZBUCBpbmZvcm1hdGlvbiB0b2dldGhlciB3 aXRoIHRoZSBjb3JyZXNwb25kaW5nIA0KU2VHVyBub3Rhcml6ZWQgc2lnbmF0dXJlIHRvIGl0cyBt b2JpbGUgb3BlcmF0b3IncyBjb3JlIG5ldHdvcmsuIFRoZSBjb3JlIA0KbmV0d29yayB2ZXJpZmll cyB0aGUgRkFQIGluZm9ybWF0aW9uIGJ5IHZhbGlkYXRpbmcgdGhlIFNlR1cgbm90YXJpemVkIA0K c2lnbmF0dXJlIHByaW9yIHRvIHRoZSBhY2NlcHRhbmNlIG9mIHRoZSBpbmZvcm1hdGlvbiIuIA0K SXMgZXZlcnkgaXAgcGFja2V0IGNhcnJpZXMgU2VHVyBub3Rhcml6ZWQgc2lnbmF0dXJlIGFmdGVy IHNlcnZlciBzZW5kcyANCm5vdGFyaXplZCBzaWduYXR1cmUgdG8gdGhlIGNsaWVudD8gaWYgbm90 LCB3aGF0J3MgdGhlIHBvaW50IGluIHJldHVybmluZyANCm5vdGFyaXplZCBzaWduYXR1cmUgdG8g dGhlIGNsaWVudD8gSSBiZWxpZXZlIHllcywgaWYgc28sIEl0IHdpbGwgaW5jcmVhc2UgDQpwZXJj ZW50YWdlIG9mIG92ZXJoZWFkIHBlciBwYWNrZXQgYW5kIG1heSBpbXBhY3QgcXVhbGl0eSBvZiBy ZWFsIHRpbWUgDQp2b2ljZSBhbmQgdmlkZW8uIA0KDQpUcmljY2kgPiBZb3UgYXNrIGEgdmVyeSBs ZWdpdGltYXRlIHF1ZXN0aW9uLiAgTWF5IGJlIG91ciBkcmFmdCBpcyBub3QgDQpjbGVhciBlbm91 Z2ggdG8gZXhwbGFpbiB0aGUgbWFpbiBtb3RpdmF0aW9uIG9mIHRoaXMgZHJhZnQgZm9yIHRhcmdl dCBvZiANCnRoZSBhdHRhY2suICAgDQoNClRyaWNjaSA+IFRoZSBtYWluIGNvbmNlcm4gaXMgbm90 IGFib3V0IHRoZSBhdHRhY2sgZm9yICJ1bmF1dGhvcml6ZWQgRkFQIiANCnRvIHNlbmQgYW55IGRh dGEgdG8gdGhlIG1vYmlsZSBjb3JlIG5ldHdvcmsuICBUaGUgbWFpbiBjb25jZXJuIGlzIGFib3V0 IA0KdGhlIGF0dGFjayBvZiB0aGUgInVuYXV0aG9yaXplZCBGQVAiIHRvIHNlbmQgdGhlICJmYWxz ZSIgY29uZmlndXJhdGlvbiANCmluZm9ybWF0aW9uIChlLmcuIHN1Y2ggYXMgY2hhbmdpbmcgdGhl IEZBUCBmcm9tICJDbG9zZWQiIHRvIGJlY29tZSAiT3BlbiIgDQo7ZmFsc2UiIGFjY2VzcyBjb250 cm9sIHJlbGF0ZWQgaW5mb3JtYXRpb24gKGUuZy4gYWxsb3dpbmcgYSAzR1BQIFVFIHdoaWNoIA0K aXMgc3VwcG9zZWQgdG8gYmUgYWxsb3dlZCB0byBhY2Nlc3MgdGhlIEZBUCBhbmQgdG8gaGF2ZSB0 aGUgYWNjZXNzIA0KcHJpdmlsZWFnZSB0byB0aGUgRkFQIC0gaS5lLiBDU0cgaW5mbyBhbHRlcmF0 aW9uLCBldGMuKS4gIE9uY2UgdGhlIEZBUCdzIA0KY29uZmlndXJhdGlvbiBhbmQgYWNjZXNzIGNv bnRyb2wgbWFuYWdlbWVudCBhcmUgYXV0aGVudGljYXRlZCB2aWEgdGhlIA0Kc3VwcG9ydCBvZiB0 aGUgbm90YXJpemF0aW9uIGJ5IHRoZSBTZUdXLCB0aGVuLCB0aGUgcmVzdCBvZiB0aGUgM0dQUCBV RXMnIA0KYWNjZXNzIHRvIHRoZSBGQVAgY2FuIGZvbGxvdyB0aGUgZXhpc3RpbmcgYWNjZXNzIGNv bnRyb2wgYW5kIFVFLWJhc2VkIA0KYXV0aGVudGljYXRpb24vYXV0aG9yaXphdGlvbiBwcm9jZWR1 cmVzIGF0IHRoZSBVRSBsZXZlbCdzLiAgIA0KDQpUcmljY2kgPiBPZiBjb3Vyc2UsIG9uY2UgdGhl IFVFIGlzIGF1dGhlbnRpY2F0ZWQgYW5kIHRvIGFsbG93IGFjY2VzcyB0byANCnRoZSBGQVAsIHdo YXRldmVyIHRoZSBVRSBzZW5kcyBpcyBiZXlvbmQgdGhlIGNvbnRyb2wgb2YgdGhlIEZBUCBqdXN0 IGFzIA0Kd2hhdCBpcyBoYXBwZW5lZCB0b2RheSBmb3IgYW55IG1vYmlsZSBkZXZpY2UuICBJc24n dCBpdD8gICANCiAgDQppZiBldmVyeSBpcCBwYWNrZXQgY2FycmllcyBTZUdXIG5vdGFyaXplZCBz aWduYXR1cmUsIEhvdyBhbmQgd2hlcmUgdGhpcyANCnNpZ25hdHVyZSBjYXJyaWVkIGluc2lkZSBp cCBwYWNrZXQ/IGNhdGlvbnMgaW5zaWRlIElQc2VjIHBhY2tldCANCnByb2Nlc3Npbmc/IElzIHRo aXMgcHJvY2Vzc2luZyBoYXBwZW5zIG91dHNpZGUgb2YgSVBzZWM/IGlzIGl0IG91dHNpZGUgDQpz Y29wZSBvZiB0aGlzIGRvY3VtZW50PyBJdCB3b3VsZCBiZSBncmVhdCwgaWYgc29tZSBvZiB0aGVz ZSBhc3BlY3RzIGFyZSANCmFkZHJlc3NlZCBpbiB0aGUgZHJhZnQuIA0KICANClRyaWNjaSA+IFNp bmNlIEkgaGF2ZSBhbHJlYWR5IGV4cGxhaW5lZCB0byB5b3UgdGhhdCwgd2UgYXJlIG5vdCBwcm9w b3NpbmcgDQp0byBub3Rhcml6ZSBldmVyeSBzaW5nbGUgcGFja2V0IHNlbnQgYnkgRkFQLiAgSGVu Y2UsIEkgZG9uJ3QgdGhpbmsgdGhhdCBJIA0KbmVlZCB0byByZXNwb25kIHRvIHlvdXIgcmVzdCBv ZiB0aGUgcXVlc3Rpb25zIGFib3ZlLiAgIA0KDQpUcmljY2kgPiBUSEFOSyBZT1UgZm9yIGFza2lu ZyBhIGdvb2QgcXVlc3Rpb24uICBDaGVlcnMuIA0KDQpUaGFua3MsIA0KICANCkRoYXJtYW5hbmRh bmEgUmVkZHkgUG90aHVsYS4gDQogIA0KJiB5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPiAgDQogX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCklQc2VjIG1haWxpbmcgbGlzdA0KSVBzZWNAaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWMNCg0KIA0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJ bmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4g dGhpcyBtYWlsIGlzIA0Kc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRp b24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIA0KY29uZmlkZW50aWFsLiBSZWNpcGllbnQN CmJzcDthcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0 dGVkIHRvIGRpc2Nsb3NlIA0KdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBv dGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUg Y29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCANCnNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5k aXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIA0KSWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5h dG9yIG9mIA0KdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdl IGFyZSB0aG9zZSBvZiB0aGUgDQppbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMg YmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gDQpzeXN0 ZW0uDQoNCg== --=_alternative 002E2D6D48257998_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIERoYXJtYW5hbmRhbmE6PC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGUgbm90YXJp emVkIHNpZ25hdHVyZSB3aWxsIG5vdCBiZQ0Kc2VudCBvaW4gZXZlcnkgSVBTZWMgcGFja2V0LiBJ dCB3aWxsIGJlIHNlbnQgdG8gY29yZSBuZXR3b3JrIHdoZW4gdGhlIEZBUA0KcmVnaXN0ZXJzIHRv IHRoZSBjb3JlIG5ldHdvcmsgaW5zaWRlIHRoZSBzaWduYWxsaW5nIGJldHdlZW4gdGhlIEZBUCBh bmQNCmNvcmUgbmV0d29yay4gQWZ0ZXIgaXQgaXMgcmVnaXN0ZXJlZCB0byB0aGUgY29yZSBuZXR3 b3JrLCB0aGUgRkFQIGlzIGFjdGl2YXRlZA0KdG8gYWNjZXB0IGF0dGFjaG1lbnQgb2YgbW9iaWxl IHRlcm1pbmFscy4gSSB3aXNoIHRoaXMgY2xhcmlmaWVzLiBUaGFua3MhPC9mb250Pg0KPGJyPg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5CUjwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+WmFpZmVuZzxicj4NCjwvZm9udD4NCjxicj48Zm9udCBz aXplPTEgZmFjZT0iQXJpYWwiPiZuYnNwOzwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJs ZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzUlPjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5EaGFybWFuYW5kYW5hIFJlZGR5IFBvdGh1bGENCiZsdDtk aGFybWFuYW5kYW5hLnBvdGh1bGFtQGh1YXdlaS5jb20mZ3Q7PC9iPiA8L2ZvbnQ+DQo8cD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMi0wMS0zMSAxODo0MzwvZm9udD4NCjx0YWJs ZSBib3JkZXI+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCBiZ2NvbG9yPXdoaXRlPg0KPGRpdiBhbGln bj1jZW50ZXI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsfrtPC4tCC4+Dxicj4NCmRo YXJtYW5hbmRhbmEucG90aHVsYW1AaHVhd2VpLmNvbTwvZm9udD48L2Rpdj48L3RhYmxlPg0KPGJy Pg0KPHRkIHdpZHRoPTY0JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8 dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+ yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPnRzb0B6 dGV1c2EuY29tPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0 Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5pcHNlY0BpZXRmLm9yZywgaXBzZWMtYm91bmNl c0BpZXRmLm9yZywNCnpvbmcuemFpZmVuZ0B6dGUuY29tLmNuPC9mb250Pg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5S RTogW0lQc2VjXSBbSVBTZWNdOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24NCmZvciBkcmFmdC16 b25nLWlwc2VjbWUtaWtldjItY3BleHQ0ZmVtdG8tMDAudHh0PC9mb250PjwvdGFibGU+DQo8YnI+ DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFi bGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2Fs aWJyaSI+SGkgVHJpY2NpLDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBm YWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5 N2QgZmFjZT0iQ2FsaWJyaSI+VGhhbmtzIGZvciB5b3VyIGV4cGxhbmF0aW9uLg0KSSBnZXQgeW91 ciBwb2ludCB3aHkgbm90YXJpemVkIHNpZ25hdHVyZSByZXF1aXJlZCwgYnV0IG15IHF1ZXN0aW9u IGlzIG5vdA0KYWJvdXQgbm90YXJpemluZyBldmVyeSBwYWNrZXQuIExldCBtZSBhc2sgbXkgcXVl c3Rpb24gaW4gZGlmZmVyZW50IHdheSwNCklzIEZBUCBzZW5kcyBub3Rhcml6ZWQgc2lnbmF0dXJl IGluIGV2ZXJ5IElQU2VjIHBhY2tldCB0byBjb3JlIG5ldHdvcms/DQpBcyBJIHVuZGVyc3RhbmQg ZnJvbSB0aGUgZHJhZnQgdGhhdCBiZWZvcmUgYWNjZXB0aW5nIGV2ZXJ5IElQU2VjIHBhY2tldCwN CmNvcmUgbmV0d29yayB2YWxpZGF0ZSB0aGUgbm90YXJpemVkIHNpZ25hdHVyZS4gV2hlcmUgaXMg dGhpcyBub3Rhcml6ZWQNCnNpZ25hdHVyZSBwbGFjZWQgaW4gZXZlcnkgSVBTZWMgcGFja2V0Pzwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+VGhhbmtzLDwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5EaGFybWFuYW5kYW5h IFJlZGR5IFBvdGh1bGE8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFj ZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEi PjxiPkZyb206PC9iPiB0c29AenRldXNhLmNvbSBbbWFpbHRvOnRzb0B6dGV1c2EuY29tXQ0KPGI+ PGJyPg0KU2VudDo8L2I+IFdlZG5lc2RheSwgSmFudWFyeSAyNSwgMjAxMiAxOjI2IFBNPGI+PGJy Pg0KVG86PC9iPiBkaGFybWFuYW5kYW5hLnBvdGh1bGFtQGh1YXdlaS5jb208Yj48YnI+DQpDYzo8 L2I+IGlwc2VjQGlldGYub3JnOyBpcHNlYy1ib3VuY2VzQGlldGYub3JnOyB6b25nLnphaWZlbmdA enRlLmNvbS5jbjsNCnRzb0B6dGV1c2EuY29tPGI+PGJyPg0KU3ViamVjdDo8L2I+IFJlOiBbSVBz ZWNdIFtJUFNlY106IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtem9uZy1pcHNl Y21lLWlrZXYNCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFu Ij4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwi PkRlYXIgRGhhcm1hbmFuZGFuYSwgPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPjxicj4NCjwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+ PGJyPg0KSSBob3BlIHRoYXQgSSBhZGRyZXNzIHlvdSBjb3JyZWN0bHkuICZuYnNwO0lmIG5vdCwg cGxlYXNlIHBhcmRvbiBteSBpZ25vcmFuY2UuDQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRp bWVzIE5ldyBSb21hbiI+PGJyPg0KPC9mb250Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9 IkFyaWFsIj48YnI+DQpBcyB0aGlzIHdlZWsgaXMgc3ByaW5nIGZlc3RpdmFsLCBaYWlGZW5nIGlz IG5vdCBhdmFpbGFibGUuICZuYnNwO0hlbmNlLA0KSSB3b3VsZCBsaWtlIHRvIHJlc3BvbmQgdG8g eW91IG9uIGJlaGFsZiBvZiBoZXIuICZuYnNwOzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNl PSJBcmlhbCI+PGJyPg0KQ291bGQgeW91IHBsZWFzZSBraW5kIHNlZSBteSByZXNwb25zZXMgdG8g eW91IGlubGluZSBiZWxvdy4gJm5ic3A7TWFueQ0KdGhhbmtzLjwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZh Y2U9IkFyaWFsIj48YnI+DQpUcmljY2kgPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPjxicj4NCjxicj4NCjxicj4NCjwvZm9udD4NCjxwPg0KPHRhYmxlIHdpZHRoPTEw MCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD01MyU+PGZvbnQgc2l6ZT0zIGZhY2U9IlRp bWVzIE5ldyBSb21hbiI+PGI+NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsnJmd0O0RoYXJtYW5hbmRhbmENClJlZGR5ICZsdDtkaGFybWFuYW5k YW5hLnBvdGh1bGFtQGh1YXdlaS5jb20mZ3Q7PC9iPjwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0i QXJpYWwiPg0KPGJyPg0KU2VudCBieTogaXBzZWMtYm91bmNlc0BpZXRmLm9yZzwvZm9udD48Zm9u dCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9 MSBmYWNlPSJBcmlhbCI+MDEvMjQvMjAxMiAwNDowNCBBTTwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD4NCjxwPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEw MCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0xMDAlIGJnY29sb3I9d2hpdGU+DQo8ZGl2 IGFsaWduPWNlbnRlcj48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPlBsZWFzZSByZXNwb25kIHRv PGJyPg0KZGhhcm1hbmFuZGFuYS5wb3RodWxhbUBodWF3ZWkuY29tPC9mb250PjwvZGl2PjwvdGFi bGU+DQo8YnI+DQo8dGQgd2lkdGg9NDYlPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZCB3aWR0aD02JT48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPlRvPC9m b250Pg0KPHRkIHdpZHRoPTkzJT48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPnpvbmcuemFpZmVu Z0B6dGUuY29tLmNuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0K PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNp emU9MSBmYWNlPSJBcmlhbCI+Y2M8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9 IkFyaWFsIj5pcHNlY0BpZXRmLm9yZzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj4NCjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdo dD48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPlN1YmplY3Q8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZv bnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+UmU6IFtJUHNlY10gW0lQU2VjXTogTmV3 IFZlcnNpb24NCk5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtem9uZy1pcHNlY21lLWlrZXYyLWNwZXh0 NGZlbXRvLTAwLnR4dDwvZm9udD48L3RhYmxlPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD4NCjxwPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD01MCU+DQo8dGQgd2lkdGg9NTAlPjwvdGFibGU+ DQo8YnI+PC90YWJsZT4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48 YnI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQpI aSBaYWlmZW5nLDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KIDwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh Y2U9IkNvdXJpZXIgTmV3Ij48YnI+DQpJIGhhdmUgZm9sbG93aW5nIHF1ZXN0aW9ucyBhbmQgY29u Y2VybnMgYWJvdXQgeW91ciBwcm9wb3NlZCBzb2x1dGlvbiAmcXVvdDtUaGUNCkZBUCB3aWxsIHRo ZW4gc2VuZCB0aGUgRkFQIGluZm9ybWF0aW9uIHRvZ2V0aGVyIHdpdGggdGhlIGNvcnJlc3BvbmRp bmcNClNlR1cgbm90YXJpemVkIHNpZ25hdHVyZSB0byBpdHMgbW9iaWxlIG9wZXJhdG9yJ3MgY29y ZSBuZXR3b3JrLiBUaGUgY29yZQ0KbmV0d29yayB2ZXJpZmllcyB0aGUgRkFQIGluZm9ybWF0aW9u IGJ5IHZhbGlkYXRpbmcgdGhlIFNlR1cgbm90YXJpemVkIHNpZ25hdHVyZQ0KcHJpb3IgdG8gdGhl IGFjY2VwdGFuY2Ugb2YgdGhlIGluZm9ybWF0aW9uJnF1b3Q7LjwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjxicj4NCklzIGV2ZXJ5IGlwIHBhY2tldCBjYXJyaWVz IFNlR1cgbm90YXJpemVkIHNpZ25hdHVyZSBhZnRlciBzZXJ2ZXIgc2VuZHMNCm5vdGFyaXplZCBz aWduYXR1cmUgdG8gdGhlIGNsaWVudD8gaWYgbm90LCB3aGF0J3MgdGhlIHBvaW50IGluIHJldHVy bmluZw0Kbm90YXJpemVkIHNpZ25hdHVyZSB0byB0aGUgY2xpZW50PyBJIGJlbGlldmUgeWVzLCBp ZiBzbywgSXQgd2lsbCBpbmNyZWFzZQ0KcGVyY2VudGFnZSBvZiBvdmVyaGVhZCBwZXIgcGFja2V0 IGFuZCBtYXkgaW1wYWN0IHF1YWxpdHkgb2YgcmVhbCB0aW1lIHZvaWNlDQphbmQgdmlkZW8uIDxi cj4NCjwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJNViBCb2xpIj48YnI+DQpU cmljY2kgJmd0OyBZb3UgYXNrIGEgdmVyeSBsZWdpdGltYXRlIHF1ZXN0aW9uLiAmbmJzcDtNYXkg YmUgb3VyIGRyYWZ0DQppcyBub3QgY2xlYXIgZW5vdWdoIHRvIGV4cGxhaW4gdGhlIG1haW4gbW90 aXZhdGlvbiBvZiB0aGlzIGRyYWZ0IGZvciB0YXJnZXQNCm9mIHRoZSBhdHRhY2suICZuYnNwOzwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPGJyPg0KPC9mb250Pjxm b250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9Ik1WIEJvbGkiPjxicj4NClRyaWNjaSAmZ3Q7IFRo ZSBtYWluIGNvbmNlcm4gaXMgbm90IGFib3V0IHRoZSBhdHRhY2sgZm9yICZxdW90O3VuYXV0aG9y aXplZA0KRkFQJnF1b3Q7IHRvIHNlbmQgYW55IGRhdGEgdG8gdGhlIG1vYmlsZSBjb3JlIG5ldHdv cmsuICZuYnNwO1RoZSBtYWluIGNvbmNlcm4NCmlzIGFib3V0IHRoZSBhdHRhY2sgb2YgdGhlICZx dW90O3VuYXV0aG9yaXplZCBGQVAmcXVvdDsgdG8gc2VuZCB0aGUgJnF1b3Q7ZmFsc2UmcXVvdDsN CmNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24gKGUuZy4gc3VjaCBhcyBjaGFuZ2luZyB0aGUgRkFQ IGZyb20gJnF1b3Q7Q2xvc2VkJnF1b3Q7DQp0byBiZWNvbWUgJnF1b3Q7T3BlbiZxdW90OyA7ZmFs c2UmcXVvdDsgYWNjZXNzIGNvbnRyb2wgcmVsYXRlZCBpbmZvcm1hdGlvbg0KKGUuZy4gYWxsb3dp bmcgYSAzR1BQIFVFIHdoaWNoIGlzIHN1cHBvc2VkIHRvIGJlIGFsbG93ZWQgdG8gYWNjZXNzIHRo ZQ0KRkFQIGFuZCB0byBoYXZlIHRoZSBhY2Nlc3MgcHJpdmlsZWFnZSB0byB0aGUgRkFQIC0gaS5l LiBDU0cgaW5mbyBhbHRlcmF0aW9uLA0KZXRjLikuICZuYnNwO09uY2UgdGhlIEZBUCdzIGNvbmZp Z3VyYXRpb24gYW5kIGFjY2VzcyBjb250cm9sIG1hbmFnZW1lbnQNCmFyZSBhdXRoZW50aWNhdGVk IHZpYSB0aGUgc3VwcG9ydCBvZiB0aGUgbm90YXJpemF0aW9uIGJ5IHRoZSBTZUdXLCB0aGVuLA0K dGhlIHJlc3Qgb2YgdGhlIDNHUFAgVUVzJyBhY2Nlc3MgdG8gdGhlIEZBUCBjYW4gZm9sbG93IHRo ZSBleGlzdGluZyBhY2Nlc3MNCmNvbnRyb2wgYW5kIFVFLWJhc2VkIGF1dGhlbnRpY2F0aW9uL2F1 dGhvcml6YXRpb24gcHJvY2VkdXJlcyBhdCB0aGUgVUUNCmxldmVsJ3MuICZuYnNwOzwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPGJyPg0KPC9mb250Pjxmb250IHNp emU9MyBjb2xvcj1ibHVlIGZhY2U9Ik1WIEJvbGkiPjxicj4NClRyaWNjaSAmZ3Q7IE9mIGNvdXJz ZSwgb25jZSB0aGUgVUUgaXMgYXV0aGVudGljYXRlZCBhbmQgdG8gYWxsb3cgYWNjZXNzDQp0byB0 aGUgRkFQLCB3aGF0ZXZlciB0aGUgVUUgc2VuZHMgaXMgYmV5b25kIHRoZSBjb250cm9sIG9mIHRo ZSBGQVAganVzdA0KYXMgd2hhdCBpcyBoYXBwZW5lZCB0b2RheSBmb3IgYW55IG1vYmlsZSBkZXZp Y2UuICZuYnNwO0lzbid0IGl0PyAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+ DQogPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9u dD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPjxicj4NCmlmIGV2ZXJ5IGlwIHBhY2tl dCBjYXJyaWVzIFNlR1cgbm90YXJpemVkIHNpZ25hdHVyZSwgSG93IGFuZCB3aGVyZSB0aGlzDQpz aWduYXR1cmUgY2FycmllZCBpbnNpZGUgaXAgcGFja2V0PyBjYXRpb25zIGluc2lkZSBJUHNlYyBw YWNrZXQgcHJvY2Vzc2luZz8NCklzIHRoaXMgcHJvY2Vzc2luZyBoYXBwZW5zIG91dHNpZGUgb2Yg SVBzZWM/IGlzIGl0IG91dHNpZGUgc2NvcGUgb2YgdGhpcw0KZG9jdW1lbnQ/IEl0IHdvdWxkIGJl IGdyZWF0LCBpZiBzb21lIG9mIHRoZXNlIGFzcGVjdHMgYXJlIGFkZHJlc3NlZCBpbg0KdGhlIGRy YWZ0LjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPWJs dWUgZmFjZT0iTVYgQm9saSI+PGJyPg0KVHJpY2NpICZndDsgU2luY2UgSSBoYXZlIGFscmVhZHkg ZXhwbGFpbmVkIHRvIHlvdSB0aGF0LCB3ZSBhcmUgbm90IHByb3Bvc2luZw0KdG8gbm90YXJpemUg ZXZlcnkgc2luZ2xlIHBhY2tldCBzZW50IGJ5IEZBUC4gJm5ic3A7SGVuY2UsIEkgZG9uJ3QgdGhp bmsNCnRoYXQgSSBuZWVkIHRvIHJlc3BvbmQgdG8geW91ciByZXN0IG9mIHRoZSBxdWVzdGlvbnMg YWJvdmUuICZuYnNwOzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4N Cjxicj4NCjwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJNViBCb2xpIj48YnI+ DQpUcmljY2kgJmd0OyBUSEFOSyBZT1UgZm9yIGFza2luZyBhIGdvb2QgcXVlc3Rpb24uICZuYnNw O0NoZWVycy4gPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxicj4N CjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPjxicj4NClRoYW5rcyw8L2Zv bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDwvZm9udD48Zm9udCBzaXpl PTMgZmFjZT0iQ291cmllciBOZXciPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRp bWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVyIE5l dyI+PGJyPg0KRGhhcm1hbmFuZGFuYSBSZWRkeSBQb3RodWxhLjwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmll ciBOZXciPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KJmFtcDsg eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsnJmd0Ow0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCiA8 L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCklQc2VjIG1haWxpbmcgbGlzdDxicj4N CklQc2VjQGlldGYub3JnPC9mb250Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PHU+PGJyPg0KPC91PjwvZm9udD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWM+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0i Q291cmllciBOZXciPjx1Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBz ZWM8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCjwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOzwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+WlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTog VGhlDQppbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0 eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLg0KVGhpcyBtYWlsIGNvbW11bmljYXRpb24g aXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnQ8YnI+DQpic3A7YXJlIG9ibGlnYXRlZCB0byBtYWlu dGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZQ0KdGhlIGNvbnRl bnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+VGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0 dGVkDQp3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhl IHVzZSBvZiB0aGUgaW5kaXZpZHVhbA0Kb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVz c2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluDQplcnJvciBwbGVhc2Ugbm90 aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkDQpp biB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci48L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5UaGlzIG1lc3NhZ2UgaGFzIGJl ZW4gc2Nhbm5lZCBmb3IgdmlydXNlcw0KYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0u PC9mb250Pg0KPGJyPg0K --=_alternative 002E2D6D48257998_=-- From dharmanandana.pothulam@huawei.com Thu Feb 2 21:20:20 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6C3121F869F; Thu, 2 Feb 2012 21:20:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.556 X-Spam-Level: X-Spam-Status: No, score=-4.556 tagged_above=-999 required=5 tests=[AWL=-1.509, BAYES_00=-2.599, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 956YwGRVnBXk; Thu, 2 Feb 2012 21:20:19 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 00E2B11E8071; Thu, 2 Feb 2012 21:20:19 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LYS009ECXHT14@szxga04-in.huawei.com>; Fri, 03 Feb 2012 13:20:18 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LYS007Q9XHTJS@szxga04-in.huawei.com>; Fri, 03 Feb 2012 13:20:17 +0800 (CST) Received: from szxeml213-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGU30252; Fri, 03 Feb 2012 13:19:22 +0800 Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by szxeml213-edg.china.huawei.com (172.24.2.30) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 03 Feb 2012 13:18:50 +0800 Received: from blrprnc06ns (10.18.96.95) by szxeml420-hub.china.huawei.com (10.82.67.159) with Microsoft SMTP Server id 14.1.323.3; Fri, 03 Feb 2012 13:19:13 +0800 Date: Fri, 03 Feb 2012 10:49:11 +0530 From: Dharmanandana Reddy Pothula In-reply-to: X-Originating-IP: [10.18.96.95] To: zong.zaifeng@zte.com.cn Message-id: <000001cce233$5dcf06c0$196d1440$%pothulam@huawei.com> Organization: HTIPL MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_8fnwEsfxLGWnMiHoUeBCGA)" Content-language: en-us Thread-index: AczhhCDaW78p6KnyQZC9X1puFS8AcgApXt1g X-CFilter-Loop: Reflected References: <000001cce005$2833bf40$789b3dc0$%pothulam@huawei.com> Cc: ipsec@ietf.org, ipsec-bounces@ietf.org, tso@zteusa.com Subject: Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dharmanandana.pothulam@huawei.com List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 05:20:20 -0000 --Boundary_(ID_8fnwEsfxLGWnMiHoUeBCGA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Zaifeng / Tricci, =20 Yes, I understood, so there is no impact on performance of UE access. = Thanks for your clarification. I feel It would be nice, if you can touch upon = some of these points in the draft, so the use case will be appreciated well = and also the main motivation of this draft may need little more explanation = like as you explained in previous emails. Of course these points may be = outside scope of this draft, since IKE payloads used for authorization = decisions, It would be appropriate to know in and around of it.=20 =20 Regards, Dharmanandana Reddy Pothula =20 From: zong.zaifeng@zte.com.cn [mailto:zong.zaifeng@zte.com.cn]=20 Sent: Thursday, February 02, 2012 1:51 PM To: dharmanandana.pothulam@huawei.com Cc: ipsec@ietf.org; ipsec-bounces@ietf.org; tso@zteusa.com Subject: =B4=F0=B8=B4: RE: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt =20 Hi Dharmanandana:=20 The notarized signature will not be sent oin every IPSec packet. It will = be sent to core network when the FAP registers to the core network inside = the signalling between the FAP and core network. After it is registered to = the core network, the FAP is activated to accept attachment of mobile = terminals. I wish this clarifies. Thanks!=20 BR=20 Zaifeng =20 Dharmanandana Reddy Pothula =20 2012-01-31 18:43=20 =C7=EB=B4=F0=B8=B4 =B8=F8 dharmanandana.pothulam@huawei.com =CA=D5=BC=FE=C8=CB tso@zteusa.com=20 =B3=AD=CB=CD ipsec@ietf.org, ipsec-bounces@ietf.org, zong.zaifeng@zte.com.cn=20 =D6=F7=CC=E2 RE: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt =20 =09 Hi Tricci,=20 =20 Thanks for your explanation. I get your point why notarized signature required, but my question is not about notarizing every packet. Let me = ask my question in different way, Is FAP sends notarized signature in every IPSec packet to core network? As I understand from the draft that before accepting every IPSec packet, core network validate the notarized = signature. Where is this notarized signature placed in every IPSec packet?=20 Thanks,=20 Dharmanandana Reddy Pothula=20 =20 From: tso@zteusa.com [mailto:tso@zteusa.com]=20 Sent: Wednesday, January 25, 2012 1:26 PM To: dharmanandana.pothulam@huawei.com Cc: ipsec@ietf.org; ipsec-bounces@ietf.org; zong.zaifeng@zte.com.cn; tso@zteusa.com Subject: Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev=20 =20 Dear Dharmanandana,=20 I hope that I address you correctly. If not, please pardon my = ignorance.=20 As this week is spring festival, ZaiFeng is not available. Hence, I = would like to respond to you on behalf of her. =20 Could you please kind see my responses to you inline below. Many = thanks.=20 Tricci=20 5pt;font-family:"Arial","sans-serif"'>Dharmanandana Reddy =20 Sent by: ipsec-bounces@ietf.org=20 01/24/2012 04:04 AM=20 =20 Please respond to dharmanandana.pothulam@huawei.com =20 To=20 zong.zaifeng@zte.com.cn=20 cc ipsec@ietf.org=20 Subject Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt =20 =20 =09 Hi Zaifeng,=20 =20 I have following questions and concerns about your proposed solution = "The FAP will then send the FAP information together with the corresponding = SeGW notarized signature to its mobile operator's core network. The core = network verifies the FAP information by validating the SeGW notarized signature prior to the acceptance of the information".=20 Is every ip packet carries SeGW notarized signature after server sends notarized signature to the client? if not, what's the point in returning notarized signature to the client? I believe yes, if so, It will = increase percentage of overhead per packet and may impact quality of real time = voice and video.=20 Tricci > You ask a very legitimate question. May be our draft is not = clear enough to explain the main motivation of this draft for target of the attack. =20 Tricci > The main concern is not about the attack for "unauthorized FAP" = to send any data to the mobile core network. The main concern is about the attack of the "unauthorized FAP" to send the "false" configuration information (e.g. such as changing the FAP from "Closed" to become = "Open" ;false" access control related information (e.g. allowing a 3GPP UE = which is supposed to be allowed to access the FAP and to have the access = privileage to the FAP - i.e. CSG info alteration, etc.). Once the FAP's = configuration and access control management are authenticated via the support of the notarization by the SeGW, then, the rest of the 3GPP UEs' access to the = FAP can follow the existing access control and UE-based authentication/authorization procedures at the UE level's. =20 Tricci > Of course, once the UE is authenticated and to allow access to = the FAP, whatever the UE sends is beyond the control of the FAP just as what = is happened today for any mobile device. Isn't it? =20 =20 if every ip packet carries SeGW notarized signature, How and where this signature carried inside ip packet? cations inside IPsec packet = processing? Is this processing happens outside of IPsec? is it outside scope of this document? It would be great, if some of these aspects are addressed in = the draft.=20 =20 Tricci > Since I have already explained to you that, we are not = proposing to notarize every single packet sent by FAP. Hence, I don't think that I = need to respond to your rest of the questions above. =20 Tricci > THANK YOU for asking a good question. Cheers.=20 Thanks,=20 =20 Dharmanandana Reddy Pothula.=20 =20 & yle=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'> =20 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec =20 --------------------------------------------------------=20 ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication is confidential. Recipient bsp;are obligated to maintain secrecy and are not permitted to disclose = the contents of this communication to others.=20 This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the originator of = the message. Any views expressed in this message are those of the individual sender.=20 This message has been scanned for viruses and Spam by ZTE Anti-Spam = system.=20 --Boundary_(ID_8fnwEsfxLGWnMiHoUeBCGA) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Zaifeng / Tricci,

 

Yes, I understood, so there is no impact on performance of UE access. = Thanks for your clarification.  I feel It would be nice, if you can = touch upon some of these points in the draft, so the use case will be = appreciated well and also the main motivation of this draft may need = little more explanation like as you explained in previous emails. Of = course these points may be outside scope of this draft, since IKE = payloads used for authorization decisions, It would be appropriate to = know in and around of it.

 

Regards,

Dharmanandana Reddy Pothula

 

From:= = zong.zaifeng@zte.com.cn [mailto:zong.zaifeng@zte.com.cn] =
Sent: Thursday, February 02, 2012 1:51 PM
To: = dharmanandana.pothulam@huawei.com
Cc: ipsec@ietf.org; = ipsec-bounces@ietf.org; tso@zteusa.com
Subject: =B4=F0=B8=B4: RE: = [IPsec] [IPSec]: New Version Notification for = draft-zong-ipsecme-ikev2-cpext4femto-00.txt

 


Hi = Dharmanandana:

The = notarized signature will not be sent oin every IPSec packet. It will be = sent to core network when the FAP registers to the core network inside = the signalling between the FAP and core network. After it is registered = to the core network, the FAP is activated to accept attachment of mobile = terminals. I wish this clarifies. Thanks!

BR =
Zaifeng

  =

Dharmanandana = Reddy Pothula <dharmanandana.pothulam@huawei.com> =

2012-01-31 = 18:43

=C7=EB=B4=F0=B8=B4 = =B8=F8
dharmanand= ana.pothulam@huawei.com

tso@zteusa.com=

=CA=D5=BC=FE=C8=CB

=B3=AD=CB=CD

ipsec@ietf.org= , ipsec-bounces@ietf.org, zong.zaifeng@zte.com.cn =

=D6=F7=CC=E2

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

 




Hi Tricci,
 
Thanks for your explanation. I get your point why notarized signature = required, but my question is not about notarizing every packet. Let me = ask my question in different way, Is FAP sends notarized signature in = every IPSec packet to core network? As I understand from the draft that = before accepting every IPSec packet, core network validate the notarized = signature. Where is this notarized signature placed in every IPSec = packet?
Thanks,
Dharmanandana Reddy Pothula
 
From:= = tso@zteusa.com [mailto:tso@zteusa.com]
Sent: Wednesday, = January 25, 2012 1:26 PM
To: = dharmanandana.pothulam@huawei.com
Cc: ipsec@ietf.org; = ipsec-bounces@ietf.org; zong.zaifeng@zte.com.cn; = tso@zteusa.com
Subject: Re: [IPsec] [IPSec]: New Version = Notification for draft-zong-ipsecme-ikev
 
Dear = Dharmanandana,

I hope that I = address you correctly.  If not, please pardon my ignorance. =

As this week = is spring festival, ZaiFeng is not available.  Hence, I would like = to respond to you on behalf of her.  

Could you = please kind see my responses to you inline below.  Many = thanks. =
Tricci =

5pt;font-family:"Arial","sans-serif"'= >Dharmanandana Reddy = <dharmanandana.pothulam@huawei.com>
Sent by: = ipsec-bounces@ietf.org

01/24/2012 = 04:04 AM =

 

Please = respond = to
dharmanandana.pothulam@huawei.com

 

To =

zong.zaifeng@z= te.com.cn =

cc=

ipsec@ietf.org= =

Subject=

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


  =

 





Hi Zaifeng,
 
I have following = questions and concerns about your proposed solution "The FAP will = then send the FAP information together with the corresponding SeGW = notarized signature to its mobile operator's core network. The core = network verifies the FAP information by validating the SeGW notarized = signature prior to the acceptance of the information".
Is every ip packet = carries SeGW notarized signature after server sends notarized signature = to the client? if not, what's the point in returning notarized signature = to the client? I believe yes, if so, It will increase percentage of = overhead per packet and may impact quality of real time voice and video. =

Tricci = > You ask a very legitimate question.  May be our draft is not = clear enough to explain the main motivation of this draft for target of = the attack.  

Tricci > The main concern is not about the = attack for "unauthorized FAP" to send any data to the mobile = core network.  The main concern is about the attack of the = "unauthorized FAP" to send the "false" configuration = information (e.g. such as changing the FAP from "Closed" to = become "Open" ;false" access control related information = (e.g. allowing a 3GPP UE which is supposed to be allowed to access the = FAP and to have the access privileage to the FAP - i.e. CSG info = alteration, etc.).  Once the FAP's configuration and access control = management are authenticated via the support of the notarization by the = SeGW, then, the rest of the 3GPP UEs' access to the FAP can follow the = existing access control and UE-based authentication/authorization = procedures at the UE level's.  

Tricci > Of course, = once the UE is authenticated and to allow access to the FAP, whatever = the UE sends is beyond the control of the FAP just as what is happened = today for any mobile device.  Isn't it?  
 
if every ip packet = carries SeGW notarized signature, How and where this signature carried = inside ip packet? cations inside IPsec packet processing? Is this = processing happens outside of IPsec? is it outside scope of this = document? It would be great, if some of these aspects are addressed in = the draft. =
 
Tricci > Since I have already explained to you = that, we are not proposing to notarize every single packet sent by FAP. =  Hence, I don't think that I need to respond to your rest of the = questions above.  

Tricci > THANK YOU for asking a good question. =  Cheers.

Thanks,
 
Dharmanandana Reddy Pothula.
 
& = yle=3D'font-size:10.0pt;font-family:"Arial","sans-serif&qu= ot;'>  
_______________________________________________
IPsec = mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

 
--------------------------------------------------------
ZTE Information Security Notice: The information contained = in this mail is solely property of the sender's organization. This mail = communication is confidential. Recipient
bsp;are obligated to = maintain secrecy and are not permitted to disclose the contents of this = communication to others.
This email = and any files transmitted with it are confidential and intended solely = for the use of the individual or entity to whom they are addressed. If = you have received this email in error please notify the originator of = the message. Any views expressed in this message are those of the = individual sender.
This = message has been scanned for viruses and Spam by ZTE Anti-Spam = system.

= --Boundary_(ID_8fnwEsfxLGWnMiHoUeBCGA)-- From dharmanandana.pothulam@huawei.com Fri Feb 3 06:19:22 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D4F21F856A for ; Fri, 3 Feb 2012 06:19:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.954 X-Spam-Level: X-Spam-Status: No, score=-5.954 tagged_above=-999 required=5 tests=[AWL=0.644, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMYeBgVXNR05 for ; Fri, 3 Feb 2012 06:19:21 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 706F521F8540 for ; Fri, 3 Feb 2012 06:19:21 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LYT00AXPMG6TH@szxga05-in.huawei.com> for ipsec@ietf.org; Fri, 03 Feb 2012 22:19:18 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LYT009GLMG6HX@szxga05-in.huawei.com> for ipsec@ietf.org; Fri, 03 Feb 2012 22:19:18 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGR53465; Fri, 03 Feb 2012 22:19:18 +0800 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 03 Feb 2012 22:19:09 +0800 Received: from blrprnc06ns (10.18.96.95) by szxeml406-hub.china.huawei.com (10.82.67.93) with Microsoft SMTP Server id 14.1.323.3; Fri, 03 Feb 2012 22:19:11 +0800 Date: Fri, 03 Feb 2012 19:49:10 +0530 From: Dharmanandana Reddy Pothula X-Originating-IP: [10.18.96.95] To: tso@zteusa.com Message-id: <000501cce27e$cc7c5a00$65750e00$%pothulam@huawei.com> Organization: HTIPL MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_/f4NmlE79GcTNYVV5J3tHg)" Content-language: en-us Thread-index: AczifsvjtxssTUMVTIGqVIAfJswN4g== X-CFilter-Loop: Reflected Cc: ipsec@ietf.org Subject: [IPsec] [IPSec]: IKEv2 configuration payload extension for draft-so-ipsecme-ikev2-cpext-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dharmanandana.pothulam@huawei.com List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 14:19:22 -0000 --Boundary_(ID_/f4NmlE79GcTNYVV5J3tHg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Tricci, My understanding follows. Please correct me, if I am wrong. The proposed solution is required only when NA(P)T is detected. The FAP(Initiator) should advertise support for NAT Traversal, so it must send NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP payloads in the IKE_SA_INIT request. I meant NAT is not optional for this proposed solution. So I feel it may be appropriate to mention 'NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP' payloads in high level control flow in section 3. Is not it? Regards, Dharmanandana Reddy Pothula --Boundary_(ID_/f4NmlE79GcTNYVV5J3tHg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Tricci,

 

My understanding follows. Please correct me, if I am wrong.

 

The proposed solution is required only when NA(P)T is detected. The FAP(Initiator) should advertise support for NAT Traversal, so it must send NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP payloads in the IKE_SA_INIT request.  

 

I meant NAT is not optional for this proposed solution. So I feel it may be appropriate to mention ‘NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP’ payloads in high level control flow in section 3. Is not it?

 

Regards,

--Boundary_(ID_/f4NmlE79GcTNYVV5J3tHg)-- From dharmanandana.pothulam@huawei.com Tue Feb 7 03:27:51 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5273321F8602; Tue, 7 Feb 2012 03:27:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.308 X-Spam-Level: X-Spam-Status: No, score=-4.308 tagged_above=-999 required=5 tests=[AWL=-1.260, BAYES_00=-2.599, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrPklx8vho57; Tue, 7 Feb 2012 03:27:50 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 8258321F85E4; Tue, 7 Feb 2012 03:27:49 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZ00063AT3RS8@szxga04-in.huawei.com>; Tue, 07 Feb 2012 19:26:15 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZ000MQCT3GY4@szxga04-in.huawei.com>; Tue, 07 Feb 2012 19:26:15 +0800 (CST) Received: from szxeml212-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGX32847; Tue, 07 Feb 2012 19:26:14 +0800 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by szxeml212-edg.china.huawei.com (172.24.2.181) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 07 Feb 2012 19:25:44 +0800 Received: from blrprnc06ns (10.18.96.95) by szxeml417-hub.china.huawei.com (10.82.67.156) with Microsoft SMTP Server id 14.1.323.3; Tue, 07 Feb 2012 19:26:02 +0800 Date: Tue, 07 Feb 2012 16:56:01 +0530 From: Dharmanandana Reddy Pothula In-reply-to: X-Originating-IP: [10.18.96.95] To: zong.zaifeng@zte.com.cn Message-id: <002501cce58b$462e5c40$d28b14c0$%pothulam@huawei.com> Organization: HTIPL MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_I8I8r2ISbmyp0TbG9QVLmw)" Content-language: en-us Thread-index: AczhhCDaW78p6KnyQZC9X1puFS8AcgEAooAA X-CFilter-Loop: Reflected References: <000001cce005$2833bf40$789b3dc0$%pothulam@huawei.com> Cc: ipsec@ietf.org, ipsec-bounces@ietf.org, tso@zteusa.com Subject: Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dharmanandana.pothulam@huawei.com List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 11:27:51 -0000 --Boundary_(ID_I8I8r2ISbmyp0TbG9QVLmw) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Hi Zaifeng, =20 Suppose authentication succeeds but verification fails due to false information sent by FAP, so IPSec tunnel will not be up, so Is there any response from responder to Initiator indicating IKE message received = with false configuration information from FAP? How to address this particular error scenario? Regards, Dharmanandana Reddy Pothula. =20 =20 From: zong.zaifeng@zte.com.cn [mailto:zong.zaifeng@zte.com.cn]=20 Sent: Thursday, February 02, 2012 1:51 PM To: dharmanandana.pothulam@huawei.com Cc: ipsec@ietf.org; ipsec-bounces@ietf.org; tso@zteusa.com Subject: =B4=F0=B8=B4: RE: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt =20 Hi Dharmanandana:=20 The notarized signature will not be sent oin every IPSec packet. It will = be sent to core network when the FAP registers to the core network inside = the signalling between the FAP and core network. After it is registered to = the core network, the FAP is activated to accept attachment of mobile = terminals. I wish this clarifies. Thanks!=20 BR=20 Zaifeng =20 Dharmanandana Reddy Pothula =20 2012-01-31 18:43=20 =C7=EB=B4=F0=B8=B4 =B8=F8 dharmanandana.pothulam@huawei.com =CA=D5=BC=FE=C8=CB tso@zteusa.com=20 =B3=AD=CB=CD ipsec@ietf.org, ipsec-bounces@ietf.org, zong.zaifeng@zte.com.cn=20 =D6=F7=CC=E2 RE: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt =20 =09 Hi Tricci,=20 =20 Thanks for your explanation. I get your point why notarized signature required, but my question is not about notarizing every packet. Let me = ask my question in different way, Is FAP sends notarized signature in every IPSec packet to core network? As I understand from the draft that before accepting every IPSec packet, core network validate the notarized = signature. Where is this notarized signature placed in every IPSec packet?=20 Thanks,=20 Dharmanandana Reddy Pothula=20 =20 From: tso@zteusa.com [mailto:tso@zteusa.com]=20 Sent: Wednesday, January 25, 2012 1:26 PM To: dharmanandana.pothulam@huawei.com Cc: ipsec@ietf.org; ipsec-bounces@ietf.org; zong.zaifeng@zte.com.cn; tso@zteusa.com Subject: Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev=20 =20 Dear Dharmanandana,=20 I hope that I address you correctly. If not, please pardon my = ignorance.=20 As this week is spring festival, ZaiFeng is not available. Hence, I = would like to respond to you on behalf of her. =20 Could you please kind see my responses to you inline below. Many = thanks.=20 Tricci=20 5pt;font-family:"Arial","sans-serif"'>Dharmanandana Reddy =20 Sent by: ipsec-bounces@ietf.org=20 01/24/2012 04:04 AM=20 =20 Please respond to dharmanandana.pothulam@huawei.com =20 To=20 zong.zaifeng@zte.com.cn=20 cc ipsec@ietf.org=20 Subject Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt =20 =20 =09 Hi Zaifeng,=20 =20 I have following questions and concerns about your proposed solution = "The FAP will then send the FAP information together with the corresponding = SeGW notarized signature to its mobile operator's core network. The core = network verifies the FAP information by validating the SeGW notarized signature prior to the acceptance of the information".=20 Is every ip packet carries SeGW notarized signature after server sends notarized signature to the client? if not, what's the point in returning notarized signature to the client? I believe yes, if so, It will = increase percentage of overhead per packet and may impact quality of real time = voice and video.=20 Tricci > You ask a very legitimate question. May be our draft is not = clear enough to explain the main motivation of this draft for target of the attack. =20 Tricci > The main concern is not about the attack for "unauthorized FAP" = to send any data to the mobile core network. The main concern is about the attack of the "unauthorized FAP" to send the "false" configuration information (e.g. such as changing the FAP from "Closed" to become = "Open" ;false" access control related information (e.g. allowing a 3GPP UE = which is supposed to be allowed to access the FAP and to have the access = privileage to the FAP - i.e. CSG info alteration, etc.). Once the FAP's = configuration and access control management are authenticated via the support of the notarization by the SeGW, then, the rest of the 3GPP UEs' access to the = FAP can follow the existing access control and UE-based authentication/authorization procedures at the UE level's. =20 Tricci > Of course, once the UE is authenticated and to allow access to = the FAP, whatever the UE sends is beyond the control of the FAP just as what = is happened today for any mobile device. Isn't it? =20 =20 if every ip packet carries SeGW notarized signature, How and where this signature carried inside ip packet? cations inside IPsec packet = processing? Is this processing happens outside of IPsec? is it outside scope of this document? It would be great, if some of these aspects are addressed in = the draft.=20 =20 Tricci > Since I have already explained to you that, we are not = proposing to notarize every single packet sent by FAP. Hence, I don't think that I = need to respond to your rest of the questions above. =20 Tricci > THANK YOU for asking a good question. Cheers.=20 Thanks,=20 =20 Dharmanandana Reddy Pothula.=20 =20 & yle=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'> =20 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec =20 --------------------------------------------------------=20 ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication is confidential. Recipient bsp;are obligated to maintain secrecy and are not permitted to disclose = the contents of this communication to others.=20 This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the originator of = the message. Any views expressed in this message are those of the individual sender.=20 This message has been scanned for viruses and Spam by ZTE Anti-Spam = system.=20 --Boundary_(ID_I8I8r2ISbmyp0TbG9QVLmw) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

= Hi Zaifeng,

=  

= Suppose authentication succeeds but verification fails due to false = information sent by FAP, so IPSec tunnel will not be up, so Is there any = response from responder to Initiator indicating IKE message received = with false configuration information from FAP? How to address this = particular error scenario?

=

= Regards,

= Dharmanandana Reddy Pothula.

 

 

From:= = zong.zaifeng@zte.com.cn [mailto:zong.zaifeng@zte.com.cn] =
Sent: Thursday, February 02, 2012 1:51 PM
To: = dharmanandana.pothulam@huawei.com
Cc: ipsec@ietf.org; = ipsec-bounces@ietf.org; tso@zteusa.com
Subject: =B4=F0=B8=B4: RE: = [IPsec] [IPSec]: New Version Notification for = draft-zong-ipsecme-ikev2-cpext4femto-00.txt

 


Hi = Dharmanandana:

The = notarized signature will not be sent oin every IPSec packet. It will be = sent to core network when the FAP registers to the core network inside = the signalling between the FAP and core network. After it is registered = to the core network, the FAP is activated to accept attachment of mobile = terminals. I wish this clarifies. Thanks!

BR =
Zaifeng

  =

Dharmanandana = Reddy Pothula <dharmanandana.pothulam@huawei.com> =

2012-01-31 = 18:43

=C7=EB=B4=F0=B8=B4 = =B8=F8
dharmanand= ana.pothulam@huawei.com

tso@zteusa.com=

=CA=D5=BC=FE=C8=CB

=B3=AD=CB=CD

ipsec@ietf.org= , ipsec-bounces@ietf.org, zong.zaifeng@zte.com.cn =

=D6=F7=CC=E2

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

 




Hi Tricci,
 
Thanks for your explanation. I get your point why notarized signature = required, but my question is not about notarizing every packet. Let me = ask my question in different way, Is FAP sends notarized signature in = every IPSec packet to core network? As I understand from the draft that = before accepting every IPSec packet, core network validate the notarized = signature. Where is this notarized signature placed in every IPSec = packet?
Thanks,
Dharmanandana Reddy Pothula
 
From:= = tso@zteusa.com [mailto:tso@zteusa.com]
Sent: Wednesday, = January 25, 2012 1:26 PM
To: = dharmanandana.pothulam@huawei.com
Cc: ipsec@ietf.org; = ipsec-bounces@ietf.org; zong.zaifeng@zte.com.cn; = tso@zteusa.com
Subject: Re: [IPsec] [IPSec]: New Version = Notification for draft-zong-ipsecme-ikev
 
Dear = Dharmanandana,

I hope that I = address you correctly.  If not, please pardon my ignorance. =

As this week = is spring festival, ZaiFeng is not available.  Hence, I would like = to respond to you on behalf of her.  

Could you = please kind see my responses to you inline below.  Many = thanks. =
Tricci =

5pt;font-family:"Arial","sans-serif"'= >Dharmanandana Reddy = <dharmanandana.pothulam@huawei.com>
Sent by: = ipsec-bounces@ietf.org

01/24/2012 = 04:04 AM =

 

Please = respond = to
dharmanandana.pothulam@huawei.com

 

To =

zong.zaifeng@z= te.com.cn =

cc=

ipsec@ietf.org= =

Subject=

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


  =

 





Hi Zaifeng,
 
I have following questions and = concerns about your proposed solution "The FAP will then send the = FAP information together with the corresponding SeGW notarized signature = to its mobile operator's core network. The core network verifies the FAP = information by validating the SeGW notarized signature prior to the = acceptance of the information".
Is every ip packet = carries SeGW notarized signature after server sends notarized signature = to the client? if not, what's the point in returning notarized signature = to the client? I believe yes, if so, It will increase percentage of = overhead per packet and may impact quality of real time voice and video. =

Tricci = > You ask a very legitimate question.  May be our draft is not = clear enough to explain the main motivation of this draft for target of = the attack.  

Tricci > The main concern is not about the = attack for "unauthorized FAP" to send any data to the mobile = core network.  The main concern is about the attack of the = "unauthorized FAP" to send the "false" configuration = information (e.g. such as changing the FAP from "Closed" to = become "Open" ;false" access control related information = (e.g. allowing a 3GPP UE which is supposed to be allowed to access the = FAP and to have the access privileage to the FAP - i.e. CSG info = alteration, etc.).  Once the FAP's configuration and access control = management are authenticated via the support of the notarization by the = SeGW, then, the rest of the 3GPP UEs' access to the FAP can follow the = existing access control and UE-based authentication/authorization = procedures at the UE level's.  

Tricci > Of course, = once the UE is authenticated and to allow access to the FAP, whatever = the UE sends is beyond the control of the FAP just as what is happened = today for any mobile device.  Isn't it?  
 
if every ip packet carries SeGW = notarized signature, How and where this signature carried inside ip = packet? cations inside IPsec packet processing? Is this processing = happens outside of IPsec? is it outside scope of this document? It would = be great, if some of these aspects are addressed in the = draft. =
 
Tricci > Since I have = already explained to you that, we are not proposing to notarize every = single packet sent by FAP.  Hence, I don't think that I need to = respond to your rest of the questions above.  

Tricci > THANK YOU for = asking a good question.  Cheers.

Thanks,
 
Dharmanandana Reddy = Pothula. =
 
& = yle=3D'font-size:10.0pt;font-family:"Arial","sans-serif&qu= ot;'>  
_______________________________________________
IPsec mailing = list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

  =
-------------------------------------------------------- =
ZTE = Information Security Notice: The information contained in this mail is = solely property of the sender's organization. This mail communication is = confidential. Recipient
bsp;are obligated to maintain secrecy and are = not permitted to disclose the contents of this communication to = others.
This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender.
This message has = been scanned for viruses and Spam by ZTE Anti-Spam system. =

= --Boundary_(ID_I8I8r2ISbmyp0TbG9QVLmw)-- From dharmanandana.pothulam@huawei.com Tue Feb 7 04:18:09 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 593C021F86D9; Tue, 7 Feb 2012 04:18:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[AWL=-1.050, BAYES_00=-2.599, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfMtp-7dyW8E; Tue, 7 Feb 2012 04:18:08 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 2FDD921F86CB; Tue, 7 Feb 2012 04:18:07 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZ000GBHVHP0E@szxga05-in.huawei.com>; Tue, 07 Feb 2012 20:17:49 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZ0008D4VHP48@szxga05-in.huawei.com>; Tue, 07 Feb 2012 20:17:49 +0800 (CST) Received: from szxeml213-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGX37707; Tue, 07 Feb 2012 20:17:48 +0800 Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153) by szxeml213-edg.china.huawei.com (172.24.2.30) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 07 Feb 2012 20:17:09 +0800 Received: from blrprnc06ns (10.18.96.95) by SZXEML414-HUB.china.huawei.com (10.82.67.153) with Microsoft SMTP Server id 14.1.323.3; Tue, 07 Feb 2012 20:17:58 +0800 Date: Tue, 07 Feb 2012 17:47:35 +0530 From: Dharmanandana Reddy Pothula In-reply-to: X-Originating-IP: [10.18.96.95] To: zong.zaifeng@zte.com.cn Message-id: <002a01cce592$7a7d4e00$6f77ea00$%pothulam@huawei.com> Organization: HTIPL MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_qPzAM66sc0NMxZzGdzUvPA)" Content-language: en-us Thread-index: AczhhCDaW78p6KnyQZC9X1puFS8AcgECHDDQ X-CFilter-Loop: Reflected References: <000001cce005$2833bf40$789b3dc0$%pothulam@huawei.com> Cc: ipsec@ietf.org, ipsec-bounces@ietf.org, tso@zteusa.com Subject: Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dharmanandana.pothulam@huawei.com List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 12:18:09 -0000 --Boundary_(ID_qPzAM66sc0NMxZzGdzUvPA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Hi Zaifeng, =20 About error condition, Is there any plan to add new error message types = to Notify payload to handle verification fail scenarios? I feel it would appropriate to inform FAP, so this helps FAP to correct if = misconfigured. =20 I have one more question about the proposed solution. Can=A1=AFt we = handle verifying FAP configuration information inside Femto Gateway? Femto = Gateway can inform security gateway to bring down the tunnel, if verification = fails. Anyway false information submission very unlikely scenario, so why we = need to make this config payload exchange as part of regular IKE negotiation? = I feel addition of more config payloads might impact tunnel setup rate. =20 Regards, Dharmanandana Reddy Pothula =20 From: zong.zaifeng@zte.com.cn [mailto:zong.zaifeng@zte.com.cn]=20 Sent: Thursday, February 02, 2012 1:51 PM To: dharmanandana.pothulam@huawei.com Cc: ipsec@ietf.org; ipsec-bounces@ietf.org; tso@zteusa.com Subject: =B4=F0=B8=B4: RE: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt =20 Hi Dharmanandana:=20 The notarized signature will not be sent oin every IPSec packet. It will = be sent to core network when the FAP registers to the core network inside = the signalling between the FAP and core network. After it is registered to = the core network, the FAP is activated to accept attachment of mobile = terminals. I wish this clarifies. Thanks!=20 BR=20 Zaifeng =20 Dharmanandana Reddy Pothula =20 2012-01-31 18:43=20 =C7=EB=B4=F0=B8=B4 =B8=F8 dharmanandana.pothulam@huawei.com =CA=D5=BC=FE=C8=CB tso@zteusa.com=20 =B3=AD=CB=CD ipsec@ietf.org, ipsec-bounces@ietf.org, zong.zaifeng@zte.com.cn=20 =D6=F7=CC=E2 RE: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt =20 =09 Hi Tricci,=20 =20 Thanks for your explanation. I get your point why notarized signature required, but my question is not about notarizing every packet. Let me = ask my question in different way, Is FAP sends notarized signature in every IPSec packet to core network? As I understand from the draft that before accepting every IPSec packet, core network validate the notarized = signature. Where is this notarized signature placed in every IPSec packet?=20 Thanks,=20 Dharmanandana Reddy Pothula=20 =20 From: tso@zteusa.com [mailto:tso@zteusa.com]=20 Sent: Wednesday, January 25, 2012 1:26 PM To: dharmanandana.pothulam@huawei.com Cc: ipsec@ietf.org; ipsec-bounces@ietf.org; zong.zaifeng@zte.com.cn; tso@zteusa.com Subject: Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev=20 =20 Dear Dharmanandana,=20 I hope that I address you correctly. If not, please pardon my = ignorance.=20 As this week is spring festival, ZaiFeng is not available. Hence, I = would like to respond to you on behalf of her. =20 Could you please kind see my responses to you inline below. Many = thanks.=20 Tricci=20 5pt;font-family:"Arial","sans-serif"'>Dharmanandana Reddy =20 Sent by: ipsec-bounces@ietf.org=20 01/24/2012 04:04 AM=20 =20 Please respond to dharmanandana.pothulam@huawei.com =20 To=20 zong.zaifeng@zte.com.cn=20 cc ipsec@ietf.org=20 Subject Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt =20 =20 =09 Hi Zaifeng,=20 =20 I have following questions and concerns about your proposed solution = "The FAP will then send the FAP information together with the corresponding = SeGW notarized signature to its mobile operator's core network. The core = network verifies the FAP information by validating the SeGW notarized signature prior to the acceptance of the information".=20 Is every ip packet carries SeGW notarized signature after server sends notarized signature to the client? if not, what's the point in returning notarized signature to the client? I believe yes, if so, It will = increase percentage of overhead per packet and may impact quality of real time = voice and video.=20 Tricci > You ask a very legitimate question. May be our draft is not = clear enough to explain the main motivation of this draft for target of the attack. =20 Tricci > The main concern is not about the attack for "unauthorized FAP" = to send any data to the mobile core network. The main concern is about the attack of the "unauthorized FAP" to send the "false" configuration information (e.g. such as changing the FAP from "Closed" to become = "Open" ;false" access control related information (e.g. allowing a 3GPP UE = which is supposed to be allowed to access the FAP and to have the access = privileage to the FAP - i.e. CSG info alteration, etc.). Once the FAP's = configuration and access control management are authenticated via the support of the notarization by the SeGW, then, the rest of the 3GPP UEs' access to the = FAP can follow the existing access control and UE-based authentication/authorization procedures at the UE level's. =20 Tricci > Of course, once the UE is authenticated and to allow access to = the FAP, whatever the UE sends is beyond the control of the FAP just as what = is happened today for any mobile device. Isn't it? =20 =20 if every ip packet carries SeGW notarized signature, How and where this signature carried inside ip packet? cations inside IPsec packet = processing? Is this processing happens outside of IPsec? is it outside scope of this document? It would be great, if some of these aspects are addressed in = the draft.=20 =20 Tricci > Since I have already explained to you that, we are not = proposing to notarize every single packet sent by FAP. Hence, I don't think that I = need to respond to your rest of the questions above. =20 Tricci > THANK YOU for asking a good question. Cheers.=20 Thanks,=20 =20 Dharmanandana Reddy Pothula.=20 =20 & yle=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'> =20 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec =20 --------------------------------------------------------=20 ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication is confidential. Recipient bsp;are obligated to maintain secrecy and are not permitted to disclose = the contents of this communication to others.=20 This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the originator of = the message. Any views expressed in this message are those of the individual sender.=20 This message has been scanned for viruses and Spam by ZTE Anti-Spam = system.=20 --Boundary_(ID_qPzAM66sc0NMxZzGdzUvPA) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

= Hi Zaifeng,

=  

= About error condition, Is there any plan to add new error message types = to Notify payload to handle verification fail scenarios? I feel it would = appropriate to inform FAP, so this helps FAP to correct if = misconfigured.

=  

= I have one more question about the proposed solution. Can=A1=AFt we = handle verifying FAP configuration information inside Femto Gateway? = Femto Gateway can inform security gateway to bring down the tunnel, if = verification fails. Anyway false information submission very unlikely = scenario, so why we need to make this config payload exchange as part of = regular IKE negotiation? I feel addition of more config payloads might = impact tunnel setup rate.

=  

= Regards,

= Dharmanandana Reddy Pothula

 

From:= = zong.zaifeng@zte.com.cn [mailto:zong.zaifeng@zte.com.cn] =
Sent: Thursday, February 02, 2012 1:51 PM
To: = dharmanandana.pothulam@huawei.com
Cc: ipsec@ietf.org; = ipsec-bounces@ietf.org; tso@zteusa.com
Subject: =B4=F0=B8=B4: RE: = [IPsec] [IPSec]: New Version Notification for = draft-zong-ipsecme-ikev2-cpext4femto-00.txt

 


Hi = Dharmanandana:

The = notarized signature will not be sent oin every IPSec packet. It will be = sent to core network when the FAP registers to the core network inside = the signalling between the FAP and core network. After it is registered = to the core network, the FAP is activated to accept attachment of mobile = terminals. I wish this clarifies. Thanks!

BR =
Zaifeng

  =

Dharmanandana = Reddy Pothula <dharmanandana.pothulam@huawei.com> =

2012-01-31 = 18:43

=C7=EB=B4=F0=B8=B4 = =B8=F8
dharmanand= ana.pothulam@huawei.com

tso@zteusa.com=

=CA=D5=BC=FE=C8=CB

=B3=AD=CB=CD

ipsec@ietf.org= , ipsec-bounces@ietf.org, zong.zaifeng@zte.com.cn =

=D6=F7=CC=E2

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

 




Hi Tricci,
 
Thanks for your explanation. I get your point why notarized signature = required, but my question is not about notarizing every packet. Let me = ask my question in different way, Is FAP sends notarized signature in = every IPSec packet to core network? As I understand from the draft that = before accepting every IPSec packet, core network validate the notarized = signature. Where is this notarized signature placed in every IPSec = packet?
Thanks,
Dharmanandana Reddy Pothula
 
From:= = tso@zteusa.com [mailto:tso@zteusa.com]
Sent: Wednesday, = January 25, 2012 1:26 PM
To: = dharmanandana.pothulam@huawei.com
Cc: ipsec@ietf.org; = ipsec-bounces@ietf.org; zong.zaifeng@zte.com.cn; = tso@zteusa.com
Subject: Re: [IPsec] [IPSec]: New Version = Notification for draft-zong-ipsecme-ikev
 
Dear = Dharmanandana,

I hope that I = address you correctly.  If not, please pardon my ignorance. =

As this week = is spring festival, ZaiFeng is not available.  Hence, I would like = to respond to you on behalf of her.  

Could you = please kind see my responses to you inline below.  Many = thanks. =
Tricci =

5pt;font-family:"Arial","sans-serif"'= >Dharmanandana Reddy = <dharmanandana.pothulam@huawei.com>
Sent by: = ipsec-bounces@ietf.org

01/24/2012 = 04:04 AM =

 

Please = respond = to
dharmanandana.pothulam@huawei.com

 

To =

zong.zaifeng@z= te.com.cn =

cc=

ipsec@ietf.org= =

Subject=

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


  =

 





Hi Zaifeng,
 
I have following questions and = concerns about your proposed solution "The FAP will then send the = FAP information together with the corresponding SeGW notarized signature = to its mobile operator's core network. The core network verifies the FAP = information by validating the SeGW notarized signature prior to the = acceptance of the information".
Is every ip packet = carries SeGW notarized signature after server sends notarized signature = to the client? if not, what's the point in returning notarized signature = to the client? I believe yes, if so, It will increase percentage of = overhead per packet and may impact quality of real time voice and video. =

Tricci = > You ask a very legitimate question.  May be our draft is not = clear enough to explain the main motivation of this draft for target of = the attack.  

Tricci > The main concern is not about the = attack for "unauthorized FAP" to send any data to the mobile = core network.  The main concern is about the attack of the = "unauthorized FAP" to send the "false" configuration = information (e.g. such as changing the FAP from "Closed" to = become "Open" ;false" access control related information = (e.g. allowing a 3GPP UE which is supposed to be allowed to access the = FAP and to have the access privileage to the FAP - i.e. CSG info = alteration, etc.).  Once the FAP's configuration and access control = management are authenticated via the support of the notarization by the = SeGW, then, the rest of the 3GPP UEs' access to the FAP can follow the = existing access control and UE-based authentication/authorization = procedures at the UE level's.  

Tricci > Of course, = once the UE is authenticated and to allow access to the FAP, whatever = the UE sends is beyond the control of the FAP just as what is happened = today for any mobile device.  Isn't it?  
 
if every ip packet carries SeGW = notarized signature, How and where this signature carried inside ip = packet? cations inside IPsec packet processing? Is this processing = happens outside of IPsec? is it outside scope of this document? It would = be great, if some of these aspects are addressed in the = draft. =
 
Tricci > Since I have = already explained to you that, we are not proposing to notarize every = single packet sent by FAP.  Hence, I don't think that I need to = respond to your rest of the questions above.  

Tricci > THANK YOU for = asking a good question.  Cheers.

Thanks,
 
Dharmanandana Reddy = Pothula. =
 
& = yle=3D'font-size:10.0pt;font-family:"Arial","sans-serif&qu= ot;'>  
_______________________________________________
IPsec mailing = list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

  =
-------------------------------------------------------- =
ZTE = Information Security Notice: The information contained in this mail is = solely property of the sender's organization. This mail communication is = confidential. Recipient
bsp;are obligated to maintain secrecy and are = not permitted to disclose the contents of this communication to = others.
This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender.
This message has = been scanned for viruses and Spam by ZTE Anti-Spam system. =

= --Boundary_(ID_qPzAM66sc0NMxZzGdzUvPA)-- From tso@zteusa.com Tue Feb 7 08:40:25 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D5321F885E for ; Tue, 7 Feb 2012 08:40:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.113 X-Spam-Level: X-Spam-Status: No, score=-1.113 tagged_above=-999 required=5 tests=[AWL=0.725, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8Du+BPocfKW for ; Tue, 7 Feb 2012 08:40:24 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id A363C21F8851 for ; Tue, 7 Feb 2012 08:40:23 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 566905521606; Wed, 8 Feb 2012 00:13:46 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 48311.1296997134; Wed, 8 Feb 2012 00:40:02 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q17Ge6bg072171; Wed, 8 Feb 2012 00:40:06 +0800 (GMT-8) (envelope-from tso@zteusa.com) In-Reply-To: <000501cce27e$cc7c5a00$65750e00$%pothulam@huawei.com> References: <000501cce27e$cc7c5a00$65750e00$%pothulam@huawei.com> To: dharmanandana.pothulam@huawei.com MIME-Version: 1.0 X-KeepSent: 0B218BEA:8C6FABE5-8825799D:005A86F0; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: tso@zteusa.com Date: Tue, 7 Feb 2012 08:38:27 -0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-02-08 00:40:08, Serialize complete at 2012-02-08 00:40:08 Content-Type: multipart/alternative; boundary="=_alternative 005B90098825799D_=" X-MAIL: mse01.zte.com.cn q17Ge6bg072171 Cc: ipsec@ietf.org Subject: Re: [IPsec] [IPSec]: IKEv2 configuration payload extension for draft-so-ipsecme-ikev2-cpext-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 16:40:25 -0000 This is a multipart message in MIME format. --=_alternative 005B90098825799D_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 RGVhciBEaGFybWFuYW5kYW5lLCANCg0KU2luY2VyZWx5IHNvcnJ5IGZvciB0aGUgZGVsYXkgdG8g cmVzcG9uZCB0byB5b3UuIA0KDQpUaGFuayB5b3UgdmVyeSBtdWNoIGZvciB5b3VyIGNvbW1lbnRz IG9uIG15IGRyYWZ0LiANCg0KWWVzLCBJIGZ1bGx5IGFncmVlIHdpdGggeW91ciB1bmRlcnN0YW5k aW5nLiAgVGhlIHJlYXNvbiB0aGF0IEkgZGlkIG5vdCANCmluY2x1ZGUgdGhlc2UgdHdvIHBhcmFt ZXRlcnMgaW4gdGhlIGRyYWZ0J3Mgc2FtcGxlIGNvbnRyb2wgZmxvdyBiZWNhdXNlIA0KdGhlIGV4 aXN0aW5nIElLRXYyIFJGQyA1OTk2IGhhdmUgYWxyZWFkeSB0aGUgcHJvY2VkdXJlcyB0aGF0IGRl c2NyaWJlIHRoZSANCmRldGVjdGlvbiBvZiBOQVQuICBIZW5jZSwgSSBvbmx5IHdhbnQgdG8gZGVz Y3JpYmUgdGhlIG1pbmltdW0gdGhhdCANCmV4cGxhaW5zIHRoZSBwcm9wb3NhbCBmcm9tIHRoZSBk cmFmdC4gDQoNCkhvcGluZyB0aGF0IGl0IGlzIGFjY2VwdGFibGUgdG8geW91LiANCg0KVGhhbmtz IGFnYWluIGZvciB5b3VyIGtpbmQgc3VnZ2VzdGlvbi4NClRyaWNjaSANCg0KDQoNCg0KRGhhcm1h bmFuZGFuYSBSZWRkeSBQb3RodWxhIDxkaGFybWFuYW5kYW5hLnBvdGh1bGFtQGh1YXdlaS5jb20+ IA0KMDIvMDMvMjAxMiAwNjoxOSBBTQ0KUGxlYXNlIHJlc3BvbmQgdG8NCmRoYXJtYW5hbmRhbmEu cG90aHVsYW1AaHVhd2VpLmNvbQ0KDQoNClRvDQp0c29AenRldXNhLmNvbQ0KY2MNCmlwc2VjQGll dGYub3JnDQpTdWJqZWN0DQpbSVBTZWNdOiBJS0V2MiBjb25maWd1cmF0aW9uIHBheWxvYWQgZXh0 ZW5zaW9uIGZvciANCmRyYWZ0LXNvLWlwc2VjbWUtaWtldjItY3BleHQtMDAudHh0DQoNCg0KDQoN Cg0KDQpIaSBUcmljY2ksDQogDQpNeSB1bmRlcnN0YW5kaW5nIGZvbGxvd3MuIFBsZWFzZSBjb3Jy ZWN0IG1lLCBpZiBJIGFtIHdyb25nLg0KIA0KVGhlIHByb3Bvc2VkIHNvbHV0aW9uIGlzIHJlcXVp cmVkIG9ubHkgd2hlbiBOQShQKVQgaXMgZGV0ZWN0ZWQuIFRoZSANCkZBUChJbml0aWF0b3IpIHNo b3VsZCBhZHZlcnRpc2Ugc3VwcG9ydCBmb3IgTkFUIFRyYXZlcnNhbCwgc28gaXQgbXVzdCBzZW5k IA0KTkFUX0RFVEVDVElPTl9TT1VSQ0VfSVAgYW5kIE5BVF9ERVRFQ1RJT05fREVTVElOQVRJT05f SVAgcGF5bG9hZHMgaW4gdGhlIA0KSUtFX1NBX0lOSVQgcmVxdWVzdC4gDQogDQpJIG1lYW50IE5B VCBpcyBub3Qgb3B0aW9uYWwgZm9yIHRoaXMgcHJvcG9zZWQgc29sdXRpb24uIFNvIEkgZmVlbCBp dCBtYXkgDQpiZSBhcHByb3ByaWF0ZSB0byBtZW50aW9uIOKAmE5BVF9ERVRFQ1RJT05fU09VUkNF X0lQIGFuZCANCk5BVF9ERVRFQ1RJT05fREVTVElOQVRJT05fSVDigJkgcGF5bG9hZHMgaW4gaGln aCBsZXZlbCBjb250cm9sIGZsb3cgaW4gDQpzZWN0aW9uIDMuIElzIG5vdCBpdD8NCiANClJlZ2Fy ZHMsDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0 aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5k ZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlh bC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3Jl Y3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlz IGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5z bWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0 aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJl c3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90 aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGlu IHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBt ZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGkt U3BhbSBzeXN0ZW0uDQo= --=_alternative 005B90098825799D_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPkRlYXIgRGhhcm1hbmFuZGFuZSwgPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5TaW5jZXJlbHkgc29y cnkgZm9yIHRoZSBkZWxheSB0byByZXNwb25kDQp0byB5b3UuIDwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91 ciBjb21tZW50cw0Kb24gbXkgZHJhZnQuIDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+WWVzLCBJIGZ1bGx5IGFncmVlIHdpdGggeW91ciB1bmRlcnN0YW5k aW5nLg0KJm5ic3A7VGhlIHJlYXNvbiB0aGF0IEkgZGlkIG5vdCBpbmNsdWRlIHRoZXNlIHR3byBw YXJhbWV0ZXJzIGluIHRoZSBkcmFmdCdzDQpzYW1wbGUgY29udHJvbCBmbG93IGJlY2F1c2UgdGhl IGV4aXN0aW5nIElLRXYyIFJGQyA1OTk2IGhhdmUgYWxyZWFkeSB0aGUNCnByb2NlZHVyZXMgdGhh dCBkZXNjcmliZSB0aGUgZGV0ZWN0aW9uIG9mIE5BVC4gJm5ic3A7SGVuY2UsIEkgb25seSB3YW50 DQp0byBkZXNjcmliZSB0aGUgbWluaW11bSB0aGF0IGV4cGxhaW5zIHRoZSBwcm9wb3NhbCBmcm9t IHRoZSBkcmFmdC4gPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNl cmlmIj5Ib3BpbmcgdGhhdCBpdCBpcyBhY2NlcHRhYmxlIHRvIHlvdS4NCiZuYnNwOzwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmtzIGFnYWluIGZv ciB5b3VyIGtpbmQgc3VnZ2VzdGlvbi48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPlRyaWNjaSA8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUg d2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM1JT48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+PGI+RGhhcm1hbmFuZGFuYSBSZWRkeSBQb3RodWxhDQombHQ7ZGhh cm1hbmFuZGFuYS5wb3RodWxhbUBodWF3ZWkuY29tJmd0OzwvYj4gPC9mb250Pg0KPHA+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjAyLzAzLzIwMTIgMDY6MTkgQU08L2ZvbnQ+DQo8dGFi bGUgYm9yZGVyPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgYmdjb2xvcj13aGl0ZT4NCjxkaXYgYWxp Z249Y2VudGVyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5QbGVhc2UgcmVzcG9uZCB0 bzxicj4NCmRoYXJtYW5hbmRhbmEucG90aHVsYW1AaHVhd2VpLmNvbTwvZm9udD48L2Rpdj48L3Rh YmxlPg0KPGJyPg0KPHRkIHdpZHRoPTY0JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGln bj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj5UbzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ dHNvQHp0ZXVzYS5jb208L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249 cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmNjPC9mb250PjwvZGl2Pg0KPHRk Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5pcHNlY0BpZXRmLm9yZzwvZm9udD4NCjx0 ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+U3ViamVjdDwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+W0lQU2VjXTogSUtFdjIgY29uZmlndXJhdGlvbiBwYXlsb2FkDQpleHRlbnNp b24gZm9yIGRyYWZ0LXNvLWlwc2VjbWUtaWtldjItY3BleHQtMDAudHh0PC9mb250PjwvdGFibGU+ DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJy PjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPkhp IFRyaWNjaSw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+TXkgdW5kZXJzdGFuZGluZyBm b2xsb3dzLiBQbGVhc2UgY29ycmVjdA0KbWUsIGlmIEkgYW0gd3JvbmcuPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9IkNhbGlicmkiPlRoZSBwcm9wb3NlZCBzb2x1dGlvbiBpcyByZXF1aXJlZCBvbmx5DQp3 aGVuIE5BKFApVCBpcyBkZXRlY3RlZC4gVGhlIEZBUChJbml0aWF0b3IpIHNob3VsZCBhZHZlcnRp c2Ugc3VwcG9ydCBmb3INCk5BVCBUcmF2ZXJzYWwsIHNvIGl0IG11c3Qgc2VuZCBOQVRfREVURUNU SU9OX1NPVVJDRV9JUCBhbmQgTkFUX0RFVEVDVElPTl9ERVNUSU5BVElPTl9JUA0KcGF5bG9hZHMg aW4gdGhlIElLRV9TQV9JTklUIHJlcXVlc3QuICZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJD YWxpYnJpIj5JIG1lYW50IE5BVCBpcyBub3Qgb3B0aW9uYWwgZm9yIHRoaXMgcHJvcG9zZWQNCnNv bHV0aW9uLiBTbyBJIGZlZWwgaXQgbWF5IGJlIGFwcHJvcHJpYXRlIHRvIG1lbnRpb24g4oCYTkFU X0RFVEVDVElPTl9TT1VSQ0VfSVANCmFuZCBOQVRfREVURUNUSU9OX0RFU1RJTkFUSU9OX0lQ4oCZ IHBheWxvYWRzIGluIGhpZ2ggbGV2ZWwgY29udHJvbCBmbG93DQppbiBzZWN0aW9uIDMuIElzIG5v dCBpdD88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+UmVnYXJkcyw8L2ZvbnQ+DQo8YnI+ DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90 aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJz cDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtv ZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJz cDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNw O1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVk Jm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJz cDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7 Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJz cDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZu YnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50 aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUm bmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2Vu dGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQu Jm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7 ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhl Jm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkm bmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2Um bmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNw O3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5u ZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7 WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 005B90098825799D_=-- From tso@zteusa.com Tue Feb 7 17:59:52 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B3721F86C3; Tue, 7 Feb 2012 17:59:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.258 X-Spam-Level: X-Spam-Status: No, score=-1.258 tagged_above=-999 required=5 tests=[AWL=0.580, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfqIEvg35xuo; Tue, 7 Feb 2012 17:59:52 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 3E77F21F8655; Tue, 7 Feb 2012 17:59:51 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 56690433787882; Wed, 8 Feb 2012 09:33:04 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 91379.433787882; Wed, 8 Feb 2012 09:59:31 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q181xb9h033164; Wed, 8 Feb 2012 09:59:37 +0800 (GMT-8) (envelope-from tso@zteusa.com) In-Reply-To: <000501cce27e$cc7c5a00$65750e00$%pothulam@huawei.com> References: <000501cce27e$cc7c5a00$65750e00$%pothulam@huawei.com> To: ipsec@ietf.org, ipsec-bounces@ietf.org MIME-Version: 1.0 X-KeepSent: 814CDA1A:00C14217-8825799E:00060595; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: tso@zteusa.com Date: Tue, 7 Feb 2012 17:57:54 -0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-02-08 09:59:37, Serialize complete at 2012-02-08 09:59:37 Content-Type: multipart/alternative; boundary="=_alternative 000AF2F68825799E_=" X-MAIL: mse01.zte.com.cn q181xb9h033164 Subject: [IPsec] [IPSec]: IKEv2 configuration payload extension for draft-so-ipsecme-ikev2-cpext-01.txt has been revised X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 01:59:52 -0000 This is a multipart message in MIME format. --=_alternative 000AF2F68825799E_= Content-Type: text/plain; charset="US-ASCII" Dear IPsecme friends, I have uploaded a new version of the draft-so-ipsecme-ikev2-cpext-01.txt. I would like to invite you to comment on this draft. http://www.ietf.org/id/draft-so-ipsecme-ikev2-cpext-01.txt The proposal of this draft is motivated by the recent fixed mobile convergence requirement for Femto that the IKE-initiator (i.e. the Femto AP (FAP)) is required to obtain its NATed IP address and port number from its IKE-responder (i.e. SeGW). Please note that, although this draft leverages the IKEv2 CP to try to resolve the issue, the "so draft" is addressing a completely different issue than the draft-zong-ipsecme-ikev2-cpext4femto-00.txt. Hence, please don't get confused by these two drafts. Your comments are most welcome. Thanks in advance. Tricci -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 000AF2F68825799E_= Content-Type: text/html; charset="US-ASCII" Dear IPsecme friends,

I have uploaded a new version of the draft-so-ipsecme-ikev2-cpext-01.txt.  I would like to invite you to comment on this draft.
http://www.ietf.org/id/draft-so-ipsecme-ikev2-cpext-01.txt

The proposal of this draft is motivated by the recent fixed mobile convergence requirement for Femto that the IKE-initiator (i.e. the Femto AP (FAP)) is required to obtain its NATed IP address and port number from its IKE-responder (i.e. SeGW).  

Please note that, although this draft leverages the IKEv2 CP to try to resolve the issue, the "so draft" is addressing a completely different issue than the draft-zong-ipsecme-ikev2-cpext4femto-00.txt.  

Hence, please don't get confused by these two drafts.  

Your comments are most welcome.  Thanks in advance.  
Tricci 


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 000AF2F68825799E_=-- From zong.zaifeng@zte.com.cn Tue Feb 7 18:36:03 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F09D111E8080; Tue, 7 Feb 2012 18:36:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -91.258 X-Spam-Level: X-Spam-Status: No, score=-91.258 tagged_above=-999 required=5 tests=[AWL=-1.982, BAYES_40=-0.185, CHARSET_FARAWAY_HEADER=3.2, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TalcOjGNSG+Z; Tue, 7 Feb 2012 18:36:02 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id D1D1311E8089; Tue, 7 Feb 2012 18:35:55 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 56690433787882; Wed, 8 Feb 2012 10:09:22 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 5467.1725263410; Wed, 8 Feb 2012 10:35:49 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q182Zccx025428; Wed, 8 Feb 2012 10:35:38 +0800 (GMT-8) (envelope-from zong.zaifeng@zte.com.cn) In-Reply-To: <002501cce58b$462e5c40$d28b14c0$%pothulam@huawei.com> To: dharmanandana.pothulam@huawei.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zong.zaifeng@zte.com.cn Date: Wed, 8 Feb 2012 10:32:48 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-02-08 10:35:39, Serialize complete at 2012-02-08 10:35:39 Content-Type: multipart/alternative; boundary="=_alternative 000E3FAD4825799E_=" X-MAIL: mse02.zte.com.cn q182Zccx025428 Cc: ipsec@ietf.org, ipsec-bounces@ietf.org, tso@zteusa.com Subject: [IPsec] =?gb2312?b?tPC4tDogUkU6IFJFOiAgW0lQU2VjXTogTmV3IFZlcnNp?= =?gb2312?b?b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC16b25nLWlwc2VjbWUtaWtldjIt?= =?gb2312?b?Y3BleHQ0ZmVtdG8tMDAudHh0?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 02:36:04 -0000 This is a multipart message in MIME format. --=_alternative 000E3FAD4825799E_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgRGhhcm1hbmFuZGFuYToNCg0KVGhlIElQU2VjIHR1bm5lbCBlc3RhYmxpc2htZW50IHdpbGwg bm90IGJlIGltcGFjdGVkIGJ5IHRoaXMgZHJhZnQsIGlmIHRoZSANCmluaXRpYXRvciBzZW5kIHNv bWUgd3JvbmcgaW5mb3JtYXRpb24gdG8gcmVzcG9uZGVyLCBpdCB3aWxsIGJlIGRldGVjdGVkIGJ5 IA0KdGhlIHJlc3BvbmRlciwgYW5kIHRoZSByZXNwb25kZXIgY2FuIHJlcGxhY2UgdGhlIHdyb25n IGluZm9ybWF0aW9uIHdpdGggDQpjb3JyZWN0IG9uZXMuIEl0IGlzIGxpa2UgSVAgYWRkcmVzcyBj b25maWd1cmF0aW9uLCB0aGUgY2xpZW50IG1heSByZXF1ZXN0IA0KYSBzcGVjaWZpYyBJUCBhZGRy ZXNzIG9yIG5vdCwgdGhlIHNlcnZlciBjYW4gYW55d2F5IGNob29zZSBhIGRpZmZlcmVudCANCm9u ZS4gVGhlIHJlc3BvbmRlciAoaS5lLiBTZUdXKSB3aWxsIGNob29zZSBjb3JyZWN0IEZBUCBjb25m aWd1cmF0aW9uIA0KaW5mb3JtYXRpb24sIGFuZCBzaWduIHRoaXMgaW5mb3JtYXRpb24sIHNvIHRo YXQgdGhlIEZBUCB3aWxsIG5vdCBiZSBhYmxlIA0KdG8gY2hhbmdlIGl0LiBUaGlzIEZBUCBjb25m aWd1cmF0aW9uIGluZm9ybWF0aW9uIHdpbGwgbGF0ZXIgYmUgc2VudCBieSB0aGUgDQpGQVAgdG8g dGhlIGNvcmUgbmV0d29yayAoaW5zaWRlIHRoZSBJUHNlYyB0dW5uZWwgYXMgcGF5bG9hZCBvZiBz aWduYWxsaW5nIA0KYmV0d2VlbiBGQVAgYW5kIGNvcmUgbmV0d29yayksIGFuZCB0aGUgY29yZSBu ZXR3b3JrIHdpbGwgdmVyaWZ5IHRoZSANCmluZm9ybWF0aW9uIGJhc2VkIG9uIHRoZSBzaWduYXR1 cmUuIA0KDQpJIHdpc2ggdGhpcyBjbGFyaWZpZXMuIFRoYW5rcyENCg0KQlINClphaWZlbmcNCiAN Cg0KDQoNCkRoYXJtYW5hbmRhbmEgUmVkZHkgUG90aHVsYSA8ZGhhcm1hbmFuZGFuYS5wb3RodWxh bUBodWF3ZWkuY29tPiANCjIwMTItMDItMDcgMTk6MjYNCsfrtPC4tCC4+A0KZGhhcm1hbmFuZGFu YS5wb3RodWxhbUBodWF3ZWkuY29tDQoNCg0KytW8/sjLDQp6b25nLnphaWZlbmdAenRlLmNvbS5j bg0Ks63LzQ0KaXBzZWNAaWV0Zi5vcmcsIGlwc2VjLWJvdW5jZXNAaWV0Zi5vcmcsIHRzb0B6dGV1 c2EuY29tDQrW98ziDQpSRTogUkU6IFtJUHNlY10gW0lQU2VjXTogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciANCmRyYWZ0LXpvbmctaXBzZWNtZS1pa2V2Mi1jcGV4dDRmZW10by0wMC50eHQN Cg0KDQoNCg0KDQoNCkhpIFphaWZlbmcsDQogDQpTdXBwb3NlIGF1dGhlbnRpY2F0aW9uIHN1Y2Nl ZWRzIGJ1dCB2ZXJpZmljYXRpb24gZmFpbHMgZHVlIHRvIGZhbHNlIA0KaW5mb3JtYXRpb24gc2Vu dCBieSBGQVAsIHNvIElQU2VjIHR1bm5lbCB3aWxsIG5vdCBiZSB1cCwgc28gSXMgdGhlcmUgYW55 IA0KcmVzcG9uc2UgZnJvbSByZXNwb25kZXIgdG8gSW5pdGlhdG9yIGluZGljYXRpbmcgSUtFIG1l c3NhZ2UgcmVjZWl2ZWQgd2l0aCANCmZhbHNlIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24gZnJv bSBGQVA/IEhvdyB0byBhZGRyZXNzIHRoaXMgcGFydGljdWxhciANCmVycm9yIHNjZW5hcmlvPw0K UmVnYXJkcywNCkRoYXJtYW5hbmRhbmEgUmVkZHkgUG90aHVsYS4NCiANCiANCkZyb206IHpvbmcu emFpZmVuZ0B6dGUuY29tLmNuIFttYWlsdG86em9uZy56YWlmZW5nQHp0ZS5jb20uY25dIA0KU2Vu dDogVGh1cnNkYXksIEZlYnJ1YXJ5IDAyLCAyMDEyIDE6NTEgUE0NClRvOiBkaGFybWFuYW5kYW5h LnBvdGh1bGFtQGh1YXdlaS5jb20NCkNjOiBpcHNlY0BpZXRmLm9yZzsgaXBzZWMtYm91bmNlc0Bp ZXRmLm9yZzsgdHNvQHp0ZXVzYS5jb20NClN1YmplY3Q6ILTwuLQ6IFJFOiBbSVBzZWNdIFtJUFNl Y106IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgDQpkcmFmdC16b25nLWlwc2VjbWUtaWtl djItY3BleHQ0ZmVtdG8tMDAudHh0DQogDQoNCkhpIERoYXJtYW5hbmRhbmE6IA0KDQpUaGUgbm90 YXJpemVkIHNpZ25hdHVyZSB3aWxsIG5vdCBiZSBzZW50IG9pbiBldmVyeSBJUFNlYyBwYWNrZXQu IEl0IHdpbGwgDQpiZSBzZW50IHRvIGNvcmUgbmV0d29yayB3aGVuIHRoZSBGQVAgcmVnaXN0ZXJz IHRvIHRoZSBjb3JlIG5ldHdvcmsgaW5zaWRlIA0KdGhlIHNpZ25hbGxpbmcgYmV0d2VlbiB0aGUg RkFQIGFuZCBjb3JlIG5ldHdvcmsuIEFmdGVyIGl0IGlzIHJlZ2lzdGVyZWQgdG8gDQp0aGUgY29y ZSBuZXR3b3JrLCB0aGUgRkFQIGlzIGFjdGl2YXRlZCB0byBhY2NlcHQgYXR0YWNobWVudCBvZiBt b2JpbGUgDQp0ZXJtaW5hbHMuIEkgd2lzaCB0aGlzIGNsYXJpZmllcy4gVGhhbmtzISANCg0KQlIg DQpaYWlmZW5nDQoNCiAgDQoNCg0KRGhhcm1hbmFuZGFuYSBSZWRkeSBQb3RodWxhIDxkaGFybWFu YW5kYW5hLnBvdGh1bGFtQGh1YXdlaS5jb20+IA0KMjAxMi0wMS0zMSAxODo0MyANCg0KDQrH67Tw uLQguPgNCmRoYXJtYW5hbmRhbmEucG90aHVsYW1AaHVhd2VpLmNvbQ0KDQoNCg0KytW8/sjLDQp0 c29AenRldXNhLmNvbSANCrOty80NCmlwc2VjQGlldGYub3JnLCBpcHNlYy1ib3VuY2VzQGlldGYu b3JnLCB6b25nLnphaWZlbmdAenRlLmNvbS5jbiANCtb3zOINClJFOiBbSVBzZWNdIFtJUFNlY106 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgDQpkcmFmdC16b25nLWlwc2VjbWUtaWtldjIt Y3BleHQ0ZmVtdG8tMDAudHh0DQogDQoNCg0KDQoNCg0KDQoNCg0KSGkgVHJpY2NpLCANCiAgDQpU aGFua3MgZm9yIHlvdXIgZXhwbGFuYXRpb24uIEkgZ2V0IHlvdXIgcG9pbnQgd2h5IG5vdGFyaXpl ZCBzaWduYXR1cmUgDQpyZXF1aXJlZCwgYnV0IG15IHF1ZXN0aW9uIGlzIG5vdCBhYm91dCBub3Rh cml6aW5nIGV2ZXJ5IHBhY2tldC4gTGV0IG1lIGFzayANCm15IHF1ZXN0aW9uIGluIGRpZmZlcmVu dCB3YXksIElzIEZBUCBzZW5kcyBub3Rhcml6ZWQgc2lnbmF0dXJlIGluIGV2ZXJ5IA0KSVBTZWMg cGFja2V0IHRvIGNvcmUgbmV0d29yaz8gQXMgSSB1bmRlcnN0YW5kIGZyb20gdGhlIGRyYWZ0IHRo YXQgYmVmb3JlIA0KYWNjZXB0aW5nIGV2ZXJ5IElQU2VjIHBhY2tldCwgY29yZSBuZXR3b3JrIHZh bGlkYXRlIHRoZSBub3Rhcml6ZWQgDQpzaWduYXR1cmUuIFdoZXJlIGlzIHRoaXMgbm90YXJpemVk IHNpZ25hdHVyZSBwbGFjZWQgaW4gZXZlcnkgSVBTZWMgcGFja2V0PyANCg0KVGhhbmtzLCANCkRo YXJtYW5hbmRhbmEgUmVkZHkgUG90aHVsYSANCiAgDQpGcm9tOiB0c29AenRldXNhLmNvbSBbbWFp bHRvOnRzb0B6dGV1c2EuY29tXSANClNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAyNSwgMjAxMiAx OjI2IFBNDQpUbzogZGhhcm1hbmFuZGFuYS5wb3RodWxhbUBodWF3ZWkuY29tDQpDYzogaXBzZWNA aWV0Zi5vcmc7IGlwc2VjLWJvdW5jZXNAaWV0Zi5vcmc7IHpvbmcuemFpZmVuZ0B6dGUuY29tLmNu OyANCnRzb0B6dGV1c2EuY29tDQpTdWJqZWN0OiBSZTogW0lQc2VjXSBbSVBTZWNdOiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIA0KZHJhZnQtem9uZy1pcHNlY21lLWlrZXYgDQogIA0KRGVh ciBEaGFybWFuYW5kYW5hLCANCg0KSSBob3BlIHRoYXQgSSBhZGRyZXNzIHlvdSBjb3JyZWN0bHku ICBJZiBub3QsIHBsZWFzZSBwYXJkb24gbXkgaWdub3JhbmNlLiANCg0KQXMgdGhpcyB3ZWVrIGlz IHNwcmluZyBmZXN0aXZhbCwgWmFpRmVuZyBpcyBub3QgYXZhaWxhYmxlLiAgSGVuY2UsIEkgd291 bGQgDQpsaWtlIHRvIHJlc3BvbmQgdG8geW91IG9uIGJlaGFsZiBvZiBoZXIuICAgDQoNCkNvdWxk IHlvdSBwbGVhc2Uga2luZCBzZWUgbXkgcmVzcG9uc2VzIHRvIHlvdSBpbmxpbmUgYmVsb3cuICBN YW55IHRoYW5rcy4gDQpUcmljY2kgDQoNCg0KNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMt c2VyaWYiJz5EaGFybWFuYW5kYW5hIFJlZGR5IA0KPGRoYXJtYW5hbmRhbmEucG90aHVsYW1AaHVh d2VpLmNvbT4gDQpTZW50IGJ5OiBpcHNlYy1ib3VuY2VzQGlldGYub3JnIA0KMDEvMjQvMjAxMiAw NDowNCBBTSANCiANCg0KDQpQbGVhc2UgcmVzcG9uZCB0bw0KZGhhcm1hbmFuZGFuYS5wb3RodWxh bUBodWF3ZWkuY29tDQoNCiANCg0KDQpUbyANCnpvbmcuemFpZmVuZ0B6dGUuY29tLmNuIA0KY2MN Cmlwc2VjQGlldGYub3JnIA0KU3ViamVjdA0KUmU6IFtJUHNlY10gW0lQU2VjXTogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciANCmRyYWZ0LXpvbmctaXBzZWNtZS1pa2V2Mi1jcGV4dDRmZW10 by0wMC50eHQNCg0KICANCiANCg0KDQoNCg0KDQoNCg0KDQoNCkhpIFphaWZlbmcsIA0KIA0KSSBo YXZlIGZvbGxvd2luZyBxdWVzdGlvbnMgYW5kIGNvbmNlcm5zIGFib3V0IHlvdXIgcHJvcG9zZWQg c29sdXRpb24gIlRoZSANCkZBUCB3aWxsIHRoZW4gc2VuZCB0aGUgRkFQIGluZm9ybWF0aW9uIHRv Z2V0aGVyIHdpdGggdGhlIGNvcnJlc3BvbmRpbmcgDQpTZUdXIG5vdGFyaXplZCBzaWduYXR1cmUg dG8gaXRzIG1vYmlsZSBvcGVyYXRvcidzIGNvcmUgbmV0d29yay4gVGhlIGNvcmUgDQpuZXR3b3Jr IHZlcmlmaWVzIHRoZSBGQVAgaW5mb3JtYXRpb24gYnkgdmFsaWRhdGluZyB0aGUgU2VHVyBub3Rh cml6ZWQgDQpzaWduYXR1cmUgcHJpb3IgdG8gdGhlIGFjY2VwdGFuY2Ugb2YgdGhlIGluZm9ybWF0 aW9uIi4gDQpJcyBldmVyeSBpcCBwYWNrZXQgY2FycmllcyBTZUdXIG5vdGFyaXplZCBzaWduYXR1 cmUgYWZ0ZXIgc2VydmVyIHNlbmRzIA0Kbm90YXJpemVkIHNpZ25hdHVyZSB0byB0aGUgY2xpZW50 PyBpZiBub3QsIHdoYXQncyB0aGUgcG9pbnQgaW4gcmV0dXJuaW5nIA0Kbm90YXJpemVkIHNpZ25h dHVyZSB0byB0aGUgY2xpZW50PyBJIGJlbGlldmUgeWVzLCBpZiBzbywgSXQgd2lsbCBpbmNyZWFz ZSANCnBlcmNlbnRhZ2Ugb2Ygb3ZlcmhlYWQgcGVyIHBhY2tldCBhbmQgbWF5IGltcGFjdCBxdWFs aXR5IG9mIHJlYWwgdGltZSANCnZvaWNlIGFuZCB2aWRlby4gDQoNClRyaWNjaSA+IFlvdSBhc2sg YSB2ZXJ5IGxlZ2l0aW1hdGUgcXVlc3Rpb24uICBNYXkgYmUgb3VyIGRyYWZ0IGlzIG5vdCANCmNs ZWFyIGVub3VnaCB0byBleHBsYWluIHRoZSBtYWluIG1vdGl2YXRpb24gb2YgdGhpcyBkcmFmdCBm b3IgdGFyZ2V0IG9mIA0KdGhlIGF0dGFjay4gICANCg0KVHJpY2NpID4gVGhlIG1haW4gY29uY2Vy biBpcyBub3QgYWJvdXQgdGhlIGF0dGFjayBmb3IgInVuYXV0aG9yaXplZCBGQVAiIA0KdG8gc2Vu ZCBhbnkgZGF0YSB0byB0aGUgbW9iaWxlIGNvcmUgbmV0d29yay4gIFRoZSBtYWluIGNvbmNlcm4g aXMgYWJvdXQgDQp0aGUgYXR0YWNrIG9mIHRoZSAidW5hdXRob3JpemVkIEZBUCIgdG8gc2VuZCB0 aGUgImZhbHNlIiBjb25maWd1cmF0aW9uIA0KaW5mb3JtYXRpb24gKGUuZy4gc3VjaCBhcyBjaGFu Z2luZyB0aGUgRkFQIGZyb20gIkNsb3NlZCIgdG8gYmVjb21lICJPcGVuIiANCjtmYWxzZSIgYWNj ZXNzIGNvbnRyb2wgcmVsYXRlZCBpbmZvcm1hdGlvbiAoZS5nLiBhbGxvd2luZyBhIDNHUFAgVUUg d2hpY2ggDQppcyBzdXBwb3NlZCB0byBiZSBhbGxvd2VkIHRvIGFjY2VzcyB0aGUgRkFQIGFuZCB0 byBoYXZlIHRoZSBhY2Nlc3MgDQpwcml2aWxlYWdlIHRvIHRoZSBGQVAgLSBpLmUuIENTRyBpbmZv IGFsdGVyYXRpb24sIGV0Yy4pLiAgT25jZSB0aGUgRkFQJ3MgDQpjb25maWd1cmF0aW9uIGFuZCBh Y2Nlc3MgY29udHJvbCBtYW5hZ2VtZW50IGFyZSBhdXRoZW50aWNhdGVkIHZpYSB0aGUgDQpzdXBw b3J0IG9mIHRoZSBub3Rhcml6YXRpb24gYnkgdGhlIFNlR1csIHRoZW4sIHRoZSByZXN0IG9mIHRo ZSAzR1BQIFVFcycgDQphY2Nlc3MgdG8gdGhlIEZBUCBjYW4gZm9sbG93IHRoZSBleGlzdGluZyBh Y2Nlc3MgY29udHJvbCBhbmQgVUUtYmFzZWQgDQphdXRoZW50aWNhdGlvbi9hdXRob3JpemF0aW9u IHByb2NlZHVyZXMgYXQgdGhlIFVFIGxldmVsJ3MuICAgDQoNClRyaWNjaSA+IE9mIGNvdXJzZSwg b25jZSB0aGUgVUUgaXMgYXV0aGVudGljYXRlZCBhbmQgdG8gYWxsb3cgYWNjZXNzIHRvIA0KdGhl IEZBUCwgd2hhdGV2ZXIgdGhlIFVFIHNlbmRzIGlzIGJleW9uZCB0aGUgY29udHJvbCBvZiB0aGUg RkFQIGp1c3QgYXMgDQp3aGF0IGlzIGhhcHBlbmVkIHRvZGF5IGZvciBhbnkgbW9iaWxlIGRldmlj ZS4gIElzbid0IGl0PyAgIA0KIA0KaWYgZXZlcnkgaXAgcGFja2V0IGNhcnJpZXMgU2VHVyBub3Rh cml6ZWQgc2lnbmF0dXJlLCBIb3cgYW5kIHdoZXJlIHRoaXMgDQpzaWduYXR1cmUgY2FycmllZCBp bnNpZGUgaXAgcGFja2V0PyBjYXRpb25zIGluc2lkZSBJUHNlYyBwYWNrZXQgDQpwcm9jZXNzaW5n PyBJcyB0aGlzIHByb2Nlc3NpbmcgaGFwcGVucyBvdXRzaWRlIG9mIElQc2VjPyBpcyBpdCBvdXRz aWRlIA0Kc2NvcGUgb2YgdGhpcyBkb2N1bWVudD8gSXQgd291bGQgYmUgZ3JlYXQsIGlmIHNvbWUg b2YgdGhlc2UgYXNwZWN0cyBhcmUgDQphZGRyZXNzZWQgaW4gdGhlIGRyYWZ0LiANCiANClRyaWNj aSA+IFNpbmNlIEkgaGF2ZSBhbHJlYWR5IGV4cGxhaW5lZCB0byB5b3UgdGhhdCwgd2UgYXJlIG5v dCBwcm9wb3NpbmcgDQp0byBub3Rhcml6ZSBldmVyeSBzaW5nbGUgcGFja2V0IHNlbnQgYnkgRkFQ LiAgSGVuY2UsIEkgZG9uJ3QgdGhpbmsgdGhhdCBJIA0KbmVlZCB0byByZXNwb25kIHRvIHlvdXIg cmVzdCBvZiB0aGUgcXVlc3Rpb25zIGFib3ZlLiAgIA0KDQpUcmljY2kgPiBUSEFOSyBZT1UgZm9y IGFza2luZyBhIGdvb2QgcXVlc3Rpb24uICBDaGVlcnMuIA0KDQpUaGFua3MsIA0KIA0KRGhhcm1h bmFuZGFuYSBSZWRkeSBQb3RodWxhLiANCiANCiYgeWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4gIA0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCklQc2VjIG1haWxpbmcgbGlzdA0KSVBzZWNAaWV0Zi5v cmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWMNCg0KICANCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIA0K WlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l ZCBpbiB0aGlzIG1haWwgaXMgDQpzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2Fu aXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgDQpjb25maWRlbnRpYWwuIFJlY2lw aWVudA0KYnNwO2FyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBw ZXJtaXR0ZWQgdG8gZGlzY2xvc2UgDQp0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9u IHRvIG90aGVycy4gDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBp dCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCANCnNvbGVseSBmb3IgdGhlIHVzZSBvZiB0 aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIA0KSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBv cmlnaW5hdG9yIG9mIA0KdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBt ZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgDQppbmRpdmlkdWFsIHNlbmRlci4gDQpUaGlzIG1lc3Nh Z2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFt IA0Kc3lzdGVtLiANCg0K --=_alternative 000E3FAD4825799E_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIERoYXJtYW5hbmRhbmE6PC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGUgSVBTZWMg dHVubmVsIGVzdGFibGlzaG1lbnQgd2lsbA0Kbm90IGJlIGltcGFjdGVkIGJ5IHRoaXMgZHJhZnQs IGlmIHRoZSBpbml0aWF0b3Igc2VuZCBzb21lIHdyb25nIGluZm9ybWF0aW9uDQp0byByZXNwb25k ZXIsIGl0IHdpbGwgYmUgZGV0ZWN0ZWQgYnkgdGhlIHJlc3BvbmRlciwgYW5kIHRoZSByZXNwb25k ZXIgY2FuDQpyZXBsYWNlIHRoZSB3cm9uZyBpbmZvcm1hdGlvbiB3aXRoIGNvcnJlY3Qgb25lcy4g SXQgaXMgbGlrZSBJUCBhZGRyZXNzDQpjb25maWd1cmF0aW9uLCB0aGUgY2xpZW50IG1heSByZXF1 ZXN0IGEgc3BlY2lmaWMgSVAgYWRkcmVzcyBvciBub3QsIHRoZQ0Kc2VydmVyIGNhbiBhbnl3YXkg Y2hvb3NlIGEgZGlmZmVyZW50IG9uZS4gVGhlIHJlc3BvbmRlciAoaS5lLiBTZUdXKSB3aWxsDQpj aG9vc2UgY29ycmVjdCBGQVAgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbiwgYW5kIHNpZ24gdGhp cyBpbmZvcm1hdGlvbiwNCnNvIHRoYXQgdGhlIEZBUCB3aWxsIG5vdCBiZSBhYmxlIHRvIGNoYW5n ZSBpdC4gVGhpcyBGQVAgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbg0Kd2lsbCBsYXRlciBiZSBz ZW50IGJ5IHRoZSBGQVAgdG8gdGhlIGNvcmUgbmV0d29yayAoaW5zaWRlIHRoZSBJUHNlYyB0dW5u ZWwNCmFzIHBheWxvYWQgb2Ygc2lnbmFsbGluZyBiZXR3ZWVuIEZBUCBhbmQgY29yZSBuZXR3b3Jr KSwgYW5kIHRoZSBjb3JlIG5ldHdvcmsNCndpbGwgdmVyaWZ5IHRoZSBpbmZvcm1hdGlvbiBiYXNl ZCBvbiB0aGUgc2lnbmF0dXJlLiA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPkkgd2lzaCB0aGlzIGNsYXJpZmllcy4gVGhhbmtzITwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QlI8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlphaWZlbmc8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0x IGZhY2U9IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lk dGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM1JT48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+PGI+RGhhcm1hbmFuZGFuYSBSZWRkeSBQb3RodWxhDQombHQ7ZGhhcm1h bmFuZGFuYS5wb3RodWxhbUBodWF3ZWkuY29tJmd0OzwvYj4gPC9mb250Pg0KPHA+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTItMDItMDcgMTk6MjY8L2ZvbnQ+DQo8dGFibGUgYm9y ZGVyPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgYmdjb2xvcj13aGl0ZT4NCjxkaXYgYWxpZ249Y2Vu dGVyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7H67TwuLQguPg8YnI+DQpkaGFybWFu YW5kYW5hLnBvdGh1bGFtQGh1YXdlaS5jb208L2ZvbnQ+PC9kaXY+PC90YWJsZT4NCjxicj4NCjx0 ZCB3aWR0aD02NCU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0K PGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9m b250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj56b25nLnphaWZl bmdAenRlLmNvbS5jbjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1y aWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0 ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+aXBzZWNAaWV0Zi5vcmcsIGlwc2VjLWJv dW5jZXNAaWV0Zi5vcmcsDQp0c29AenRldXNhLmNvbTwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0K PHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM 4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UkU6IFJF OiBbSVBzZWNdIFtJUFNlY106IE5ldyBWZXJzaW9uDQpOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXpv bmctaXBzZWNtZS1pa2V2Mi1jcGV4dDRmZW10by0wMC50eHQ8L2ZvbnQ+PC90YWJsZT4NCjxicj4N Cjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJs ZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJDYWxpYnJp Ij5IaSBaYWlmZW5nLDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJD YWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0i Q2FsaWJyaSI+U3VwcG9zZSBhdXRoZW50aWNhdGlvbiBzdWNjZWVkcw0KYnV0IHZlcmlmaWNhdGlv biBmYWlscyBkdWUgdG8gZmFsc2UgaW5mb3JtYXRpb24gc2VudCBieSBGQVAsIHNvIElQU2VjIHR1 bm5lbA0Kd2lsbCBub3QgYmUgdXAsIHNvIElzIHRoZXJlIGFueSByZXNwb25zZSBmcm9tIHJlc3Bv bmRlciB0byBJbml0aWF0b3IgaW5kaWNhdGluZw0KSUtFIG1lc3NhZ2UgcmVjZWl2ZWQgd2l0aCBm YWxzZSBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uIGZyb20gRkFQPyBIb3cNCnRvIGFkZHJlc3Mg dGhpcyBwYXJ0aWN1bGFyIGVycm9yIHNjZW5hcmlvPzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg Y29sb3I9Ymx1ZSBmYWNlPSJDYWxpYnJpIj5SZWdhcmRzLDwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgY29sb3I9Ymx1ZSBmYWNlPSJDYWxpYnJpIj5EaGFybWFuYW5kYW5hIFJlZGR5IFBvdGh1bGEu PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPiZu YnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJp Ij4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGI+RnJvbTo8 L2I+IHpvbmcuemFpZmVuZ0B6dGUuY29tLmNuIFttYWlsdG86em9uZy56YWlmZW5nQHp0ZS5jb20u Y25dDQo8Yj48YnI+DQpTZW50OjwvYj4gVGh1cnNkYXksIEZlYnJ1YXJ5IDAyLCAyMDEyIDE6NTEg UE08Yj48YnI+DQpUbzo8L2I+IGRoYXJtYW5hbmRhbmEucG90aHVsYW1AaHVhd2VpLmNvbTxiPjxi cj4NCkNjOjwvYj4gaXBzZWNAaWV0Zi5vcmc7IGlwc2VjLWJvdW5jZXNAaWV0Zi5vcmc7IHRzb0B6 dGV1c2EuY29tPGI+PGJyPg0KU3ViamVjdDo8L2I+IDwvZm9udD48Zm9udCBzaXplPTI+tPC4tDwv Zm9udD48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj46DQpSRTogW0lQc2VjXSBbSVBTZWNdOiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXpvbmctaXBzZWNtZS1pa2V2Mi1jcGV4 dDRmZW10by0wMC50eHQ8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCkhpIERoYXJtYW5hbmRhbmE6PC9mb250 Pjxmb250IHNpemU9Mz4gPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJy Pg0KVGhlIG5vdGFyaXplZCBzaWduYXR1cmUgd2lsbCBub3QgYmUgc2VudCBvaW4gZXZlcnkgSVBT ZWMgcGFja2V0LiBJdCB3aWxsDQpiZSBzZW50IHRvIGNvcmUgbmV0d29yayB3aGVuIHRoZSBGQVAg cmVnaXN0ZXJzIHRvIHRoZSBjb3JlIG5ldHdvcmsgaW5zaWRlDQp0aGUgc2lnbmFsbGluZyBiZXR3 ZWVuIHRoZSBGQVAgYW5kIGNvcmUgbmV0d29yay4gQWZ0ZXIgaXQgaXMgcmVnaXN0ZXJlZA0KdG8g dGhlIGNvcmUgbmV0d29yaywgdGhlIEZBUCBpcyBhY3RpdmF0ZWQgdG8gYWNjZXB0IGF0dGFjaG1l bnQgb2YgbW9iaWxlDQp0ZXJtaW5hbHMuIEkgd2lzaCB0aGlzIGNsYXJpZmllcy4gVGhhbmtzITwv Zm9udD48Zm9udCBzaXplPTM+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwi Pjxicj4NCkJSPC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJB cmlhbCI+PGJyPg0KWmFpZmVuZzwvZm9udD48Zm9udCBzaXplPTM+PGJyPg0KPC9mb250Pjxmb250 IHNpemU9MSBmYWNlPSJBcmlhbCI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTM+Jm5ic3A7PGJy Pg0KPC9mb250Pg0KPHA+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRk IHdpZHRoPTQ1JT48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPjxiPkRoYXJtYW5hbmRhbmEgUmVk ZHkgUG90aHVsYQ0KJmx0O2RoYXJtYW5hbmRhbmEucG90aHVsYW1AaHVhd2VpLmNvbSZndDs8L2I+ IDwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+MjAxMi0wMS0zMSAxODo0Mzwv Zm9udD48Zm9udCBzaXplPTM+IDwvZm9udD4NCjxwPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0xMDAlIGJnY29sb3I9d2hpdGU+DQo8ZGl2IGFs aWduPWNlbnRlcj48Zm9udCBzaXplPTE+x+u08Li0PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJB cmlhbCI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0xPrj4PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJB cmlhbCI+PGJyPg0KZGhhcm1hbmFuZGFuYS5wb3RodWxhbUBodWF3ZWkuY29tPC9mb250PjwvZGl2 PjwvdGFibGU+DQo8YnI+DQo8dGQgd2lkdGg9NTQlPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD02JT4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQg c2l6ZT0xPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZCB3aWR0aD05MyU+PGZvbnQgc2l6ZT0xIGZh Y2U9IkFyaWFsIj50c29AenRldXNhLmNvbTwvZm9udD48Zm9udCBzaXplPTM+DQo8L2ZvbnQ+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xPrOty808 L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj5pcHNlY0BpZXRmLm9y ZywgaXBzZWMtYm91bmNlc0BpZXRmLm9yZywgem9uZy56YWlmZW5nQHp0ZS5jb20uY248L2ZvbnQ+ PGZvbnQgc2l6ZT0zPg0KPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWdu PXJpZ2h0Pjxmb250IHNpemU9MT7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBm YWNlPSJBcmlhbCI+UkU6IFtJUHNlY10gW0lQU2VjXTogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u DQpmb3IgZHJhZnQtem9uZy1pcHNlY21lLWlrZXYyLWNwZXh0NGZlbXRvLTAwLnR4dDwvZm9udD48 L3RhYmxlPg0KPGJyPjxmb250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+DQo8cD4NCjxicj4NCjx0YWJs ZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9NTAlPg0KPHRkIHdpZHRo PTUwJT48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+PGZvbnQgc2l6ZT0zPjxicj4NCjxicj4N CjwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpI aSBUcmljY2ksPC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0j MWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiZuYnNwOzwv Zm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpUaGFu a3MgZm9yIHlvdXIgZXhwbGFuYXRpb24uIEkgZ2V0IHlvdXIgcG9pbnQgd2h5IG5vdGFyaXplZCBz aWduYXR1cmUgcmVxdWlyZWQsDQpidXQgbXkgcXVlc3Rpb24gaXMgbm90IGFib3V0IG5vdGFyaXpp bmcgZXZlcnkgcGFja2V0LiBMZXQgbWUgYXNrIG15IHF1ZXN0aW9uDQppbiBkaWZmZXJlbnQgd2F5 LCBJcyBGQVAgc2VuZHMgbm90YXJpemVkIHNpZ25hdHVyZSBpbiBldmVyeSBJUFNlYyBwYWNrZXQN CnRvIGNvcmUgbmV0d29yaz8gQXMgSSB1bmRlcnN0YW5kIGZyb20gdGhlIGRyYWZ0IHRoYXQgYmVm b3JlIGFjY2VwdGluZyBldmVyeQ0KSVBTZWMgcGFja2V0LCBjb3JlIG5ldHdvcmsgdmFsaWRhdGUg dGhlIG5vdGFyaXplZCBzaWduYXR1cmUuIFdoZXJlIGlzIHRoaXMNCm5vdGFyaXplZCBzaWduYXR1 cmUgcGxhY2VkIGluIGV2ZXJ5IElQU2VjIHBhY2tldD88L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2Zv bnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPjxicj4NClRoYW5rcyw8L2ZvbnQ+PGZvbnQg c2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+ PGJyPg0KRGhhcm1hbmFuZGFuYSBSZWRkeSBQb3RodWxhPC9mb250Pjxmb250IHNpemU9Mz4gPC9m b250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCiA8L2Zv bnQ+PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj48 Yj48YnI+DQpGcm9tOjwvYj4gdHNvQHp0ZXVzYS5jb20gW21haWx0bzp0c29AenRldXNhLmNvbV0g PGI+PGJyPg0KU2VudDo8L2I+IFdlZG5lc2RheSwgSmFudWFyeSAyNSwgMjAxMiAxOjI2IFBNPGI+ PGJyPg0KVG86PC9iPiBkaGFybWFuYW5kYW5hLnBvdGh1bGFtQGh1YXdlaS5jb208Yj48YnI+DQpD Yzo8L2I+IGlwc2VjQGlldGYub3JnOyBpcHNlYy1ib3VuY2VzQGlldGYub3JnOyB6b25nLnphaWZl bmdAenRlLmNvbS5jbjsNCnRzb0B6dGV1c2EuY29tPGI+PGJyPg0KU3ViamVjdDo8L2I+IFJlOiBb SVBzZWNdIFtJUFNlY106IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtem9uZy1p cHNlY21lLWlrZXYNCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48 YnI+DQogPC9mb250Pjxmb250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9y PWJsdWUgZmFjZT0iQXJpYWwiPjxicj4NCkRlYXIgRGhhcm1hbmFuZGFuYSwgPGJyPg0KPGJyPg0K SSBob3BlIHRoYXQgSSBhZGRyZXNzIHlvdSBjb3JyZWN0bHkuICZuYnNwO0lmIG5vdCwgcGxlYXNl IHBhcmRvbiBteSBpZ25vcmFuY2UuDQo8YnI+DQo8YnI+DQpBcyB0aGlzIHdlZWsgaXMgc3ByaW5n IGZlc3RpdmFsLCBaYWlGZW5nIGlzIG5vdCBhdmFpbGFibGUuICZuYnNwO0hlbmNlLA0KSSB3b3Vs ZCBsaWtlIHRvIHJlc3BvbmQgdG8geW91IG9uIGJlaGFsZiBvZiBoZXIuICZuYnNwOzwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBzaXplPTMg Y29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PGJyPg0KPGJyPg0KQ291bGQgeW91IHBsZWFzZSBraW5k IHNlZSBteSByZXNwb25zZXMgdG8geW91IGlubGluZSBiZWxvdy4gJm5ic3A7TWFueQ0KdGhhbmtz LjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxmb250 IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj48YnI+DQpUcmljY2kgPC9mb250Pjxmb250 IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxicj4NCjwvZm9udD4NCjxwPg0KPHRhYmxl IHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD01MyU+PGZvbnQgc2l6ZT0z IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGI+NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsnJmd0O0RoYXJtYW5hbmRhbmENClJlZGR5ICZsdDtk aGFybWFuYW5kYW5hLnBvdGh1bGFtQGh1YXdlaS5jb20mZ3Q7PC9iPjwvZm9udD48Zm9udCBzaXpl PTEgZmFjZT0iQXJpYWwiPg0KPGJyPg0KU2VudCBieTogaXBzZWMtYm91bmNlc0BpZXRmLm9yZzwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD4NCjxwPjxm b250IHNpemU9MSBmYWNlPSJBcmlhbCI+MDEvMjQvMjAxMiAwNDowNCBBTTwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9Mz4m bmJzcDs8L2ZvbnQ+DQo8cD4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQgd2lkdGg9MTAwJSBiZ2NvbG9yPXdoaXRlPg0KPGRpdiBhbGlnbj1jZW50ZXI+PGZv bnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj5QbGVhc2UgcmVzcG9uZCB0bzxicj4NCmRoYXJtYW5hbmRh bmEucG90aHVsYW1AaHVhd2VpLmNvbTwvZm9udD48L2Rpdj48L3RhYmxlPg0KPGJyPg0KPHRkIHdp ZHRoPTQ2JT48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pg0KPHA+DQo8YnI+DQo8dGFibGUgd2lk dGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTYlPjxmb250IHNpemU9MSBmYWNl PSJBcmlhbCI+VG88L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+DQo8dGQgd2lkdGg9OTMlPjxm b250IHNpemU9MSBmYWNlPSJBcmlhbCI+em9uZy56YWlmZW5nQHp0ZS5jb20uY248L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+DQo8dHIgdmFsaWduPXRv cD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj5jYzwv Zm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPmlwc2VjQGlldGYub3Jn PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pg0KPHRy IHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJB cmlhbCI+U3ViamVjdDwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj5SZTogW0lQc2VjXSBbSVBTZWNdOiBOZXcgVmVyc2lvbg0KTm90aWZpY2F0aW9u IGZvciBkcmFmdC16b25nLWlwc2VjbWUtaWtldjItY3BleHQ0ZmVtdG8tMDAudHh0PC9mb250Pjwv dGFibGU+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGJyPg0KIDwv Zm9udD48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0zPiZuYnNwOzwv Zm9udD4NCjxwPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0 ZCB3aWR0aD01MCU+DQo8dGQgd2lkdGg9NTAlPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxwPjxm b250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxicj4NCjxicj4NCjwvZm9udD48Zm9u dCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPjxicj4NCjxicj4NCkhpIFphaWZlbmcsPC9mb250 Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8YnI+DQogPC9mb250Pjxmb250 IHNpemU9MyBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KSSBoYXZlIGZvbGxvd2luZyBxdWVzdGlv bnMgYW5kIGNvbmNlcm5zIGFib3V0IHlvdXIgcHJvcG9zZWQgc29sdXRpb24gJnF1b3Q7VGhlDQpG QVAgd2lsbCB0aGVuIHNlbmQgdGhlIEZBUCBpbmZvcm1hdGlvbiB0b2dldGhlciB3aXRoIHRoZSBj b3JyZXNwb25kaW5nDQpTZUdXIG5vdGFyaXplZCBzaWduYXR1cmUgdG8gaXRzIG1vYmlsZSBvcGVy YXRvcidzIGNvcmUgbmV0d29yay4gVGhlIGNvcmUNCm5ldHdvcmsgdmVyaWZpZXMgdGhlIEZBUCBp bmZvcm1hdGlvbiBieSB2YWxpZGF0aW5nIHRoZSBTZUdXIG5vdGFyaXplZCBzaWduYXR1cmUNCnBy aW9yIHRvIHRoZSBhY2NlcHRhbmNlIG9mIHRoZSBpbmZvcm1hdGlvbiZxdW90Oy48L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8YnI+DQpJcyBldmVyeSBpcCBwYWNr ZXQgY2FycmllcyBTZUdXIG5vdGFyaXplZCBzaWduYXR1cmUgYWZ0ZXIgc2VydmVyIHNlbmRzDQpu b3Rhcml6ZWQgc2lnbmF0dXJlIHRvIHRoZSBjbGllbnQ/IGlmIG5vdCwgd2hhdCdzIHRoZSBwb2lu dCBpbiByZXR1cm5pbmcNCm5vdGFyaXplZCBzaWduYXR1cmUgdG8gdGhlIGNsaWVudD8gSSBiZWxp ZXZlIHllcywgaWYgc28sIEl0IHdpbGwgaW5jcmVhc2UNCnBlcmNlbnRhZ2Ugb2Ygb3ZlcmhlYWQg cGVyIHBhY2tldCBhbmQgbWF5IGltcGFjdCBxdWFsaXR5IG9mIHJlYWwgdGltZSB2b2ljZQ0KYW5k IHZpZGVvLiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0iTVYgQm9saSI+PGJy Pg0KPGJyPg0KVHJpY2NpICZndDsgWW91IGFzayBhIHZlcnkgbGVnaXRpbWF0ZSBxdWVzdGlvbi4g Jm5ic3A7TWF5IGJlIG91ciBkcmFmdA0KaXMgbm90IGNsZWFyIGVub3VnaCB0byBleHBsYWluIHRo ZSBtYWluIG1vdGl2YXRpb24gb2YgdGhpcyBkcmFmdCBmb3IgdGFyZ2V0DQpvZiB0aGUgYXR0YWNr LiAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDwvZm9u dD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJNViBCb2xpIj48YnI+DQo8YnI+DQpUcmlj Y2kgJmd0OyBUaGUgbWFpbiBjb25jZXJuIGlzIG5vdCBhYm91dCB0aGUgYXR0YWNrIGZvciAmcXVv dDt1bmF1dGhvcml6ZWQNCkZBUCZxdW90OyB0byBzZW5kIGFueSBkYXRhIHRvIHRoZSBtb2JpbGUg Y29yZSBuZXR3b3JrLiAmbmJzcDtUaGUgbWFpbiBjb25jZXJuDQppcyBhYm91dCB0aGUgYXR0YWNr IG9mIHRoZSAmcXVvdDt1bmF1dGhvcml6ZWQgRkFQJnF1b3Q7IHRvIHNlbmQgdGhlICZxdW90O2Zh bHNlJnF1b3Q7DQpjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uIChlLmcuIHN1Y2ggYXMgY2hhbmdp bmcgdGhlIEZBUCBmcm9tICZxdW90O0Nsb3NlZCZxdW90Ow0KdG8gYmVjb21lICZxdW90O09wZW4m cXVvdDsgO2ZhbHNlJnF1b3Q7IGFjY2VzcyBjb250cm9sIHJlbGF0ZWQgaW5mb3JtYXRpb24NCihl LmcuIGFsbG93aW5nIGEgM0dQUCBVRSB3aGljaCBpcyBzdXBwb3NlZCB0byBiZSBhbGxvd2VkIHRv IGFjY2VzcyB0aGUNCkZBUCBhbmQgdG8gaGF2ZSB0aGUgYWNjZXNzIHByaXZpbGVhZ2UgdG8gdGhl IEZBUCAtIGkuZS4gQ1NHIGluZm8gYWx0ZXJhdGlvbiwNCmV0Yy4pLiAmbmJzcDtPbmNlIHRoZSBG QVAncyBjb25maWd1cmF0aW9uIGFuZCBhY2Nlc3MgY29udHJvbCBtYW5hZ2VtZW50DQphcmUgYXV0 aGVudGljYXRlZCB2aWEgdGhlIHN1cHBvcnQgb2YgdGhlIG5vdGFyaXphdGlvbiBieSB0aGUgU2VH VywgdGhlbiwNCnRoZSByZXN0IG9mIHRoZSAzR1BQIFVFcycgYWNjZXNzIHRvIHRoZSBGQVAgY2Fu IGZvbGxvdyB0aGUgZXhpc3RpbmcgYWNjZXNzDQpjb250cm9sIGFuZCBVRS1iYXNlZCBhdXRoZW50 aWNhdGlvbi9hdXRob3JpemF0aW9uIHByb2NlZHVyZXMgYXQgdGhlIFVFDQpsZXZlbCdzLiAmbmJz cDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDwvZm9udD48Zm9u dCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJNViBCb2xpIj48YnI+DQo8YnI+DQpUcmljY2kgJmd0 OyBPZiBjb3Vyc2UsIG9uY2UgdGhlIFVFIGlzIGF1dGhlbnRpY2F0ZWQgYW5kIHRvIGFsbG93IGFj Y2Vzcw0KdG8gdGhlIEZBUCwgd2hhdGV2ZXIgdGhlIFVFIHNlbmRzIGlzIGJleW9uZCB0aGUgY29u dHJvbCBvZiB0aGUgRkFQIGp1c3QNCmFzIHdoYXQgaXMgaGFwcGVuZWQgdG9kYXkgZm9yIGFueSBt b2JpbGUgZGV2aWNlLiAmbmJzcDtJc24ndCBpdD8gJm5ic3A7PC9mb250Pjxmb250IHNpemU9MyBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0i Q291cmllciBOZXciPjxicj4NCmlmIGV2ZXJ5IGlwIHBhY2tldCBjYXJyaWVzIFNlR1cgbm90YXJp emVkIHNpZ25hdHVyZSwgSG93IGFuZCB3aGVyZSB0aGlzDQpzaWduYXR1cmUgY2FycmllZCBpbnNp ZGUgaXAgcGFja2V0PyBjYXRpb25zIGluc2lkZSBJUHNlYyBwYWNrZXQgcHJvY2Vzc2luZz8NCklz IHRoaXMgcHJvY2Vzc2luZyBoYXBwZW5zIG91dHNpZGUgb2YgSVBzZWM/IGlzIGl0IG91dHNpZGUg c2NvcGUgb2YgdGhpcw0KZG9jdW1lbnQ/IEl0IHdvdWxkIGJlIGdyZWF0LCBpZiBzb21lIG9mIHRo ZXNlIGFzcGVjdHMgYXJlIGFkZHJlc3NlZCBpbg0KdGhlIGRyYWZ0LjwvZm9udD48Zm9udCBzaXpl PTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTMgY29s b3I9Ymx1ZSBmYWNlPSJNViBCb2xpIj48YnI+DQpUcmljY2kgJmd0OyBTaW5jZSBJIGhhdmUgYWxy ZWFkeSBleHBsYWluZWQgdG8geW91IHRoYXQsIHdlIGFyZSBub3QgcHJvcG9zaW5nDQp0byBub3Rh cml6ZSBldmVyeSBzaW5nbGUgcGFja2V0IHNlbnQgYnkgRkFQLiAmbmJzcDtIZW5jZSwgSSBkb24n dCB0aGluaw0KdGhhdCBJIG5lZWQgdG8gcmVzcG9uZCB0byB5b3VyIHJlc3Qgb2YgdGhlIHF1ZXN0 aW9ucyBhYm92ZS4gJm5ic3A7PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPg0KPC9mb250Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9Ik1WIEJvbGkiPjxicj4N Cjxicj4NClRyaWNjaSAmZ3Q7IFRIQU5LIFlPVSBmb3IgYXNraW5nIGEgZ29vZCBxdWVzdGlvbi4g Jm5ic3A7Q2hlZXJzLiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+ DQo8YnI+DQpUaGFua3MsPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PiA8YnI+DQogPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KRGhh cm1hbmFuZGFuYSBSZWRkeSBQb3RodWxhLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj4NCjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3 Ij48YnI+DQomYW1wOyB5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OycmZ3Q7DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJD b3VyaWVyIE5ldyI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQpJUHNlYyBtYWlsaW5nIGxpc3Q8YnI+DQpJUHNlY0BpZXRmLm9yZzwvZm9u dD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dT48YnI+DQo8L3U+PC9mb250PjxhIGhyZWY9aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHNlYz48Zm9udCBzaXplPTIgY29s b3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIE5ldyI+PHU+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pcHNlYzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9Mz48YnI+DQo8L2ZvbnQ+ PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQogPC9mb250Pjxmb250IHNpemU9 Mz4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvZm9u dD48Zm9udCBzaXplPTM+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48 YnI+DQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29u dGFpbmVkIGluIHRoaXMgbWFpbA0KaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBv cmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uDQppcyBjb25maWRlbnRpYWwuIFJl Y2lwaWVudDxicj4NCmJzcDthcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFy ZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlDQp0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5p Y2F0aW9uIHRvIG90aGVycy48L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0y IGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNt aXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZA0Kc29sZWx5IGZvciB0 aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJl c3NlZC4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5v dGlmeSB0aGUgb3JpZ2luYXRvciBvZg0KdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQg aW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbA0Kc2VuZGVyLjwvZm9u dD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxi cj4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5 IFpURSBBbnRpLVNwYW0gc3lzdGVtLjwvZm9udD48Zm9udCBzaXplPTM+DQo8L2ZvbnQ+DQo8cD4N Cg== --=_alternative 000E3FAD4825799E_=-- From zong.zaifeng@zte.com.cn Tue Feb 7 19:37:44 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18CA521F8603; Tue, 7 Feb 2012 19:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -91.969 X-Spam-Level: X-Spam-Status: No, score=-91.969 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJmYM6kl005v; Tue, 7 Feb 2012 19:37:43 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 02E9121F8602; Tue, 7 Feb 2012 19:37:41 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 56690433787882; Wed, 8 Feb 2012 11:10:40 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 91379.1725263410; Wed, 8 Feb 2012 11:37:20 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q183bL5Q013268; Wed, 8 Feb 2012 11:37:21 +0800 (GMT-8) (envelope-from zong.zaifeng@zte.com.cn) In-Reply-To: <002a01cce592$7a7d4e00$6f77ea00$%pothulam@huawei.com> To: dharmanandana.pothulam@huawei.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zong.zaifeng@zte.com.cn Date: Wed, 8 Feb 2012 11:34:31 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-02-08 11:37:22, Serialize complete at 2012-02-08 11:37:22 Content-Type: multipart/alternative; boundary="=_alternative 0013E6314825799E_=" X-MAIL: mse02.zte.com.cn q183bL5Q013268 Cc: ipsec@ietf.org, ipsec-bounces@ietf.org, tso@zteusa.com Subject: [IPsec] =?gb2312?b?tPC4tDogUkU6IFJFOiAgW0lQU2VjXTogTmV3IFZlcnNp?= =?gb2312?b?b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC16b25nLWlwc2VjbWUtaWtldjIt?= =?gb2312?b?Y3BleHQ0ZmVtdG8tMDAudHh0?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 03:37:44 -0000 This is a multipart message in MIME format. --=_alternative 0013E6314825799E_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 IERoYXJtYW5hbmRhbmEgUmVkZHkgUG90aHVsYSA8ZGhhcm1hbmFuZGFuYS5wb3RodWxhbUBodWF3 ZWkuY29tPiB3cm90ZSBvbiANCjIwMTItMDItMDcgMjA6MTc6MzU6DQoNCj4gSGkgWmFpZmVuZywN Cj4gDQo+IEFib3V0IGVycm9yIGNvbmRpdGlvbiwgSXMgdGhlcmUgYW55IHBsYW4gdG8gYWRkIG5l dyBlcnJvciBtZXNzYWdlIA0KPiB0eXBlcyB0byBOb3RpZnkgcGF5bG9hZCB0byBoYW5kbGUgdmVy aWZpY2F0aW9uIGZhaWwgc2NlbmFyaW9zPyBJIA0KPiBmZWVsIGl0IHdvdWxkIGFwcHJvcHJpYXRl IHRvIGluZm9ybSBGQVAsIHNvIHRoaXMgaGVscHMgRkFQIHRvIA0KPiBjb3JyZWN0IGlmIG1pc2Nv bmZpZ3VyZWQuDQo+IA0KPiBJIGhhdmUgb25lIG1vcmUgcXVlc3Rpb24gYWJvdXQgdGhlIHByb3Bv c2VkIHNvbHV0aW9uLiBDYW6hr3Qgd2UgDQo+IGhhbmRsZSB2ZXJpZnlpbmcgRkFQIGNvbmZpZ3Vy YXRpb24gaW5mb3JtYXRpb24gaW5zaWRlIEZlbXRvIEdhdGV3YXk/DQo+IEZlbXRvIEdhdGV3YXkg Y2FuIGluZm9ybSBzZWN1cml0eSBnYXRld2F5IHRvIGJyaW5nIGRvd24gdGhlIHR1bm5lbCwgDQo+ IGlmIHZlcmlmaWNhdGlvbiBmYWlscy4gQW55d2F5IGZhbHNlIGluZm9ybWF0aW9uIHN1Ym1pc3Np b24gdmVyeSANCj4gdW5saWtlbHkgc2NlbmFyaW8sIHNvIHdoeSB3ZSBuZWVkIHRvIG1ha2UgdGhp cyBjb25maWcgcGF5bG9hZCANCj4gZXhjaGFuZ2UgYXMgcGFydCBvZiByZWd1bGFyIElLRSBuZWdv dGlhdGlvbj8gSSBmZWVsIGFkZGl0aW9uIG9mIG1vcmUNCj4gY29uZmlnIHBheWxvYWRzIG1pZ2h0 IGltcGFjdCB0dW5uZWwgc2V0dXAgcmF0ZS4NCj4gDQpUaGUgcmVhc29uIHdoeSB3ZSBoYXZlIHRo aXMgZHJhZnQgaXMgdG8gZW5hYmxlIGZlbXRvIGdhdGV3YXkgKG9yIG90aGVyIA0KY29yZSBuZXR3 b3JrIGVudGl0aWVzIGluIGNlcnRhaW4gc2NlbmFyaW9zKSB0byB2ZXJpZnkgdGhlIEZBUCANCmNv bmZpZ3VyYXRpb24gaW5mb3JtYXRpb24uIEJ1dCB0aGUgcHJvYmxlbSBpcyB0aGUgZmVtdG8gZ2F0 ZXdheSBkb2VzIG5vdCANCmhhdmUgdGhlIGNhcGFiaWxpdHkgdG8gZG8gc28gYWNjb3JkaW5nIHRv IGZlbXRvIGFyY2hpdGVjdHVyZSwgYmVjYXVzZSB0aGUgDQpGQVAgaXMgbm90IGF1dGhlbnRpY2F0 ZWQgYnkgZmVtdG8gZ2F0ZXdheSBhbmQgdGhlcmUgaXMgbm8gaW50ZXJmYWNlIA0KYmV0d2VlbiBm ZW10byBnYXRld2F5IGFuZCB0aGUgZW50aXRpZXMgd2hpY2ggYXJlIHJlc3BvbnNpYmxlIGZvciB0 aGUgDQphdXRoZW50aWNhdGlvbiBvZiB0aGUgRkFQIChpLmUuIHRoZSBTZUdXKS4gT2YgY291cnNl LCBpZiB0aGUgZmVtdG8gDQphcmNoaXRlY3R1cmUgY291bGQgYmUgY2hhbmdlZCwgZS5nLiBhZGRp bmcgYW4gaW50ZXJmYWNlIGJldHdlZW4gU2VHVyBhbmQgDQpjb3JlIG5ldHdvcmssIGNvdWxkIHNv bHZlIHRoZSBwcm9ibGVtIHRvbywgYnV0IHRoYXQgaGFzIHRoZSBhcmNoaXRlY3R1cmFsIA0KaW1w YWN0cywgaGVuY2UsIEkgdGhpbmsgdGhlIGNoYW5nZSBpcyBodWdlLiANCg0KDQo+IFJlZ2FyZHMs DQo+IERoYXJtYW5hbmRhbmEgUmVkZHkgUG90aHVsYQ0KPiANCj4gRnJvbTogem9uZy56YWlmZW5n QHp0ZS5jb20uY24gW21haWx0bzp6b25nLnphaWZlbmdAenRlLmNvbS5jbl0gDQo+IFNlbnQ6IFRo dXJzZGF5LCBGZWJydWFyeSAwMiwgMjAxMiAxOjUxIFBNDQo+IFRvOiBkaGFybWFuYW5kYW5hLnBv dGh1bGFtQGh1YXdlaS5jb20NCj4gQ2M6IGlwc2VjQGlldGYub3JnOyBpcHNlYy1ib3VuY2VzQGll dGYub3JnOyB0c29AenRldXNhLmNvbQ0KPiBTdWJqZWN0OiC08Li0OiBSRTogW0lQc2VjXSBbSVBT ZWNdOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIA0KPiBkcmFmdC16b25nLWlwc2VjbWUt aWtldjItY3BleHQ0ZmVtdG8tMDAudHh0DQo+IA0KPiANCj4gSGkgRGhhcm1hbmFuZGFuYTogDQo+ IA0KPiBUaGUgbm90YXJpemVkIHNpZ25hdHVyZSB3aWxsIG5vdCBiZSBzZW50IG9pbiBldmVyeSBJ UFNlYyBwYWNrZXQuIEl0IA0KPiB3aWxsIGJlIHNlbnQgdG8gY29yZSBuZXR3b3JrIHdoZW4gdGhl IEZBUCByZWdpc3RlcnMgdG8gdGhlIGNvcmUgDQo+IG5ldHdvcmsgaW5zaWRlIHRoZSBzaWduYWxs aW5nIGJldHdlZW4gdGhlIEZBUCBhbmQgY29yZSBuZXR3b3JrLiANCj4gQWZ0ZXIgaXQgaXMgcmVn aXN0ZXJlZCB0byB0aGUgY29yZSBuZXR3b3JrLCB0aGUgRkFQIGlzIGFjdGl2YXRlZCB0byANCj4g YWNjZXB0IGF0dGFjaG1lbnQgb2YgbW9iaWxlIHRlcm1pbmFscy4gSSB3aXNoIHRoaXMgY2xhcmlm aWVzLiBUaGFua3MhIA0KPiANCj4gQlIgDQo+IFphaWZlbmcNCj4gDQo+IA0KDQo+IA0KPiBEaGFy bWFuYW5kYW5hIFJlZGR5IFBvdGh1bGEgPGRoYXJtYW5hbmRhbmEucG90aHVsYW1AaHVhd2VpLmNv bT4gDQo+IDIwMTItMDEtMzEgMTg6NDMgDQo+IA0KPiDH67TwuLQguPgNCj4gZGhhcm1hbmFuZGFu YS5wb3RodWxhbUBodWF3ZWkuY29tDQo+IA0KPiDK1bz+yMsNCj4gDQo+IHRzb0B6dGV1c2EuY29t IA0KPiANCj4gs63LzQ0KPiANCj4gaXBzZWNAaWV0Zi5vcmcsIGlwc2VjLWJvdW5jZXNAaWV0Zi5v cmcsIHpvbmcuemFpZmVuZ0B6dGUuY29tLmNuIA0KPiANCj4g1vfM4g0KPiANCj4gUkU6IFtJUHNl Y10gW0lQU2VjXTogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC16b25nLQ0KPiBp cHNlY21lLWlrZXYyLWNwZXh0NGZlbXRvLTAwLnR4dA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0K PiBIaSBUcmljY2ksIA0KPiANCj4gVGhhbmtzIGZvciB5b3VyIGV4cGxhbmF0aW9uLiBJIGdldCB5 b3VyIHBvaW50IHdoeSBub3Rhcml6ZWQgDQo+IHNpZ25hdHVyZSByZXF1aXJlZCwgYnV0IG15IHF1 ZXN0aW9uIGlzIG5vdCBhYm91dCBub3Rhcml6aW5nIGV2ZXJ5IA0KPiBwYWNrZXQuIExldCBtZSBh c2sgbXkgcXVlc3Rpb24gaW4gZGlmZmVyZW50IHdheSwgSXMgRkFQIHNlbmRzIA0KPiBub3Rhcml6 ZWQgc2lnbmF0dXJlIGluIGV2ZXJ5IElQU2VjIHBhY2tldCB0byBjb3JlIG5ldHdvcms/IEFzIEkg DQo+IHVuZGVyc3RhbmQgZnJvbSB0aGUgZHJhZnQgdGhhdCBiZWZvcmUgYWNjZXB0aW5nIGV2ZXJ5 IElQU2VjIHBhY2tldCwgDQo+IGNvcmUgbmV0d29yayB2YWxpZGF0ZSB0aGUgbm90YXJpemVkIHNp Z25hdHVyZS4gV2hlcmUgaXMgdGhpcyANCj4gbm90YXJpemVkIHNpZ25hdHVyZSBwbGFjZWQgaW4g ZXZlcnkgSVBTZWMgcGFja2V0PyANCj4gVGhhbmtzLCANCj4gRGhhcm1hbmFuZGFuYSBSZWRkeSBQ b3RodWxhIA0KPiANCj4gRnJvbTogdHNvQHp0ZXVzYS5jb20gW21haWx0bzp0c29AenRldXNhLmNv bV0gDQo+IFNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAyNSwgMjAxMiAxOjI2IFBNDQo+IFRvOiBk aGFybWFuYW5kYW5hLnBvdGh1bGFtQGh1YXdlaS5jb20NCj4gQ2M6IGlwc2VjQGlldGYub3JnOyBp cHNlYy1ib3VuY2VzQGlldGYub3JnOyB6b25nLnphaWZlbmdAenRlLmNvbS5jbjsNCj4gdHNvQHp0 ZXVzYS5jb20NCj4gU3ViamVjdDogUmU6IFtJUHNlY10gW0lQU2VjXTogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC0NCj4gem9uZy1pcHNlY21lLWlrZXYgDQo+IA0KPiBEZWFyIERo YXJtYW5hbmRhbmEsIA0KPiANCj4gSSBob3BlIHRoYXQgSSBhZGRyZXNzIHlvdSBjb3JyZWN0bHku ICBJZiBub3QsIHBsZWFzZSBwYXJkb24gbXkgDQppZ25vcmFuY2UuIA0KPiANCj4gQXMgdGhpcyB3 ZWVrIGlzIHNwcmluZyBmZXN0aXZhbCwgWmFpRmVuZyBpcyBub3QgYXZhaWxhYmxlLiAgSGVuY2Us IEkNCj4gd291bGQgbGlrZSB0byByZXNwb25kIHRvIHlvdSBvbiBiZWhhbGYgb2YgaGVyLiANCj4g DQo+IENvdWxkIHlvdSBwbGVhc2Uga2luZCBzZWUgbXkgcmVzcG9uc2VzIHRvIHlvdSBpbmxpbmUg YmVsb3cuICBNYW55IA0KdGhhbmtzLiANCj4gVHJpY2NpIA0KDQo+IA0KPiA1cHQ7Zm9udC1mYW1p bHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPkRoYXJtYW5hbmRhbmEgUmVkZHkgDQo+IDxkaGFybWFu YW5kYW5hLnBvdGh1bGFtQGh1YXdlaS5jb20+IA0KPiBTZW50IGJ5OiBpcHNlYy1ib3VuY2VzQGll dGYub3JnIA0KPiAwMS8yNC8yMDEyIDA0OjA0IEFNIA0KPiANCj4gDQo+IFBsZWFzZSByZXNwb25k IHRvDQo+IGRoYXJtYW5hbmRhbmEucG90aHVsYW1AaHVhd2VpLmNvbQ0KPiANCj4gDQo+IA0KPiBU byANCj4gDQo+IHpvbmcuemFpZmVuZ0B6dGUuY29tLmNuIA0KPiANCj4gY2MNCj4gDQo+IGlwc2Vj QGlldGYub3JnIA0KPiANCj4gU3ViamVjdA0KPiANCj4gUmU6IFtJUHNlY10gW0lQU2VjXTogTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC16b25nLQ0KPiBpcHNlY21lLWlrZXYyLWNw ZXh0NGZlbXRvLTAwLnR4dA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiBI aSBaYWlmZW5nLCANCj4gDQo+IEkgaGF2ZSBmb2xsb3dpbmcgcXVlc3Rpb25zIGFuZCBjb25jZXJu cyBhYm91dCB5b3VyIHByb3Bvc2VkIHNvbHV0aW9uDQo+ICJUaGUgRkFQIHdpbGwgdGhlbiBzZW5k IHRoZSBGQVAgaW5mb3JtYXRpb24gdG9nZXRoZXIgd2l0aCB0aGUgDQo+IGNvcnJlc3BvbmRpbmcg U2VHVyBub3Rhcml6ZWQgc2lnbmF0dXJlIHRvIGl0cyBtb2JpbGUgb3BlcmF0b3IncyBjb3JlDQo+ IG5ldHdvcmsuIFRoZSBjb3JlIG5ldHdvcmsgdmVyaWZpZXMgdGhlIEZBUCBpbmZvcm1hdGlvbiBi eSB2YWxpZGF0aW5nDQo+IHRoZSBTZUdXIG5vdGFyaXplZCBzaWduYXR1cmUgcHJpb3IgdG8gdGhl IGFjY2VwdGFuY2Ugb2YgdGhlIA0KaW5mb3JtYXRpb24iLiANCj4gSXMgZXZlcnkgaXAgcGFja2V0 IGNhcnJpZXMgU2VHVyBub3Rhcml6ZWQgc2lnbmF0dXJlIGFmdGVyIHNlcnZlciANCj4gc2VuZHMg bm90YXJpemVkIHNpZ25hdHVyZSB0byB0aGUgY2xpZW50PyBpZiBub3QsIHdoYXQncyB0aGUgcG9p bnQgaW4NCj4gcmV0dXJuaW5nIG5vdGFyaXplZCBzaWduYXR1cmUgdG8gdGhlIGNsaWVudD8gSSBi ZWxpZXZlIHllcywgaWYgc28sIA0KPiBJdCB3aWxsIGluY3JlYXNlIHBlcmNlbnRhZ2Ugb2Ygb3Zl cmhlYWQgcGVyIHBhY2tldCBhbmQgbWF5IGltcGFjdCANCj4gcXVhbGl0eSBvZiByZWFsIHRpbWUg dm9pY2UgYW5kIHZpZGVvLiANCj4gDQo+IFRyaWNjaSA+IFlvdSBhc2sgYSB2ZXJ5IGxlZ2l0aW1h dGUgcXVlc3Rpb24uICBNYXkgYmUgb3VyIGRyYWZ0IGlzIA0KPiBub3QgY2xlYXIgZW5vdWdoIHRv IGV4cGxhaW4gdGhlIG1haW4gbW90aXZhdGlvbiBvZiB0aGlzIGRyYWZ0IGZvciANCj4gdGFyZ2V0 IG9mIHRoZSBhdHRhY2suIA0KPiANCj4gVHJpY2NpID4gVGhlIG1haW4gY29uY2VybiBpcyBub3Qg YWJvdXQgdGhlIGF0dGFjayBmb3IgInVuYXV0aG9yaXplZCANCj4gRkFQIiB0byBzZW5kIGFueSBk YXRhIHRvIHRoZSBtb2JpbGUgY29yZSBuZXR3b3JrLiAgVGhlIG1haW4gY29uY2VybiANCj4gaXMg YWJvdXQgdGhlIGF0dGFjayBvZiB0aGUgInVuYXV0aG9yaXplZCBGQVAiIHRvIHNlbmQgdGhlICJm YWxzZSIgDQo+IGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24gKGUuZy4gc3VjaCBhcyBjaGFuZ2lu ZyB0aGUgRkFQIGZyb20gDQo+ICJDbG9zZWQiIHRvIGJlY29tZSAiT3BlbiIgO2ZhbHNlIiBhY2Nl c3MgY29udHJvbCByZWxhdGVkIGluZm9ybWF0aW9uDQo+IChlLmcuIGFsbG93aW5nIGEgM0dQUCBV RSB3aGljaCBpcyBzdXBwb3NlZCB0byBiZSBhbGxvd2VkIHRvIGFjY2VzcyANCj4gdGhlIEZBUCBh bmQgdG8gaGF2ZSB0aGUgYWNjZXNzIHByaXZpbGVhZ2UgdG8gdGhlIEZBUCAtIGkuZS4gQ1NHIGlu Zm8NCj4gYWx0ZXJhdGlvbiwgZXRjLikuICBPbmNlIHRoZSBGQVAncyBjb25maWd1cmF0aW9uIGFu ZCBhY2Nlc3MgY29udHJvbCANCj4gbWFuYWdlbWVudCBhcmUgYXV0aGVudGljYXRlZCB2aWEgdGhl IHN1cHBvcnQgb2YgdGhlIG5vdGFyaXphdGlvbiBieSANCj4gdGhlIFNlR1csIHRoZW4sIHRoZSBy ZXN0IG9mIHRoZSAzR1BQIFVFcycgYWNjZXNzIHRvIHRoZSBGQVAgY2FuIA0KPiBmb2xsb3cgdGhl IGV4aXN0aW5nIGFjY2VzcyBjb250cm9sIGFuZCBVRS1iYXNlZCANCj4gYXV0aGVudGljYXRpb24v YXV0aG9yaXphdGlvbiBwcm9jZWR1cmVzIGF0IHRoZSBVRSBsZXZlbCdzLiANCj4gDQo+IFRyaWNj aSA+IE9mIGNvdXJzZSwgb25jZSB0aGUgVUUgaXMgYXV0aGVudGljYXRlZCBhbmQgdG8gYWxsb3cg YWNjZXNzDQo+IHRvIHRoZSBGQVAsIHdoYXRldmVyIHRoZSBVRSBzZW5kcyBpcyBiZXlvbmQgdGhl IGNvbnRyb2wgb2YgdGhlIEZBUCANCj4ganVzdCBhcyB3aGF0IGlzIGhhcHBlbmVkIHRvZGF5IGZv ciBhbnkgbW9iaWxlIGRldmljZS4gIElzbid0IGl0PyANCj4gDQo+IGlmIGV2ZXJ5IGlwIHBhY2tl dCBjYXJyaWVzIFNlR1cgbm90YXJpemVkIHNpZ25hdHVyZSwgSG93IGFuZCB3aGVyZSANCj4gdGhp cyBzaWduYXR1cmUgY2FycmllZCBpbnNpZGUgaXAgcGFja2V0PyBjYXRpb25zIGluc2lkZSBJUHNl YyBwYWNrZXQNCj4gcHJvY2Vzc2luZz8gSXMgdGhpcyBwcm9jZXNzaW5nIGhhcHBlbnMgb3V0c2lk ZSBvZiBJUHNlYz8gaXMgaXQgDQo+IG91dHNpZGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudD8gSXQg d291bGQgYmUgZ3JlYXQsIGlmIHNvbWUgb2YgdGhlc2UgDQo+IGFzcGVjdHMgYXJlIGFkZHJlc3Nl ZCBpbiB0aGUgZHJhZnQuIA0KPiANCj4gVHJpY2NpID4gU2luY2UgSSBoYXZlIGFscmVhZHkgZXhw bGFpbmVkIHRvIHlvdSB0aGF0LCB3ZSBhcmUgbm90IA0KPiBwcm9wb3NpbmcgdG8gbm90YXJpemUg ZXZlcnkgc2luZ2xlIHBhY2tldCBzZW50IGJ5IEZBUC4gIEhlbmNlLCBJIA0KPiBkb24ndCB0aGlu ayB0aGF0IEkgbmVlZCB0byByZXNwb25kIHRvIHlvdXIgcmVzdCBvZiB0aGUgcXVlc3Rpb25zIGFi b3ZlLiAgDQoNCj4gDQo+IFRyaWNjaSA+IFRIQU5LIFlPVSBmb3IgYXNraW5nIGEgZ29vZCBxdWVz dGlvbi4gIENoZWVycy4gDQo+IA0KPiBUaGFua3MsIA0KPiANCj4gRGhhcm1hbmFuZGFuYSBSZWRk eSBQb3RodWxhLiANCj4gDQo+ICYgeWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJB cmlhbCIsInNhbnMtc2VyaWYiJz4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IElQc2VjIG1haWxpbmcgbGlzdA0KPiBJUHNlY0BpZXRmLm9yZw0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwc2VjDQo+IA0KPiANCj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0g DQo+IFpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250 YWluZWQgaW4gdGhpcyANCj4gbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidz IG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIA0KPiBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlh bC4gUmVjaXBpZW50DQo+IGJzcDthcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5k IGFyZSBub3QgcGVybWl0dGVkIHRvIA0KPiBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBj b21tdW5pY2F0aW9uIHRvIG90aGVycy4gDQo+IFRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFu c21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIA0KPiBpbnRlbmRlZCBzb2xlbHkg Zm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleQ0KPiBh cmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBs ZWFzZSANCj4gbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3Mg ZXhwcmVzc2VkIGluIHRoaXMgDQo+IG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFs IHNlbmRlci4gDQo+IFRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFu ZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gDQpzeXN0ZW0uIA0K --=_alternative 0013E6314825799E_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPiZuYnNwOzwvZm9udD4NCjxicj4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPkRoYXJtYW5hbmRhbmEgUmVkZHkgUG90aHVsYSAmbHQ7ZGhhcm1hbmFuZGFuYS5w b3RodWxhbUBodWF3ZWkuY29tJmd0Ow0Kd3JvdGUgb24gMjAxMi0wMi0wNyAyMDoxNzozNTo8YnI+ DQo8YnI+DQomZ3Q7IEhpIFphaWZlbmcsPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBBYm91 dCBlcnJvciBjb25kaXRpb24sIElzIHRoZXJlIGFueSBwbGFuIHRvIGFkZA0KbmV3IGVycm9yIG1l c3NhZ2UgPGJyPg0KJmd0OyB0eXBlcyB0byBOb3RpZnkgcGF5bG9hZCB0byBoYW5kbGUgdmVyaWZp Y2F0aW9uIGZhaWwgc2NlbmFyaW9zPyBJIDxicj4NCiZndDsgZmVlbCBpdCB3b3VsZCBhcHByb3By aWF0ZSB0byBpbmZvcm0gRkFQLCBzbyB0aGlzIGhlbHBzIEZBUCB0byA8YnI+DQomZ3Q7IGNvcnJl Y3QgaWYgbWlzY29uZmlndXJlZC48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZn dDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEkgaGF2ZSBv bmUgbW9yZSBxdWVzdGlvbiBhYm91dCB0aGUgcHJvcG9zZWQgc29sdXRpb24uDQpDYW6hr3Qgd2Ug PGJyPg0KJmd0OyBoYW5kbGUgdmVyaWZ5aW5nIEZBUCBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9u IGluc2lkZSBGZW10byBHYXRld2F5Pzxicj4NCiZndDsgRmVtdG8gR2F0ZXdheSBjYW4gaW5mb3Jt IHNlY3VyaXR5IGdhdGV3YXkgdG8gYnJpbmcgZG93biB0aGUgdHVubmVsLA0KPGJyPg0KJmd0OyBp ZiB2ZXJpZmljYXRpb24gZmFpbHMuIEFueXdheSBmYWxzZSBpbmZvcm1hdGlvbiBzdWJtaXNzaW9u IHZlcnkgPGJyPg0KJmd0OyB1bmxpa2VseSBzY2VuYXJpbywgc28gd2h5IHdlIG5lZWQgdG8gbWFr ZSB0aGlzIGNvbmZpZyBwYXlsb2FkIDxicj4NCiZndDsgZXhjaGFuZ2UgYXMgcGFydCBvZiByZWd1 bGFyIElLRSBuZWdvdGlhdGlvbj8gSSBmZWVsIGFkZGl0aW9uIG9mIG1vcmU8YnI+DQomZ3Q7IGNv bmZpZyBwYXlsb2FkcyBtaWdodCBpbXBhY3QgdHVubmVsIHNldHVwIHJhdGUuPC9mb250PjwvdHQ+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+VGhlIHJlYXNvbiB3aHkgd2UgaGF2ZSB0aGlzIGRyYWZ0IGlzIHRvIGVuYWJs ZSBmZW10bw0KZ2F0ZXdheSAob3Igb3RoZXIgY29yZSBuZXR3b3JrIGVudGl0aWVzIGluIGNlcnRh aW4gc2NlbmFyaW9zKSB0byB2ZXJpZnkNCnRoZSBGQVAgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlv bi4gQnV0IHRoZSBwcm9ibGVtIGlzIHRoZSBmZW10byBnYXRld2F5DQpkb2VzIG5vdCBoYXZlIHRo ZSBjYXBhYmlsaXR5IHRvIGRvIHNvIGFjY29yZGluZyB0byBmZW10byBhcmNoaXRlY3R1cmUsDQpi ZWNhdXNlIHRoZSBGQVAgaXMgbm90IGF1dGhlbnRpY2F0ZWQgYnkgZmVtdG8gZ2F0ZXdheSBhbmQg dGhlcmUgaXMgbm8gaW50ZXJmYWNlDQpiZXR3ZWVuIGZlbXRvIGdhdGV3YXkgYW5kIHRoZSBlbnRp dGllcyB3aGljaCBhcmUgcmVzcG9uc2libGUgZm9yIHRoZSBhdXRoZW50aWNhdGlvbg0Kb2YgdGhl IEZBUCAoaS5lLiB0aGUgU2VHVykuIE9mIGNvdXJzZSwgaWYgdGhlIGZlbXRvIGFyY2hpdGVjdHVy ZSBjb3VsZA0KYmUgY2hhbmdlZCwgZS5nLiBhZGRpbmcgYW4gaW50ZXJmYWNlIGJldHdlZW4gU2VH VyBhbmQgY29yZSBuZXR3b3JrLCBjb3VsZA0Kc29sdmUgdGhlIHByb2JsZW0gdG9vLCBidXQgdGhh dCBoYXMgdGhlIGFyY2hpdGVjdHVyYWwgaW1wYWN0cywgaGVuY2UsIEkNCnRoaW5rIHRoZSBjaGFu Z2UgaXMgaHVnZS4gPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7IFJlZ2FyZHMsPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IERo YXJtYW5hbmRhbmEgUmVkZHkgUG90aHVsYTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgRnJv bTogem9uZy56YWlmZW5nQHp0ZS5jb20uY24gW21haWx0bzp6b25nLnphaWZlbmdAenRlLmNvbS5j bl0NCjxicj4NCiZndDsgU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDAyLCAyMDEyIDE6NTEgUE08 YnI+DQomZ3Q7IFRvOiBkaGFybWFuYW5kYW5hLnBvdGh1bGFtQGh1YXdlaS5jb208YnI+DQomZ3Q7 IENjOiBpcHNlY0BpZXRmLm9yZzsgaXBzZWMtYm91bmNlc0BpZXRmLm9yZzsgdHNvQHp0ZXVzYS5j b208YnI+DQomZ3Q7IFN1YmplY3Q6ILTwuLQ6IFJFOiBbSVBzZWNdIFtJUFNlY106IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3INCjxicj4NCiZndDsgZHJhZnQtem9uZy1pcHNlY21lLWlrZXYy LWNwZXh0NGZlbXRvLTAwLnR4dDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0 OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0 OyBIaSBEaGFybWFuYW5kYW5hOiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhlIG5vdGFyaXplZCBz aWduYXR1cmUgd2lsbCBub3QgYmUgc2VudCBvaW4gZXZlcnkgSVBTZWMgcGFja2V0LiBJdA0KPGJy Pg0KJmd0OyB3aWxsIGJlIHNlbnQgdG8gY29yZSBuZXR3b3JrIHdoZW4gdGhlIEZBUCByZWdpc3Rl cnMgdG8gdGhlIGNvcmUgPGJyPg0KJmd0OyBuZXR3b3JrIGluc2lkZSB0aGUgc2lnbmFsbGluZyBi ZXR3ZWVuIHRoZSBGQVAgYW5kIGNvcmUgbmV0d29yay4gPGJyPg0KJmd0OyBBZnRlciBpdCBpcyBy ZWdpc3RlcmVkIHRvIHRoZSBjb3JlIG5ldHdvcmssIHRoZSBGQVAgaXMgYWN0aXZhdGVkIHRvDQo8 YnI+DQomZ3Q7IGFjY2VwdCBhdHRhY2htZW50IG9mIG1vYmlsZSB0ZXJtaW5hbHMuIEkgd2lzaCB0 aGlzIGNsYXJpZmllcy4gVGhhbmtzIQ0KPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEJSIDxicj4NCiZn dDsgWmFpZmVuZzxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgPGJyPg0KPC9mb250PjwvdHQ+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgRGhhcm1hbmFuZGFuYSBSZWRk eSBQb3RodWxhICZsdDtkaGFybWFuYW5kYW5hLnBvdGh1bGFtQGh1YXdlaS5jb20mZ3Q7DQo8L2Zv bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgMjAxMi0wMS0zMSAxODo0MyA8L2Zv bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyDH67TwuLQguPg8 YnI+DQomZ3Q7IGRoYXJtYW5hbmRhbmEucG90aHVsYW1AaHVhd2VpLmNvbTwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IMrVvP7IyzwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IHRzb0B6dGV1c2EuY29tIDwvZm9u dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7ILOty808L2ZvbnQ+ PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBpcHNlY0BpZXRmLm9y ZywgaXBzZWMtYm91bmNlc0BpZXRmLm9yZywgem9uZy56YWlmZW5nQHp0ZS5jb20uY24gPC9mb250 PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsg1vfM4jwvZm9udD48 L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IFJFOiBbSVBzZWNdIFtJ UFNlY106IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtem9uZy08YnI+DQomZ3Q7 IGlwc2VjbWUtaWtldjItY3BleHQ0ZmVtdG8tMDAudHh0PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZn dDsgSGkgVHJpY2NpLCA8YnI+DQomZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7IFRoYW5rcyBmb3IgeW91 ciBleHBsYW5hdGlvbi4gSSBnZXQgeW91ciBwb2ludCB3aHkgbm90YXJpemVkIDxicj4NCiZndDsg c2lnbmF0dXJlIHJlcXVpcmVkLCBidXQgbXkgcXVlc3Rpb24gaXMgbm90IGFib3V0IG5vdGFyaXpp bmcgZXZlcnkNCjxicj4NCiZndDsgcGFja2V0LiBMZXQgbWUgYXNrIG15IHF1ZXN0aW9uIGluIGRp ZmZlcmVudCB3YXksIElzIEZBUCBzZW5kcyA8YnI+DQomZ3Q7IG5vdGFyaXplZCBzaWduYXR1cmUg aW4gZXZlcnkgSVBTZWMgcGFja2V0IHRvIGNvcmUgbmV0d29yaz8gQXMgSSA8YnI+DQomZ3Q7IHVu ZGVyc3RhbmQgZnJvbSB0aGUgZHJhZnQgdGhhdCBiZWZvcmUgYWNjZXB0aW5nIGV2ZXJ5IElQU2Vj IHBhY2tldCwNCjxicj4NCiZndDsgY29yZSBuZXR3b3JrIHZhbGlkYXRlIHRoZSBub3Rhcml6ZWQg c2lnbmF0dXJlLiBXaGVyZSBpcyB0aGlzIDxicj4NCiZndDsgbm90YXJpemVkIHNpZ25hdHVyZSBw bGFjZWQgaW4gZXZlcnkgSVBTZWMgcGFja2V0PyA8YnI+DQomZ3Q7IFRoYW5rcywgPGJyPg0KJmd0 OyBEaGFybWFuYW5kYW5hIFJlZGR5IFBvdGh1bGEgPGJyPg0KJmd0OyAmbmJzcDsgPGJyPg0KJmd0 OyBGcm9tOiB0c29AenRldXNhLmNvbSBbbWFpbHRvOnRzb0B6dGV1c2EuY29tXSA8YnI+DQomZ3Q7 IFNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAyNSwgMjAxMiAxOjI2IFBNPGJyPg0KJmd0OyBUbzog ZGhhcm1hbmFuZGFuYS5wb3RodWxhbUBodWF3ZWkuY29tPGJyPg0KJmd0OyBDYzogaXBzZWNAaWV0 Zi5vcmc7IGlwc2VjLWJvdW5jZXNAaWV0Zi5vcmc7IHpvbmcuemFpZmVuZ0B6dGUuY29tLmNuOzxi cj4NCiZndDsgdHNvQHp0ZXVzYS5jb208YnI+DQomZ3Q7IFN1YmplY3Q6IFJlOiBbSVBzZWNdIFtJ UFNlY106IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtPGJyPg0KJmd0OyB6b25n LWlwc2VjbWUtaWtldiA8YnI+DQomZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7IERlYXIgRGhhcm1hbmFu ZGFuYSwgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgaG9wZSB0aGF0IEkgYWRkcmVzcyB5b3UgY29y cmVjdGx5LiAmbmJzcDtJZiBub3QsIHBsZWFzZSBwYXJkb24gbXkNCmlnbm9yYW5jZS4gPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IEFzIHRoaXMgd2VlayBpcyBzcHJpbmcgZmVzdGl2YWwsIFphaUZlbmcg aXMgbm90IGF2YWlsYWJsZS4gJm5ic3A7SGVuY2UsDQpJPGJyPg0KJmd0OyB3b3VsZCBsaWtlIHRv IHJlc3BvbmQgdG8geW91IG9uIGJlaGFsZiBvZiBoZXIuICZuYnNwOyA8YnI+DQomZ3Q7IDxicj4N CiZndDsgQ291bGQgeW91IHBsZWFzZSBraW5kIHNlZSBteSByZXNwb25zZXMgdG8geW91IGlubGlu ZSBiZWxvdy4gJm5ic3A7TWFueQ0KdGhhbmtzLiA8YnI+DQomZ3Q7IFRyaWNjaSA8YnI+DQo8L2Zv bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyA1cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OycmZ3Q7RGhhcm1h bmFuZGFuYQ0KUmVkZHkgPGJyPg0KJmd0OyAmbHQ7ZGhhcm1hbmFuZGFuYS5wb3RodWxhbUBodWF3 ZWkuY29tJmd0OyA8YnI+DQomZ3Q7IFNlbnQgYnk6IGlwc2VjLWJvdW5jZXNAaWV0Zi5vcmcgPC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDAxLzI0LzIwMTIgMDQ6MDQgQU0g PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0 Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IFBsZWFzZSByZXNwb25kIHRv PGJyPg0KJmd0OyBkaGFybWFuYW5kYW5hLnBvdGh1bGFtQGh1YXdlaS5jb208L2ZvbnQ+PC90dD4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBUbyA8L2ZvbnQ+PC90dD4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyB6b25nLnphaWZlbmdAenRlLmNvbS5j biA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBjYzwv Zm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IGlwc2VjQGll dGYub3JnIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7 IFN1YmplY3Q8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0 OyBSZTogW0lQc2VjXSBbSVBTZWNdOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LXpvbmctPGJyPg0KJmd0OyBpcHNlY21lLWlrZXYyLWNwZXh0NGZlbXRvLTAwLnR4dDwvZm9udD48 L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5i c3A7IDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+ PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxi cj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEhpIFphaWZlbmcsIDxicj4NCiZndDsgJm5i c3A7PGJyPg0KJmd0OyBJIGhhdmUgZm9sbG93aW5nIHF1ZXN0aW9ucyBhbmQgY29uY2VybnMgYWJv dXQgeW91ciBwcm9wb3NlZCBzb2x1dGlvbjxicj4NCiZndDsgJnF1b3Q7VGhlIEZBUCB3aWxsIHRo ZW4gc2VuZCB0aGUgRkFQIGluZm9ybWF0aW9uIHRvZ2V0aGVyIHdpdGggdGhlDQo8YnI+DQomZ3Q7 IGNvcnJlc3BvbmRpbmcgU2VHVyBub3Rhcml6ZWQgc2lnbmF0dXJlIHRvIGl0cyBtb2JpbGUgb3Bl cmF0b3IncyBjb3JlPGJyPg0KJmd0OyBuZXR3b3JrLiBUaGUgY29yZSBuZXR3b3JrIHZlcmlmaWVz IHRoZSBGQVAgaW5mb3JtYXRpb24gYnkgdmFsaWRhdGluZzxicj4NCiZndDsgdGhlIFNlR1cgbm90 YXJpemVkIHNpZ25hdHVyZSBwcmlvciB0byB0aGUgYWNjZXB0YW5jZSBvZiB0aGUgaW5mb3JtYXRp b24mcXVvdDsuDQo8YnI+DQomZ3Q7IElzIGV2ZXJ5IGlwIHBhY2tldCBjYXJyaWVzIFNlR1cgbm90 YXJpemVkIHNpZ25hdHVyZSBhZnRlciBzZXJ2ZXIgPGJyPg0KJmd0OyBzZW5kcyBub3Rhcml6ZWQg c2lnbmF0dXJlIHRvIHRoZSBjbGllbnQ/IGlmIG5vdCwgd2hhdCdzIHRoZSBwb2ludA0KaW48YnI+ DQomZ3Q7IHJldHVybmluZyBub3Rhcml6ZWQgc2lnbmF0dXJlIHRvIHRoZSBjbGllbnQ/IEkgYmVs aWV2ZSB5ZXMsIGlmIHNvLA0KPGJyPg0KJmd0OyBJdCB3aWxsIGluY3JlYXNlIHBlcmNlbnRhZ2Ug b2Ygb3ZlcmhlYWQgcGVyIHBhY2tldCBhbmQgbWF5IGltcGFjdA0KPGJyPg0KJmd0OyBxdWFsaXR5 IG9mIHJlYWwgdGltZSB2b2ljZSBhbmQgdmlkZW8uIDxicj4NCiZndDsgPGJyPg0KJmd0OyBUcmlj Y2kgJmd0OyBZb3UgYXNrIGEgdmVyeSBsZWdpdGltYXRlIHF1ZXN0aW9uLiAmbmJzcDtNYXkgYmUg b3VyIGRyYWZ0DQppcyA8YnI+DQomZ3Q7IG5vdCBjbGVhciBlbm91Z2ggdG8gZXhwbGFpbiB0aGUg bWFpbiBtb3RpdmF0aW9uIG9mIHRoaXMgZHJhZnQgZm9yDQo8YnI+DQomZ3Q7IHRhcmdldCBvZiB0 aGUgYXR0YWNrLiAmbmJzcDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRyaWNjaSAmZ3Q7IFRoZSBt YWluIGNvbmNlcm4gaXMgbm90IGFib3V0IHRoZSBhdHRhY2sgZm9yICZxdW90O3VuYXV0aG9yaXpl ZA0KPGJyPg0KJmd0OyBGQVAmcXVvdDsgdG8gc2VuZCBhbnkgZGF0YSB0byB0aGUgbW9iaWxlIGNv cmUgbmV0d29yay4gJm5ic3A7VGhlIG1haW4NCmNvbmNlcm4gPGJyPg0KJmd0OyBpcyBhYm91dCB0 aGUgYXR0YWNrIG9mIHRoZSAmcXVvdDt1bmF1dGhvcml6ZWQgRkFQJnF1b3Q7IHRvIHNlbmQgdGhl DQomcXVvdDtmYWxzZSZxdW90OyA8YnI+DQomZ3Q7IGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24g KGUuZy4gc3VjaCBhcyBjaGFuZ2luZyB0aGUgRkFQIGZyb20gPGJyPg0KJmd0OyAmcXVvdDtDbG9z ZWQmcXVvdDsgdG8gYmVjb21lICZxdW90O09wZW4mcXVvdDsgO2ZhbHNlJnF1b3Q7IGFjY2Vzcw0K Y29udHJvbCByZWxhdGVkIGluZm9ybWF0aW9uPGJyPg0KJmd0OyAoZS5nLiBhbGxvd2luZyBhIDNH UFAgVUUgd2hpY2ggaXMgc3VwcG9zZWQgdG8gYmUgYWxsb3dlZCB0byBhY2Nlc3MNCjxicj4NCiZn dDsgdGhlIEZBUCBhbmQgdG8gaGF2ZSB0aGUgYWNjZXNzIHByaXZpbGVhZ2UgdG8gdGhlIEZBUCAt IGkuZS4gQ1NHIGluZm88YnI+DQomZ3Q7IGFsdGVyYXRpb24sIGV0Yy4pLiAmbmJzcDtPbmNlIHRo ZSBGQVAncyBjb25maWd1cmF0aW9uIGFuZCBhY2Nlc3MgY29udHJvbA0KPGJyPg0KJmd0OyBtYW5h Z2VtZW50IGFyZSBhdXRoZW50aWNhdGVkIHZpYSB0aGUgc3VwcG9ydCBvZiB0aGUgbm90YXJpemF0 aW9uIGJ5DQo8YnI+DQomZ3Q7IHRoZSBTZUdXLCB0aGVuLCB0aGUgcmVzdCBvZiB0aGUgM0dQUCBV RXMnIGFjY2VzcyB0byB0aGUgRkFQIGNhbiA8YnI+DQomZ3Q7IGZvbGxvdyB0aGUgZXhpc3Rpbmcg YWNjZXNzIGNvbnRyb2wgYW5kIFVFLWJhc2VkIDxicj4NCiZndDsgYXV0aGVudGljYXRpb24vYXV0 aG9yaXphdGlvbiBwcm9jZWR1cmVzIGF0IHRoZSBVRSBsZXZlbCdzLiAmbmJzcDsNCjxicj4NCiZn dDsgPGJyPg0KJmd0OyBUcmljY2kgJmd0OyBPZiBjb3Vyc2UsIG9uY2UgdGhlIFVFIGlzIGF1dGhl bnRpY2F0ZWQgYW5kIHRvIGFsbG93IGFjY2Vzczxicj4NCiZndDsgdG8gdGhlIEZBUCwgd2hhdGV2 ZXIgdGhlIFVFIHNlbmRzIGlzIGJleW9uZCB0aGUgY29udHJvbCBvZiB0aGUgRkFQDQo8YnI+DQom Z3Q7IGp1c3QgYXMgd2hhdCBpcyBoYXBwZW5lZCB0b2RheSBmb3IgYW55IG1vYmlsZSBkZXZpY2Uu ICZuYnNwO0lzbid0DQppdD8gJm5ic3A7IDxicj4NCiZndDsgJm5ic3A7PGJyPg0KJmd0OyBpZiBl dmVyeSBpcCBwYWNrZXQgY2FycmllcyBTZUdXIG5vdGFyaXplZCBzaWduYXR1cmUsIEhvdyBhbmQg d2hlcmUNCjxicj4NCiZndDsgdGhpcyBzaWduYXR1cmUgY2FycmllZCBpbnNpZGUgaXAgcGFja2V0 PyBjYXRpb25zIGluc2lkZSBJUHNlYyBwYWNrZXQ8YnI+DQomZ3Q7IHByb2Nlc3Npbmc/IElzIHRo aXMgcHJvY2Vzc2luZyBoYXBwZW5zIG91dHNpZGUgb2YgSVBzZWM/IGlzIGl0IDxicj4NCiZndDsg b3V0c2lkZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50PyBJdCB3b3VsZCBiZSBncmVhdCwgaWYgc29t ZSBvZiB0aGVzZQ0KPGJyPg0KJmd0OyBhc3BlY3RzIGFyZSBhZGRyZXNzZWQgaW4gdGhlIGRyYWZ0 LiA8YnI+DQomZ3Q7ICZuYnNwOzxicj4NCiZndDsgVHJpY2NpICZndDsgU2luY2UgSSBoYXZlIGFs cmVhZHkgZXhwbGFpbmVkIHRvIHlvdSB0aGF0LCB3ZSBhcmUgbm90DQo8YnI+DQomZ3Q7IHByb3Bv c2luZyB0byBub3Rhcml6ZSBldmVyeSBzaW5nbGUgcGFja2V0IHNlbnQgYnkgRkFQLiAmbmJzcDtI ZW5jZSwNCkkgPGJyPg0KJmd0OyBkb24ndCB0aGluayB0aGF0IEkgbmVlZCB0byByZXNwb25kIHRv IHlvdXIgcmVzdCBvZiB0aGUgcXVlc3Rpb25zIGFib3ZlLg0KJm5ic3A7IDxicj4NCiZndDsgPGJy Pg0KJmd0OyBUcmljY2kgJmd0OyBUSEFOSyBZT1UgZm9yIGFza2luZyBhIGdvb2QgcXVlc3Rpb24u ICZuYnNwO0NoZWVycy4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoYW5rcywgPGJyPg0KJmd0OyAm bmJzcDs8YnI+DQomZ3Q7IERoYXJtYW5hbmRhbmEgUmVkZHkgUG90aHVsYS4gPGJyPg0KJmd0OyAm bmJzcDs8YnI+DQomZ3Q7ICZhbXA7IHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7JyZndDsNCiZuYnNwOzxicj4N CiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQomZ3Q7IElQc2VjIG1haWxpbmcgbGlzdDxicj4NCiZndDsgSVBzZWNAaWV0Zi5vcmc8YnI+DQom Z3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWM8YnI+DQomZ3Q7 IDxicj4NCiZndDsgJm5ic3A7IDxicj4NCiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gPGJyPg0KJmd0OyBaVEUgSW5mb3JtYXRpb24g U2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMNCjxicj4N CiZndDsgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlv bi4gVGhpcyBtYWlsIDxicj4NCiZndDsgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJl Y2lwaWVudDxicj4NCiZndDsgYnNwO2FyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBh bmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gPGJyPg0KJmd0OyBkaXNjbG9zZSB0aGUgY29udGVudHMg b2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4gPGJyPg0KJmd0OyBUaGlzIGVtYWlsIGFu ZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZA0KPGJy Pg0KJmd0OyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3Ig ZW50aXR5IHRvIHdob20gdGhleTxicj4NCiZndDsgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2UgPGJyPg0KJmd0OyBub3RpZnkgdGhl IG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcw0K PGJyPg0KJmd0OyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuIDxi cj4NCiZndDsgVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNw YW0gYnkgWlRFIEFudGktU3BhbQ0Kc3lzdGVtLiA8L2ZvbnQ+PC90dD4NCg== --=_alternative 0013E6314825799E_=-- From iana-shared@icann.org Tue Feb 7 18:08:34 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08DB221F84FB for ; Tue, 7 Feb 2012 18:08:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.08 X-Spam-Level: X-Spam-Status: No, score=-0.08 tagged_above=-999 required=5 tests=[AWL=1.228, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2AeeNlb8HdMO for ; Tue, 7 Feb 2012 18:08:32 -0800 (PST) Received: from pechora8.dc.icann.org (unknown [IPv6:2620:0:2830:201::1:74]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB5321F84D6 for ; Tue, 7 Feb 2012 18:08:27 -0800 (PST) Received: from request1.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by pechora8.dc.icann.org (8.13.8/8.13.8) with ESMTP id q18282bD006201; Tue, 7 Feb 2012 21:08:22 -0500 Received: from request1.lax.icann.org (localhost.localdomain [127.0.0.1]) by request1.lax.icann.org (8.13.8/8.13.8) with ESMTP id q18281vq030765; Wed, 8 Feb 2012 02:08:01 GMT Received: (from apache@localhost) by request1.lax.icann.org (8.13.8/8.13.8/Submit) id q1827x3l030760; Wed, 8 Feb 2012 02:07:59 GMT From: "Pearl Liang via RT" In-Reply-To: References: <20162.16194.361337.415232@fireball.kivinen.iki.fi> <20235.3284.301719.250098@fireball.kivinen.iki.fi> Message-ID: Precedence: bulk X-RT-Loop-Prevention: IANA RT-Ticket: IANA #111200 Managed-by: RT 3.8.HEAD (http://www.bestpractical.com/rt/) RT-Originator: pearl.liang@icann.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Date: Wed, 8 Feb 2012 02:07:59 +0000 X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.3 (pechora8.dc.icann.org [192.0.46.74]); Tue, 07 Feb 2012 21:08:23 -0500 (EST) X-Mailman-Approved-At: Wed, 08 Feb 2012 08:12:35 -0800 Cc: ipsec@ietf.org, turners@ieca.com, liang@icann.org, kivinen@iki.fi, stephen.farrell@cs.tcd.ie Subject: [IPsec] [IANA #111200] [old message] Possible update to isakmp-registry X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Reply-To: iana-matrix@iana.org List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 02:08:34 -0000 Hi, Tero, This is very useful information. I've revised the ipsec-registry to include your edits (included below). Though I have a few remaining questions: - For Registry Name: IPSEC Authentication Methods (Value 3) > Registry Name: IPSEC Authentication Methods (Value 3) > Current: Standards-track RFC > > There is nothing about this in the RFC2409, so I would say either "RFC > required" or "Specification required" would be ok. There is draft > http://tools.ietf.org/html/draft-harkins-ike-iana-update-00 already > proposing this change. Question1: since a new document is in work to update this, the registration procedures will be updated when the document is made to IETF Last call. Would it be okay to not change the listed registration procedures at this time? - For Registry Name: PRF (Value 13) > Registry Name: PRF (Value 13) > Current: Standards-track or Informational RFC > > There is nothing about this in the RFC2409, so I would say either "RFC > required" or "Specification required" would be ok. > Question2: Would it be sufficient to list "RFC required" only? - For these 'early assignment' registrations as per ietf-ipsec-ike-ecc-groups, you commented the following: > > 6 EC2NGF163Random2 > > 7 EC2NGF163Koblitz > > 8 EC2NGF283Random > > 9 EC2NGF283Koblitz > > 10 EC2NGF409Random > > 11 EC2NGF409Koblitz > > 12 EC2NGF571Random > > 13 EC2NGF571Koblitz > > These are from the > http://tools.ietf.org/html/draft-ietf-ipsec-ike-ecc-groups-04 version, > i.e. the registry was updated at some point in 2002 even when the > registry had registration policy of "RFC Required" and the document > was still draft (and was never published as RFC). > > I think you should remove "Panjwani" and "Blake-Wilson" and put > "ipsec-ike-ecc-groups" for all of them, and put some down a footnote > saying that the registry was updated too early and the draft never > made it to the RFC, but as these values might be used by some > implementations they are left there in the registry, but new > implementations should not use them. Also the reference could point > out that the values in the registry match the -04 version of the > document. [pl] I have removed the version number from the draft string. (I was unable to locate those assignments (e.g. EC2NGF163Random2) in version 4.) I have also remove both "Panjwani" and "Blake-Wilson" from the registry. I have also marked the draft-ipsec-ike-ecc-group as expired in the registry since it has never made it to an RFC. Regarding the footnote, I've drafted something as follows: [[ Note: these values were reserved as per draft-ipsec-ike-ecc-groups which never made it to the RFC. These values might be used by some implementations as currently registered in the registry, but new implementations should not use them. ]] Question: does the above look okay? Please comment. When I receive your edits, I will add the "Note" to the registry. Please see: http://www.iana.org/assignments/ipsec-registry When you have updates for the isakmp-registry, please send them to us. Thank you again for your help, ~pearl On Mon Jan 09 08:24:39 2012, kivinen@iki.fi wrote: > [I CCed the ipsec@ietf.org list, as this changes the registration > policies, and we have already had some discussion about this earlier > on the list and other people there might also have their opinion about > the matter.] > > Pearl Liang via RT writes: > > 1) What are the registration procedures for these sub-registries > > listed in http://www.iana.org/assignments/ipsec-registry: > > > > - Exchange Type > > - Additional Exchanges Defined-- XCHG values > > - Next Payload Types > > - Notify Message Types > > - Notify Messages - Error Types (1-8191) > > - Notify Messages - Status Types (16384-24575) > > > > ? I would like to update "Not defined" if possible. > > For most of those it is not defined... I.e the original RFC does not > specify any registration procedures for them (or for some other > registries we have there). > > I would most likely think it would be best to put them as > "Specification required" or "RFC required". > > Actually I think we should go through the RFC2407-2409 and see from > there for which registries they do specify any registration policies, > and use those values for only those registries and put everything else > as "Specification required" or "RFC Required". > > ---------------------------------------------------------------------- > > Registry Name: Attribute Classes > Current: Standards-track RFC > RFC2409: 11.1 Attribute Classes > > Attributes negotiated in this protocol are identified by their class. > Requests for assignment of new classes must be accompanied by a > standards-track RFC which describes the use of this attribute. > > -> Standards-track RFC, already OK > > ---------------------------------------------------------------------- > > Registry Name: Encryption Algorithm Class Values (Value 1) > Current: Standards-track or Informational RFC > RFC2409: 11.2 Encryption Algorithm Class > > Values of the Encryption Algorithm Class define an encryption > algorithm to use when called for in this document. Requests for > assignment of new encryption algorithm values must be accompanied by > a reference to a standards-track or Informational RFC or a reference > to published cryptographic literature which describes this algorithm. > > -> Specification required, currently this is Standards-track or > Informational RFC, but I think Specification required is closer to > what the RFC says about "a reference to published cryptographic > literature". > > ---------------------------------------------------------------------- > > Registry Name: Hash Algorithm (Value 2) > Current: Standards-track or Informational RFC > RFC2409: 11.3 Hash Algorithm > > Values of the Hash Algorithm Class define a hash algorithm to use > when called for in this document. Requests for assignment of new hash > algorithm values must be accompanied by a reference to a standards- > track or Informational RFC or a reference to published cryptographic > literature which describes this algorithm. Due to the key derivation > and key expansion uses of HMAC forms of hash algorithms in IKE, > requests for assignment of new hash algorithm values must take into > account the cryptographic properties-- e.g it's resistance to > collision-- of the hash algorithm itself. > > -> Specification required, see above. > > ---------------------------------------------------------------------- > > Registry Name: IPSEC Authentication Methods (Value 3) > Current: Standards-track RFC > > There is nothing about this in the RFC2409, so I would say either "RFC > required" or "Specification required" would be ok. There is draft > http://tools.ietf.org/html/draft-harkins-ike-iana-update-00 already > proposing this change. > > ---------------------------------------------------------------------- > > Registry Name: Group Description (Value 4) > Current: Standards-track or Informational RFC > Registry Name: Group Type (Value 5) > Current: Standards-track or Informational RFC > RFC2409: 11.4 Group Description and Group Type > > Values of the Group Description Class identify a group to use in a > Diffie-Hellman exchange. Values of the Group Type Class define the > type of group. Requests for assignment of new groups must be > accompanied by a reference to a standards-track or Informational RFC > which describes this group. Requests for assignment of new group > types must be accompanied by a reference to a standards-track or > Informational RFC or by a reference to published cryptographic or > mathmatical literature which describes the new type. > > Group Description (Value 4) -> RFC required > Group Type (Value 5) -> Specification required > > ---------------------------------------------------------------------- > > Registry Name: Life Type (Value 11) > Current: Specification Required > RFC2409: 11.5 Life Type > > Values of the Life Type Class define a type of lifetime to which the > ISAKMP Security Association applies. Requests for assignment of new > life types must be accompanied by a detailed description of the units > of this type and its expiry. > > -> Hmm... this is vague, I would expect it means "Specification > required", so ok already. > > ---------------------------------------------------------------------- > > Registry Name: PRF (Value 13) > Current: Standards-track or Informational RFC > > There is nothing about this in the RFC2409, so I would say either "RFC > required" or "Specification required" would be ok. > > ---------------------------------------------------------------------- > > Registry Name: Exchange Type > Current: Not defined > > There is nothing in RFC2409/RFC2408. There has not been additions to > this, and I do not expect there to be one (as all new stuff should be > done on the protocol which obsoleted this one). I would say "Standards > Action" would most likely be best for this. > > ---------------------------------------------------------------------- > > Registry Name: Additional Exchanges Defined-- XCHG values > Current: Not defined > > There is nothing in RFC2409/RFC2408. Same as above -> "Standards > Action". > > ---------------------------------------------------------------------- > > Registry Name: ISAKMP Domain of Interpretation (DOI) > Current: Standards-track RFC > RFC2408: Domain of Interpretation > > The Domain of Interpretation (DOI) is a 32-bit field which identifies > the domain under which the security association negotiation is taking > place. Requests for assignments of new DOIs must be accompanied by a > standards-track RFC which describes the specific domain. > > -> "Standards action" (i.e. Standards-track RFC) > > ---------------------------------------------------------------------- > > Registry Name: Next Payload Types > Current: Internet Draft > > There is nothing in RFC2409/RFC2408. There has been more of these, so > "RFC required", I think Internet Draft is bit too low, and not > matching the RFC5226 usages. > > ---------------------------------------------------------------------- > > Registry Name: Notify Message Types > Current: Not defined > Sub-registry: Notify Messages - Error Types (1-8191) > Current: Not defined > Sub-Registry: Notify Messages - Status Types (16384-24575) > Current: Not defined > > No additions to these registries, but these are large registries, so > perhaps "RFC required". > > ---------------------------------------------------------------------- > > There is a problem in the "IPSEC Authentication Methods (Value 3)" as > there is 3 values which do not have any real specification, i.e. > > 6 Encryption with El-Gamal > 7 Revised encryption with El-Gamal > 8 ECDSA signatures [Fahn] > > As there is no reference to any document or anything, I have no idea > how anybody could actually implement those in interoperable manner. I > would suggest changing those to: > > 6 Reserved (was Encryption with El-Gamal) > 7 Reserved (was Revised encryption with El-Gamal) > 8 Reserved (was ECDSA signatures) > > so it is clear that nobody knows how those should be implemented... > > ---------------------------------------------------------------------- > > > 2) I've added the draft ietf-ipsec-ike-ecc-groups to ipsec-registry. > > I then noticed that the document also requests the following values > > as described in Table 2 in the IANA Considerations section: > > > > 6 EC2NGF163Random2 > > 7 EC2NGF163Koblitz > > 8 EC2NGF283Random > > 9 EC2NGF283Koblitz > > 10 EC2NGF409Random > > 11 EC2NGF409Koblitz > > 12 EC2NGF571Random > > 13 EC2NGF571Koblitz > > These are from the > http://tools.ietf.org/html/draft-ietf-ipsec-ike-ecc-groups-04 version, > i.e. the registry was updated at some point in 2002 even when the > registry had registration policy of "RFC Required" and the document > was still draft (and was never published as RFC). > > I think you should remove "Panjwani" and "Blake-Wilson" and put > "ipsec-ike-ecc-groups" for all of them, and put some down a footnote > saying that the registry was updated too early and the draft never > made it to the RFC, but as these values might be used by some > implementations they are left there in the registry, but new > implementations should not use them. Also the reference could point > out that the values in the registry match the -04 version of the > document. > > > 22 ECPRGF192Random > > 23 EC2NGF163Random > > 24 ECPRGF224Random > > 25 EC2NGF233Random > > 26 EC2NGF233Koblitz > > These overlap with the already allocated other groups, so those should > not be added to the registry. > > > Question: are these, specifically 10-13 & 22-26, no longer required > > by ietf-ipsec-ike-ecc-groups? If we should leave them untouched, > > please let me know. > > The draft-ietf-ipsec-ike-ecc-groups document will most likely not be > going forward so adding the footnotes and comments to references might > be best. > > I did not yet check the isakmp-registry, I will do that later. > ~pearl From mark.boltz@stonesoft.com Wed Feb 8 08:26:22 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D070121F873C for ; Wed, 8 Feb 2012 08:26:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDe9c20QzDSO for ; Wed, 8 Feb 2012 08:26:22 -0800 (PST) Received: from hki-smtp-1a.stonesoft.com (hki-smtp-1a.stonesoft.com [192.89.38.178]) by ietfa.amsl.com (Postfix) with ESMTP id 6F12021F873D for ; Wed, 8 Feb 2012 08:26:08 -0800 (PST) Received: from hki-smtp-1a.stonesoft.com (localhost.localdomain [127.0.0.1]) by localhost.stonesoft.com (Postfix) with ESMTP id 2936D34814C; Wed, 8 Feb 2012 18:26:04 +0200 (EET) Received: from outlook.stonesoft.com (unknown [172.16.40.22]) by hki-smtp-1a.stonesoft.com (Postfix) with ESMTP id 1D223348147; Wed, 8 Feb 2012 18:26:04 +0200 (EET) Received: from HKI-EXC-1.stonesoft.com ([fe80::b914:799e:5fe4:7c73]) by HKI-EXC-2.stonesoft.com ([fe80::400e:df46:3369:4741%14]) with mapi id 14.01.0355.002; Wed, 8 Feb 2012 18:26:06 +0200 From: Mark Boltz To: "Ulliott, Chris" Thread-Topic: [IPsec] NUDGE: Starting work on our new charter items Thread-Index: AQHM3ROI6lryQc3iAUKRSHADDknCmZYmRyGAgAz7bek= Date: Wed, 8 Feb 2012 16:26:05 +0000 Message-ID: <383B3239-76E7-4960-8B1E-5A71F4B5AE52@stonesoft.com> References: <8CAC2292-8A17-4B38-B2DC-D8A4FDB43CEB@vpnc.org>, <20549DD10769DA47A86F0F0FAF8012DD031BF75CC0@PIACHEVEX00.GCHQ.GOV.UK> In-Reply-To: <20549DD10769DA47A86F0F0FAF8012DD031BF75CC0@PIACHEVEX00.GCHQ.GOV.UK> Accept-Language: en-US, fi-FI Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] NUDGE: Starting work on our new charter items X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 16:26:22 -0000 I will volunteer to help review the drafts and develop the requirements. Ho= w should we approach that sharing? Google, this list, something else? Also,= could someone (re-)post the charter with the objectives again, I can't see= m to find it. Alternatively send to me directly off list. I look forward to participating. -- Mark Boltz, CISSP, CISA, NSA-IEM, CSGI Director, Federal and Mid-Atlantic e: mark.boltz@stonesoft.com e: federal@stonesoft.com=20 p: 866.869.4075 c: 571.246.2233 o: 202.434.8963 f: 703.997.4759 w: http://www.stonesoft.com 1200 G St. NW, Suite 800 Washington, DC 20005-6705 Stonesoft: Network Security. Simplified. On Jan 31, 2012, at 7:12 AM, "Ulliott, Chris" wrote: > Paul - count me in, am more than happy to contribute and help review draf= ts. Unfortunately getting to Paris could be challenging, but I'll go and t= alk nicely to the folk who control the purse strings! >=20 > Chris >=20 > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of= Paul Hoffman > Sent: Friday, January 27, 2012 4:49 PM > To: IPsecme WG > Subject: [IPsec] NUDGE: Starting work on our new charter items >=20 > [[ There has not been enough response yet, by far. ]] >=20 > We have a new charter. Do we have any volunteers to start work on the two= documents we committed to work on? >=20 > Related: we should consider having a face-to-face meeting at the upcoming= IETF in Paris, but only if there is value for the newly-chartered work. In= my mind, that means both a first draft submitted *and* interesting questio= ns that would benefit from face-to-face discussion instead of just work on = the list. Do people believe we will have that? >=20 > --Paul Hoffman >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > *************************************************************************= *** > Communications with GCHQ may be monitored and/or recorded=20 > for system efficiency and other lawful purposes. Any views or=20 > opinions expressed in this e-mail do not necessarily reflect GCHQ=20 > policy. This email, and any attachments, is intended for the=20 > attention of the addressee(s) only. Its unauthorised use,=20 > disclosure, storage or copying is not permitted. If you are not the > intended recipient, please notify postmaster@gchq.gsi.gov.uk. =20 >=20 > This information is exempt from disclosure under the Freedom of=20 > Information Act 2000 and may be subject to exemption under > other UK information legislation. Refer disclosure requests to=20 > GCHQ on 01242 221491 ext 30306 (non-secure) or email > infoleg@gchq.gsi.gov.uk >=20 > *************************************************************************= *** >=20 >=20 > The original of this email was scanned for viruses by the Government Secu= re Intranet virus scanning service supplied by Cable&Wireless Worldwide in = partnership with MessageLabs. (CCTM Certificate Number 2009/09/0052.) On le= aving the GSi this email was certified virus free. > Communications via the GSi may be automatically logged, monitored and/or = recorded for legal purposes. > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From yaronf.ietf@gmail.com Wed Feb 8 08:32:20 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC74021F8795 for ; Wed, 8 Feb 2012 08:32:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.855 X-Spam-Level: X-Spam-Status: No, score=-102.855 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJlrf+KhLOvg for ; Wed, 8 Feb 2012 08:32:19 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 12B4C21F86B7 for ; Wed, 8 Feb 2012 08:32:18 -0800 (PST) Received: by bkuw12 with SMTP id w12so846937bku.31 for ; Wed, 08 Feb 2012 08:32:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=6oWCH9QbKJrZUBT+UHDgQ8LAo/EP7k2h6ckXLtPzujw=; b=rR8mzmRp/PIt/OtbThIvfj6eRbsSxYFeYOP7NMHciKlanRNRYxoHJ0IIwjFxQQTIrV T+pjrxrkOj8SBmupAOdij1icxw9gYX2b3ErhtxWHVbgdMlYIQEtCXsa001VGAbZc3NRt ITRnAqVGy1emvwEKnmm12hEEA6qLwdHIo85xk= Received: by 10.205.124.130 with SMTP id go2mr12988380bkc.66.1328718738182; Wed, 08 Feb 2012 08:32:18 -0800 (PST) Received: from [10.0.0.6] (bzq-79-177-156-198.red.bezeqint.net. [79.177.156.198]) by mx.google.com with ESMTPS id cz3sm6078404bkb.3.2012.02.08.08.32.16 (version=SSLv3 cipher=OTHER); Wed, 08 Feb 2012 08:32:17 -0800 (PST) Message-ID: <4F32A38F.9070104@gmail.com> Date: Wed, 08 Feb 2012 18:32:15 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Mark Boltz References: <8CAC2292-8A17-4B38-B2DC-D8A4FDB43CEB@vpnc.org>, <20549DD10769DA47A86F0F0FAF8012DD031BF75CC0@PIACHEVEX00.GCHQ.GOV.UK> <383B3239-76E7-4960-8B1E-5A71F4B5AE52@stonesoft.com> In-Reply-To: <383B3239-76E7-4960-8B1E-5A71F4B5AE52@stonesoft.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG , "Ulliott, Chris" , Paul Hoffman Subject: Re: [IPsec] NUDGE: Starting work on our new charter items X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 16:32:21 -0000 Hi Mark, the normal IETF way to review documents is on this list. If you want to review earlier pre-published drafts of the problem statement, please approach Steve Hanna privately. In any case, thanks for your participation! For the charter: http://datatracker.ietf.org/wg/ipsecme/charter/ Yaron On 02/08/2012 06:26 PM, Mark Boltz wrote: > I will volunteer to help review the drafts and develop the requirements. How should we approach that sharing? Google, this list, something else? Also, could someone (re-)post the charter with the objectives again, I can't seem to find it. Alternatively send to me directly off list. > > I look forward to participating. > > -- > Mark Boltz, CISSP, CISA, NSA-IEM, CSGI > Director, Federal and Mid-Atlantic > e: mark.boltz@stonesoft.com e: federal@stonesoft.com > p: 866.869.4075 c: 571.246.2233 > o: 202.434.8963 f: 703.997.4759 > w: http://www.stonesoft.com > > 1200 G St. NW, Suite 800 > Washington, DC 20005-6705 > > Stonesoft: Network Security. Simplified. > > On Jan 31, 2012, at 7:12 AM, "Ulliott, Chris" wrote: > >> Paul - count me in, am more than happy to contribute and help review drafts. Unfortunately getting to Paris could be challenging, but I'll go and talk nicely to the folk who control the purse strings! >> >> Chris >> >> -----Original Message----- >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Paul Hoffman >> Sent: Friday, January 27, 2012 4:49 PM >> To: IPsecme WG >> Subject: [IPsec] NUDGE: Starting work on our new charter items >> >> [[ There has not been enough response yet, by far. ]] >> >> We have a new charter. Do we have any volunteers to start work on the two documents we committed to work on? >> >> Related: we should consider having a face-to-face meeting at the upcoming IETF in Paris, but only if there is value for the newly-chartered work. In my mind, that means both a first draft submitted *and* interesting questions that would benefit from face-to-face discussion instead of just work on the list. Do people believe we will have that? >> >> --Paul Hoffman >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> **************************************************************************** >> Communications with GCHQ may be monitored and/or recorded >> for system efficiency and other lawful purposes. Any views or >> opinions expressed in this e-mail do not necessarily reflect GCHQ >> policy. This email, and any attachments, is intended for the >> attention of the addressee(s) only. Its unauthorised use, >> disclosure, storage or copying is not permitted. If you are not the >> intended recipient, please notify postmaster@gchq.gsi.gov.uk. >> >> This information is exempt from disclosure under the Freedom of >> Information Act 2000 and may be subject to exemption under >> other UK information legislation. Refer disclosure requests to >> GCHQ on 01242 221491 ext 30306 (non-secure) or email >> infoleg@gchq.gsi.gov.uk >> >> **************************************************************************** >> >> >> The original of this email was scanned for viruses by the Government Secure Intranet virus scanning service supplied by Cable&Wireless Worldwide in partnership with MessageLabs. (CCTM Certificate Number 2009/09/0052.) On leaving the GSi this email was certified virus free. >> Communications via the GSi may be automatically logged, monitored and/or recorded for legal purposes. >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From jcoronel@live.com Wed Feb 8 10:12:41 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A498D21F85A0 for ; Wed, 8 Feb 2012 10:12:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UDovM9+-FeZ for ; Wed, 8 Feb 2012 10:12:40 -0800 (PST) Received: from snt0-omc4-s20.snt0.hotmail.com (snt0-omc4-s20.snt0.hotmail.com [65.55.90.223]) by ietfa.amsl.com (Postfix) with ESMTP id 20F6621F84D7 for ; Wed, 8 Feb 2012 10:12:38 -0800 (PST) Received: from SNT115-W33 ([65.55.90.199]) by snt0-omc4-s20.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Feb 2012 10:12:37 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_207512bb-4e40-4e17-bb33-8255b219c8fd_" X-Originating-IP: [98.247.219.18] From: jorge coronel To: , Date: Wed, 8 Feb 2012 10:12:37 -0800 Importance: Normal In-Reply-To: <4F32A38F.9070104@gmail.com> References: <8CAC2292-8A17-4B38-B2DC-D8A4FDB43CEB@vpnc.org>, , <20549DD10769DA47A86F0F0FAF8012DD031BF75CC0@PIACHEVEX00.GCHQ.GOV.UK>, <383B3239-76E7-4960-8B1E-5A71F4B5AE52@stonesoft.com>, <4F32A38F.9070104@gmail.com> MIME-Version: 1.0 X-OriginalArrivalTime: 08 Feb 2012 18:12:37.0972 (UTC) FILETIME=[3D46A940:01CCE68D] Cc: ipsec@ietf.org, chris.ulliott@cesg.gsi.gov.uk, paul.hoffman@vpnc.org Subject: Re: [IPsec] NUDGE: Starting work on our new charter items X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 18:12:41 -0000 --_207512bb-4e40-4e17-bb33-8255b219c8fd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm also voluteering to help review the drafts and develop the requirements= .ThanksJorge CoronelMicrosoft Corp. > Date: Wed=2C 8 Feb 2012 18:32:15 +020= 0 > From: yaronf.ietf@gmail.com > To: mark.boltz@stonesoft.com > CC: ipsec@ietf.org=3B Chris.Ulliott@cesg.gsi.gov.uk=3B paul.hoffman@vpnc.= org > Subject: Re: [IPsec] NUDGE: Starting work on our new charter items >=20 > Hi Mark=2C >=20 > the normal IETF way to review documents is on this list. If you want to=20 > review earlier pre-published drafts of the problem statement=2C please=20 > approach Steve Hanna privately. In any case=2C thanks for your participat= ion! >=20 > For the charter: http://datatracker.ietf.org/wg/ipsecme/charter/ >=20 > Yaron >=20 > On 02/08/2012 06:26 PM=2C Mark Boltz wrote: > > I will volunteer to help review the drafts and develop the requirements= . How should we approach that sharing? Google=2C this list=2C something els= e? Also=2C could someone (re-)post the charter with the objectives again=2C= I can't seem to find it. Alternatively send to me directly off list. > > > > I look forward to participating. > > > > -- > > Mark Boltz=2C CISSP=2C CISA=2C NSA-IEM=2C CSGI > > Director=2C Federal and Mid-Atlantic > > e: mark.boltz@stonesoft.com e: federal@stonesoft.com > > p: 866.869.4075 c: 571.246.2233 > > o: 202.434.8963 f: 703.997.4759 > > w: http://www.stonesoft.com > > > > 1200 G St. NW=2C Suite 800 > > Washington=2C DC 20005-6705 > > > > Stonesoft: Network Security. Simplified. > > > > On Jan 31=2C 2012=2C at 7:12 AM=2C "Ulliott=2C Chris" wrote: > > > >> Paul - count me in=2C am more than happy to contribute and help review= drafts. Unfortunately getting to Paris could be challenging=2C but I'll g= o and talk nicely to the folk who control the purse strings! > >> > >> Chris > >> > >> -----Original Message----- > >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf= Of Paul Hoffman > >> Sent: Friday=2C January 27=2C 2012 4:49 PM > >> To: IPsecme WG > >> Subject: [IPsec] NUDGE: Starting work on our new charter items > >> > >> [[ There has not been enough response yet=2C by far. ]] > >> > >> We have a new charter. Do we have any volunteers to start work on the = two documents we committed to work on? > >> > >> Related: we should consider having a face-to-face meeting at the upcom= ing IETF in Paris=2C but only if there is value for the newly-chartered wor= k. In my mind=2C that means both a first draft submitted *and* interesting = questions that would benefit from face-to-face discussion instead of just w= ork on the list. Do people believe we will have that? > >> > >> --Paul Hoffman > >> > >> _______________________________________________ > >> IPsec mailing list > >> IPsec@ietf.org > >> https://www.ietf.org/mailman/listinfo/ipsec > >> > >> **********************************************************************= ****** > >> Communications with GCHQ may be monitored and/or recorded > >> for system efficiency and other lawful purposes. Any views or > >> opinions expressed in this e-mail do not necessarily reflect GCHQ > >> policy. This email=2C and any attachments=2C is intended for the > >> attention of the addressee(s) only. Its unauthorised use=2C > >> disclosure=2C storage or copying is not permitted. If you are not the > >> intended recipient=2C please notify postmaster@gchq.gsi.gov.uk. > >> > >> This information is exempt from disclosure under the Freedom of > >> Information Act 2000 and may be subject to exemption under > >> other UK information legislation. Refer disclosure requests to > >> GCHQ on 01242 221491 ext 30306 (non-secure) or email > >> infoleg@gchq.gsi.gov.uk > >> > >> **********************************************************************= ****** > >> > >> > >> The original of this email was scanned for viruses by the Government S= ecure Intranet virus scanning service supplied by Cable&Wireless Worldwide = in partnership with MessageLabs. (CCTM Certificate Number 2009/09/0052.) On= leaving the GSi this email was certified virus free. > >> Communications via the GSi may be automatically logged=2C monitored an= d/or recorded for legal purposes. > >> _______________________________________________ > >> IPsec mailing list > >> IPsec@ietf.org > >> https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec = --_207512bb-4e40-4e17-bb33-8255b219c8fd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I'm also voluteering to help review the drafts and develop the requirements= .
Thanks
Jorge Coronel
Microsoft Corp.
 =3B
>=3B Date: Wed=2C 8 Feb 2012 18:32:15 +020= 0
>=3B From: yaronf.ietf@gmail.com
>=3B To: mark.boltz@stonesoft.= com
>=3B CC: ipsec@ietf.org=3B Chris.Ulliott@cesg.gsi.gov.uk=3B paul.h= offman@vpnc.org
>=3B Subject: Re: [IPsec] NUDGE: Starting work on our = new charter items
>=3B
>=3B Hi Mark=2C
>=3B
>=3B the = normal IETF way to review documents is on this list. If you want to
>= =3B review earlier pre-published drafts of the problem statement=2C please =
>=3B approach Steve Hanna privately. In any case=2C thanks for your p= articipation!
>=3B
>=3B For the charter: http://datatracker.ietf= .org/wg/ipsecme/charter/
>=3B
>=3B Yaron
>=3B
>=3B O= n 02/08/2012 06:26 PM=2C Mark Boltz wrote:
>=3B >=3B I will voluntee= r to help review the drafts and develop the requirements. How should we app= roach that sharing? Google=2C this list=2C something else? Also=2C could so= meone (re-)post the charter with the objectives again=2C I can't seem to fi= nd it. Alternatively send to me directly off list.
>=3B >=3B
>= =3B >=3B I look forward to participating.
>=3B >=3B
>=3B >= =3B --
>=3B >=3B Mark Boltz=2C CISSP=2C CISA=2C NSA-IEM=2C CSGI
&= gt=3B >=3B Director=2C Federal and Mid-Atlantic
>=3B >=3B e: mark.= boltz@stonesoft.com e: federal@stonesoft.com
>=3B >=3B p: 866.869.= 4075 c: 571.246.2233
>=3B >=3B o: 202.434.8963 = f: 703.997.4759
>=3B >=3B w: http://www.stonesoft.com
>= =3B >=3B
>=3B >=3B 1200 G St. NW=2C Suite 800
>=3B >=3B Was= hington=2C DC 20005-6705
>=3B >=3B
>=3B >=3B Stonesoft: Netwo= rk Security. Simplified.
>=3B >=3B
>=3B >=3B On Jan 31=2C 201= 2=2C at 7:12 AM=2C "Ulliott=2C Chris"<=3BChris.Ulliott@cesg.gsi.gov.uk>= =3B wrote:
>=3B >=3B
>=3B >=3B>=3B Paul - count me in=2C a= m more than happy to contribute and help review drafts. Unfortunately gett= ing to Paris could be challenging=2C but I'll go and talk nicely to the fol= k who control the purse strings!
>=3B >=3B>=3B
>=3B >=3B>= =3B Chris
>=3B >=3B>=3B
>=3B >=3B>=3B -----Original Messa= ge-----
>=3B >=3B>=3B From: ipsec-bounces@ietf.org [mailto:ipsec-b= ounces@ietf.org] On Behalf Of Paul Hoffman
>=3B >=3B>=3B Sent: Fri= day=2C January 27=2C 2012 4:49 PM
>=3B >=3B>=3B To: IPsecme WG
= >=3B >=3B>=3B Subject: [IPsec] NUDGE: Starting work on our new charte= r items
>=3B >=3B>=3B
>=3B >=3B>=3B [[ There has not been= enough response yet=2C by far. ]]
>=3B >=3B>=3B
>=3B >=3B&= gt=3B We have a new charter. Do we have any volunteers to start work on the= two documents we committed to work on?
>=3B >=3B>=3B
>=3B &g= t=3B>=3B Related: we should consider having a face-to-face meeting at the= upcoming IETF in Paris=2C but only if there is value for the newly-charter= ed work. In my mind=2C that means both a first draft submitted *and* intere= sting questions that would benefit from face-to-face discussion instead of = just work on the list. Do people believe we will have that?
>=3B >= =3B>=3B
>=3B >=3B>=3B --Paul Hoffman
>=3B >=3B>=3B
&= gt=3B >=3B>=3B _______________________________________________
>= =3B >=3B>=3B IPsec mailing list
>=3B >=3B>=3B IPsec@ietf.org>=3B >=3B>=3B https://www.ietf.org/mailman/listinfo/ipsec
>=3B= >=3B>=3B
>=3B >=3B>=3B **************************************= **************************************
>=3B >=3B>=3B Communication= s with GCHQ may be monitored and/or recorded
>=3B >=3B>=3B for sys= tem efficiency and other lawful purposes. Any views or
>=3B >=3B>= =3B opinions expressed in this e-mail do not necessarily reflect GCHQ
&g= t=3B >=3B>=3B policy. This email=2C and any attachments=2C is intended= for the
>=3B >=3B>=3B attention of the addressee(s) only. Its una= uthorised use=2C
>=3B >=3B>=3B disclosure=2C storage or copying is= not permitted. If you are not the
>=3B >=3B>=3B intended recipie= nt=2C please notify postmaster@gchq.gsi.gov.uk.
>=3B >=3B>=3B
&= gt=3B >=3B>=3B This information is exempt from disclosure under the Fre= edom of
>=3B >=3B>=3B Information Act 2000 and may be subject to e= xemption under
>=3B >=3B>=3B other UK information legislation. Ref= er disclosure requests to
>=3B >=3B>=3B GCHQ on 01242 221491 ext 3= 0306 (non-secure) or email
>=3B >=3B>=3B infoleg@gchq.gsi.gov.uk>=3B >=3B>=3B
>=3B >=3B>=3B ******************************= **********************************************
>=3B >=3B>=3B
&g= t=3B >=3B>=3B
>=3B >=3B>=3B The original of this email was sca= nned for viruses by the Government Secure Intranet virus scanning service s= upplied by Cable&=3BWireless Worldwide in partnership with MessageLabs. = (CCTM Certificate Number 2009/09/0052.) On leaving the GSi this email was c= ertified virus free.
>=3B >=3B>=3B Communications via the GSi may = be automatically logged=2C monitored and/or recorded for legal purposes.>=3B >=3B>=3B _______________________________________________
>= =3B >=3B>=3B IPsec mailing list
>=3B >=3B>=3B IPsec@ietf.org>=3B >=3B>=3B https://www.ietf.org/mailman/listinfo/ipsec
>=3B= >=3B _______________________________________________
>=3B >=3B IP= sec mailing list
>=3B >=3B IPsec@ietf.org
>=3B >=3B https://w= ww.ietf.org/mailman/listinfo/ipsec
>=3B ______________________________= _________________
>=3B IPsec mailing list
>=3B IPsec@ietf.org
= >=3B https://www.ietf.org/mailman/listinfo/ipsec
= --_207512bb-4e40-4e17-bb33-8255b219c8fd_-- From yaronf.ietf@gmail.com Thu Feb 9 09:59:52 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC28121E8021 for ; Thu, 9 Feb 2012 09:59:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.836 X-Spam-Level: X-Spam-Status: No, score=-102.836 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RECV_BEZEQINT_B=0.763, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkNg3PYigRMl for ; Thu, 9 Feb 2012 09:59:51 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id D64DF21E8014 for ; Thu, 9 Feb 2012 09:59:50 -0800 (PST) Received: by werm10 with SMTP id m10so1949225wer.31 for ; Thu, 09 Feb 2012 09:59:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=cybn8NKGVaO7u7xkLIWSmylcyuOij/RNddBbAzBAE64=; b=eMzFRg4UBO8uWPkogf5QCVcVBJb5VlZ1xqKJUaSs/SdYudJUREQ0oINJOQqMxIwp4q IB55Ea6LaP00ZabSJ5pNcL4W4d8aKw7BnWs7IeF6bXvQ0EDUkNfWVLKHy62WkjghrCiV 7bVBN0l/TCJsHQ0Gqq1P7DejcL9zOZINgPV84= Received: by 10.180.19.97 with SMTP id d1mr4386585wie.12.1328810388520; Thu, 09 Feb 2012 09:59:48 -0800 (PST) Received: from [192.168.3.141] (bzq-218-164-247.red.bezeqint.net. [81.218.164.247]) by mx.google.com with ESMTPS id da8sm8225213wib.6.2012.02.09.09.59.46 (version=SSLv3 cipher=OTHER); Thu, 09 Feb 2012 09:59:48 -0800 (PST) Message-ID: <4F340992.5030502@gmail.com> Date: Thu, 09 Feb 2012 19:59:46 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: iana-matrix@iana.org References: <20162.16194.361337.415232@fireball.kivinen.iki.fi> <20235.3284.301719.250098@fireball.kivinen.iki.fi> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, turners@ieca.com, liang@icann.org, kivinen@iki.fi, stephen.farrell@cs.tcd.ie Subject: Re: [IPsec] [IANA #111200] [old message] Possible update to isakmp-registry X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 17:59:52 -0000 Hi Pearl, Tero, Regarding the first change (IPsec Auth Methods), I prefer the existing language. Even though IKEv1 has been obsoleted, I think change control of this central piece of the protocol needs to still require a higher bar than just "specification required". I'm afraid my co-chair disagrees, but he can surely speak for himself... Thanks, Yaron On 02/08/2012 04:07 AM, Pearl Liang via RT wrote: > Hi, Tero, > > This is very useful information. I've revised the ipsec-registry to > include your edits (included below). Though I have a few remaining > questions: > > - For Registry Name: IPSEC Authentication Methods (Value 3) >> Registry Name: IPSEC Authentication Methods (Value 3) >> Current: Standards-track RFC >> >> There is nothing about this in the RFC2409, so I would say either "RFC >> required" or "Specification required" would be ok. There is draft >> http://tools.ietf.org/html/draft-harkins-ike-iana-update-00 already >> proposing this change. > > Question1: since a new document is in work to update this, > the registration procedures will be updated when the document is made > to IETF Last call. Would it be okay to not change the listed > registration procedures at this time? > > - For Registry Name: PRF (Value 13) >> Registry Name: PRF (Value 13) >> Current: Standards-track or Informational RFC >> >> There is nothing about this in the RFC2409, so I would say either "RFC >> required" or "Specification required" would be ok. >> > > Question2: Would it be sufficient to list "RFC required" only? > > - For these 'early assignment' registrations as per ietf-ipsec-ike-ecc-groups, > you commented the following: > >>> 6 EC2NGF163Random2 >>> 7 EC2NGF163Koblitz >>> 8 EC2NGF283Random >>> 9 EC2NGF283Koblitz >>> 10 EC2NGF409Random >>> 11 EC2NGF409Koblitz >>> 12 EC2NGF571Random >>> 13 EC2NGF571Koblitz >> >> These are from the >> http://tools.ietf.org/html/draft-ietf-ipsec-ike-ecc-groups-04 version, >> i.e. the registry was updated at some point in 2002 even when the >> registry had registration policy of "RFC Required" and the document >> was still draft (and was never published as RFC). >> >> I think you should remove "Panjwani" and "Blake-Wilson" and put >> "ipsec-ike-ecc-groups" for all of them, and put some down a footnote >> saying that the registry was updated too early and the draft never >> made it to the RFC, but as these values might be used by some >> implementations they are left there in the registry, but new >> implementations should not use them. Also the reference could point >> out that the values in the registry match the -04 version of the >> document. > > [pl] I have removed the version number from the draft string. (I was > unable to locate those assignments (e.g. EC2NGF163Random2) in version 4.) > I have also remove both "Panjwani" and "Blake-Wilson" from the registry. > I have also marked the draft-ipsec-ike-ecc-group as expired in > the registry since it has never made it to an RFC. > Regarding the footnote, I've drafted something as follows: > > [[ > Note: these values were reserved as per draft-ipsec-ike-ecc-groups which > never made it to the RFC. These values might be used by some > implementations as currently registered in the registry, but new > implementations should not use them. > ]] > > Question: does the above look okay? Please comment. When I receive > your edits, I will add the "Note" to the registry. > > Please see: http://www.iana.org/assignments/ipsec-registry > > When you have updates for the isakmp-registry, please send them > to us. > > Thank you again for your help, > ~pearl > > > On Mon Jan 09 08:24:39 2012, kivinen@iki.fi wrote: >> [I CCed the ipsec@ietf.org list, as this changes the registration >> policies, and we have already had some discussion about this earlier >> on the list and other people there might also have their opinion about >> the matter.] >> >> Pearl Liang via RT writes: >>> 1) What are the registration procedures for these sub-registries >>> listed in http://www.iana.org/assignments/ipsec-registry: >>> >>> - Exchange Type >>> - Additional Exchanges Defined-- XCHG values >>> - Next Payload Types >>> - Notify Message Types >>> - Notify Messages - Error Types (1-8191) >>> - Notify Messages - Status Types (16384-24575) >>> >>> ? I would like to update "Not defined" if possible. >> >> For most of those it is not defined... I.e the original RFC does not >> specify any registration procedures for them (or for some other >> registries we have there). >> >> I would most likely think it would be best to put them as >> "Specification required" or "RFC required". >> >> Actually I think we should go through the RFC2407-2409 and see from >> there for which registries they do specify any registration policies, >> and use those values for only those registries and put everything else >> as "Specification required" or "RFC Required". >> >> ---------------------------------------------------------------------- >> >> Registry Name: Attribute Classes >> Current: Standards-track RFC >> RFC2409: 11.1 Attribute Classes >> >> Attributes negotiated in this protocol are identified by their class. >> Requests for assignment of new classes must be accompanied by a >> standards-track RFC which describes the use of this attribute. >> >> -> Standards-track RFC, already OK >> >> ---------------------------------------------------------------------- >> >> Registry Name: Encryption Algorithm Class Values (Value 1) >> Current: Standards-track or Informational RFC >> RFC2409: 11.2 Encryption Algorithm Class >> >> Values of the Encryption Algorithm Class define an encryption >> algorithm to use when called for in this document. Requests for >> assignment of new encryption algorithm values must be accompanied by >> a reference to a standards-track or Informational RFC or a reference >> to published cryptographic literature which describes this algorithm. >> >> -> Specification required, currently this is Standards-track or >> Informational RFC, but I think Specification required is closer to >> what the RFC says about "a reference to published cryptographic >> literature". >> >> ---------------------------------------------------------------------- >> >> Registry Name: Hash Algorithm (Value 2) >> Current: Standards-track or Informational RFC >> RFC2409: 11.3 Hash Algorithm >> >> Values of the Hash Algorithm Class define a hash algorithm to use >> when called for in this document. Requests for assignment of new hash >> algorithm values must be accompanied by a reference to a standards- >> track or Informational RFC or a reference to published cryptographic >> literature which describes this algorithm. Due to the key derivation >> and key expansion uses of HMAC forms of hash algorithms in IKE, >> requests for assignment of new hash algorithm values must take into >> account the cryptographic properties-- e.g it's resistance to >> collision-- of the hash algorithm itself. >> >> -> Specification required, see above. >> >> ---------------------------------------------------------------------- >> >> Registry Name: IPSEC Authentication Methods (Value 3) >> Current: Standards-track RFC >> >> There is nothing about this in the RFC2409, so I would say either "RFC >> required" or "Specification required" would be ok. There is draft >> http://tools.ietf.org/html/draft-harkins-ike-iana-update-00 already >> proposing this change. >> >> ---------------------------------------------------------------------- >> >> Registry Name: Group Description (Value 4) >> Current: Standards-track or Informational RFC >> Registry Name: Group Type (Value 5) >> Current: Standards-track or Informational RFC >> RFC2409: 11.4 Group Description and Group Type >> >> Values of the Group Description Class identify a group to use in a >> Diffie-Hellman exchange. Values of the Group Type Class define the >> type of group. Requests for assignment of new groups must be >> accompanied by a reference to a standards-track or Informational RFC >> which describes this group. Requests for assignment of new group >> types must be accompanied by a reference to a standards-track or >> Informational RFC or by a reference to published cryptographic or >> mathmatical literature which describes the new type. >> >> Group Description (Value 4) -> RFC required >> Group Type (Value 5) -> Specification required >> >> ---------------------------------------------------------------------- >> >> Registry Name: Life Type (Value 11) >> Current: Specification Required >> RFC2409: 11.5 Life Type >> >> Values of the Life Type Class define a type of lifetime to which the >> ISAKMP Security Association applies. Requests for assignment of new >> life types must be accompanied by a detailed description of the units >> of this type and its expiry. >> >> -> Hmm... this is vague, I would expect it means "Specification >> required", so ok already. >> >> ---------------------------------------------------------------------- >> >> Registry Name: PRF (Value 13) >> Current: Standards-track or Informational RFC >> >> There is nothing about this in the RFC2409, so I would say either "RFC >> required" or "Specification required" would be ok. >> >> ---------------------------------------------------------------------- >> >> Registry Name: Exchange Type >> Current: Not defined >> >> There is nothing in RFC2409/RFC2408. There has not been additions to >> this, and I do not expect there to be one (as all new stuff should be >> done on the protocol which obsoleted this one). I would say "Standards >> Action" would most likely be best for this. >> >> ---------------------------------------------------------------------- >> >> Registry Name: Additional Exchanges Defined-- XCHG values >> Current: Not defined >> >> There is nothing in RFC2409/RFC2408. Same as above -> "Standards >> Action". >> >> ---------------------------------------------------------------------- >> >> Registry Name: ISAKMP Domain of Interpretation (DOI) >> Current: Standards-track RFC >> RFC2408: Domain of Interpretation >> >> The Domain of Interpretation (DOI) is a 32-bit field which identifies >> the domain under which the security association negotiation is taking >> place. Requests for assignments of new DOIs must be accompanied by a >> standards-track RFC which describes the specific domain. >> >> -> "Standards action" (i.e. Standards-track RFC) >> >> ---------------------------------------------------------------------- >> >> Registry Name: Next Payload Types >> Current: Internet Draft >> >> There is nothing in RFC2409/RFC2408. There has been more of these, so >> "RFC required", I think Internet Draft is bit too low, and not >> matching the RFC5226 usages. >> >> ---------------------------------------------------------------------- >> >> Registry Name: Notify Message Types >> Current: Not defined >> Sub-registry: Notify Messages - Error Types (1-8191) >> Current: Not defined >> Sub-Registry: Notify Messages - Status Types (16384-24575) >> Current: Not defined >> >> No additions to these registries, but these are large registries, so >> perhaps "RFC required". >> >> ---------------------------------------------------------------------- >> >> There is a problem in the "IPSEC Authentication Methods (Value 3)" as >> there is 3 values which do not have any real specification, i.e. >> >> 6 Encryption with El-Gamal >> 7 Revised encryption with El-Gamal >> 8 ECDSA signatures [Fahn] >> >> As there is no reference to any document or anything, I have no idea >> how anybody could actually implement those in interoperable manner. I >> would suggest changing those to: >> >> 6 Reserved (was Encryption with El-Gamal) >> 7 Reserved (was Revised encryption with El-Gamal) >> 8 Reserved (was ECDSA signatures) >> >> so it is clear that nobody knows how those should be implemented... >> >> ---------------------------------------------------------------------- >> >>> 2) I've added the draft ietf-ipsec-ike-ecc-groups to ipsec-registry. >>> I then noticed that the document also requests the following values >>> as described in Table 2 in the IANA Considerations section: >>> >>> 6 EC2NGF163Random2 >>> 7 EC2NGF163Koblitz >>> 8 EC2NGF283Random >>> 9 EC2NGF283Koblitz >>> 10 EC2NGF409Random >>> 11 EC2NGF409Koblitz >>> 12 EC2NGF571Random >>> 13 EC2NGF571Koblitz >> >> These are from the >> http://tools.ietf.org/html/draft-ietf-ipsec-ike-ecc-groups-04 version, >> i.e. the registry was updated at some point in 2002 even when the >> registry had registration policy of "RFC Required" and the document >> was still draft (and was never published as RFC). >> >> I think you should remove "Panjwani" and "Blake-Wilson" and put >> "ipsec-ike-ecc-groups" for all of them, and put some down a footnote >> saying that the registry was updated too early and the draft never >> made it to the RFC, but as these values might be used by some >> implementations they are left there in the registry, but new >> implementations should not use them. Also the reference could point >> out that the values in the registry match the -04 version of the >> document. >> >>> 22 ECPRGF192Random >>> 23 EC2NGF163Random >>> 24 ECPRGF224Random >>> 25 EC2NGF233Random >>> 26 EC2NGF233Koblitz >> >> These overlap with the already allocated other groups, so those should >> not be added to the registry. >> >>> Question: are these, specifically 10-13& 22-26, no longer required >>> by ietf-ipsec-ike-ecc-groups? If we should leave them untouched, >>> please let me know. >> >> The draft-ietf-ipsec-ike-ecc-groups document will most likely not be >> going forward so adding the footnotes and comments to references might >> be best. >> >> I did not yet check the isakmp-registry, I will do that later. >> > > ~pearl > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From paul.hoffman@vpnc.org Thu Feb 9 10:10:41 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCDAB21F86F6 for ; Thu, 9 Feb 2012 10:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYG1XbQ0G3RZ for ; Thu, 9 Feb 2012 10:10:41 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC1A21F86DB for ; Thu, 9 Feb 2012 10:10:40 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q19IA2GE098675 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Feb 2012 11:10:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4F340992.5030502@gmail.com> Date: Thu, 9 Feb 2012 10:10:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <372E1EC3-5516-447F-AC27-89E584418135@vpnc.org> References: <20162.16194.361337.415232@fireball.kivinen.iki.fi> <20235.3284.301719.250098@fireball.kivinen.iki.fi> <4F340992.5030502@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.1257) Cc: liang@icann.org, kivinen@iki.fi, ipsec@ietf.org, iana-matrix@iana.org, turners@ieca.com, stephen.farrell@cs.tcd.ie Subject: Re: [IPsec] [IANA #111200] [old message] Possible update to isakmp-registry X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 18:10:42 -0000 On Feb 9, 2012, at 9:59 AM, Yaron Sheffer wrote: > Hi Pearl, Tero, >=20 > Regarding the first change (IPsec Auth Methods), I prefer the existing = language. Even though IKEv1 has been obsoleted, I think change control = of this central piece of the protocol needs to still require a higher = bar than just "specification required". >=20 > I'm afraid my co-chair disagrees, but he can surely speak for = himself... I do, and I can. The overhead of requiring IETF and RFC Editor process = for extensions to a popular-but-obsolete protocol is not worth it. If = someone publishes a new authentication mechanism for IKEv1 that has = significant flaws (and they certainly will), they publish a new document = and it gets a new identifier. This will damp out fairly quickly, and = auth mechanism developers will get more input before publishing. --Paul Hoffman From kivinen@iki.fi Fri Feb 10 05:16:30 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E73521F86EF for ; Fri, 10 Feb 2012 05:16:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pT7AaEmHtn6A for ; Fri, 10 Feb 2012 05:16:28 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB3421F86B8 for ; Fri, 10 Feb 2012 05:16:27 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id q1ADDG8V019092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Feb 2012 15:13:16 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id q1ADDFJ1016109; Fri, 10 Feb 2012 15:13:15 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20277.6123.754992.433923@fireball.kivinen.iki.fi> Date: Fri, 10 Feb 2012 15:13:15 +0200 From: Tero Kivinen To: iana-matrix@iana.org In-Reply-To: References: <20162.16194.361337.415232@fireball.kivinen.iki.fi> <20235.3284.301719.250098@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 12 min X-Total-Time: 15 min Cc: ipsec@ietf.org, turners@ieca.com, liang@icann.org, stephen.farrell@cs.tcd.ie Subject: [IPsec] [IANA #111200] [old message] Possible update to isakmp-registry X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 13:16:30 -0000 Pearl Liang via RT writes: > - For Registry Name: IPSEC Authentication Methods (Value 3) > > Registry Name: IPSEC Authentication Methods (Value 3) > > Current: Standards-track RFC > > > > There is nothing about this in the RFC2409, so I would say either "RFC > > required" or "Specification required" would be ok. There is draft > > http://tools.ietf.org/html/draft-harkins-ike-iana-update-00 already > > proposing this change. > > Question1: since a new document is in work to update this, > the registration procedures will be updated when the document is made > to IETF Last call. Would it be okay to not change the listed > registration procedures at this time? As there seems to be different opinions about this in the IPsecME WG, I think it might be better to leave this for now, and then we can work on that issue by using the draft-harkins-ike-iana-update document as our placeholder. I myself do think that as the current Standards-track RFC requirement is not mentioned in any RFCs, we do not necessarely need RFC to change it (and I think publishing RFC just to change one unspecified registration policy is not really needed). On the other hand we do need to have concencus on the issue among the working group, so after we reach that, we can come back to you, regardless whether we publish separate document about that issue or not (which is separate issue we need to decide). So leave it as it is for now, and we work on this issue in the IPsecME WG. > - For Registry Name: PRF (Value 13) > > Registry Name: PRF (Value 13) > > Current: Standards-track or Informational RFC > > > > There is nothing about this in the RFC2409, so I would say either "RFC > > required" or "Specification required" would be ok. > > > > Question2: Would it be sufficient to list "RFC required" only? Yes that would also be acceptable, but "Specification required" would be more inline with other cryptographic algorithms specified in the RFC2409 (encryption algorithm, hash algorithm etc), so I would prefer "Specification required". The exact text in RFC2409 for similar registries is: Requests for assignment of new encryption algorithm values must be accompanied by a reference to a standards-track or Informational RFC or a reference to published cryptographic literature which describes this algorithm. > - For these 'early assignment' registrations as per > ietf-ipsec-ike-ecc-groups, you commented the following: > > > > 6 EC2NGF163Random2 > > > 7 EC2NGF163Koblitz > > > 8 EC2NGF283Random > > > 9 EC2NGF283Koblitz > > > 10 EC2NGF409Random > > > 11 EC2NGF409Koblitz > > > 12 EC2NGF571Random > > > 13 EC2NGF571Koblitz > > > > These are from the > > http://tools.ietf.org/html/draft-ietf-ipsec-ike-ecc-groups-04 version, > > i.e. the registry was updated at some point in 2002 even when the > > registry had registration policy of "RFC Required" and the document > > was still draft (and was never published as RFC). > > > > I think you should remove "Panjwani" and "Blake-Wilson" and put > > "ipsec-ike-ecc-groups" for all of them, and put some down a footnote > > saying that the registry was updated too early and the draft never > > made it to the RFC, but as these values might be used by some > > implementations they are left there in the registry, but new > > implementations should not use them. Also the reference could point > > out that the values in the registry match the -04 version of the > > document. > > [pl] I have removed the version number from the draft string. (I was > unable to locate those assignments (e.g. EC2NGF163Random2) in version 4.) > I have also remove both "Panjwani" and "Blake-Wilson" from the registry. > I have also marked the draft-ipsec-ike-ecc-group as expired in > the registry since it has never made it to an RFC. > Regarding the footnote, I've drafted something as follows: > > [[ > Note: these values were reserved as per draft-ipsec-ike-ecc-groups which > never made it to the RFC. These values might be used by some > implementations as currently registered in the registry, but new > implementations should not use them. > ]] > > Question: does the above look okay? Please comment. When I receive > your edits, I will add the "Note" to the registry. That note seems to be ok. > Please see: http://www.iana.org/assignments/ipsec-registry Your changes seem to be ok. BTW, is there any way to get diffs to the registries, in the same way you can get diffs to the drafts. It would be useful when checking out what has changed in the registry and when. Do you keep old versions of the registries and if so, is there a way to fetch those using http so I could use rfcdiff (or wdiff, or make separate tool for that) to make side by side diffs of the registries. > When you have updates for the isakmp-registry, please send them > to us. I will come back when I have time to go through that one. -- kivinen@iki.fi From kivinen@iki.fi Fri Feb 10 05:23:08 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7EE21F8615 for ; Fri, 10 Feb 2012 05:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGxLWe-GZQ+l for ; Fri, 10 Feb 2012 05:23:07 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5560D21F8609 for ; Fri, 10 Feb 2012 05:23:05 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id q1ADN2Ac024314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Feb 2012 15:23:02 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id q1ADN1vj015564; Fri, 10 Feb 2012 15:23:01 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20277.6709.732929.527261@fireball.kivinen.iki.fi> Date: Fri, 10 Feb 2012 15:23:01 +0200 From: Tero Kivinen To: Paul Hoffman In-Reply-To: <372E1EC3-5516-447F-AC27-89E584418135@vpnc.org> References: <20162.16194.361337.415232@fireball.kivinen.iki.fi> <20235.3284.301719.250098@fireball.kivinen.iki.fi> <4F340992.5030502@gmail.com> <372E1EC3-5516-447F-AC27-89E584418135@vpnc.org> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 10 min X-Total-Time: 9 min Cc: ipsec@ietf.org Subject: Re: [IPsec] [IANA #111200] [old message] Possible update to isakmp-registry X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 13:23:08 -0000 [Removed iana etc from the CC list, as there is no point of keeping them spammed by our WG discussion, I will contact back to them when we have some kind of resolution about this.] Paul Hoffman writes: > On Feb 9, 2012, at 9:59 AM, Yaron Sheffer wrote: > > > Hi Pearl, Tero, > > > > Regarding the first change (IPsec Auth Methods), I prefer the > > existing language. Even though IKEv1 has been obsoleted, I think > > change control of this central piece of the protocol needs to > > still require a higher bar than just "specification required". > > > > I'm afraid my co-chair disagrees, but he can surely speak for himself... > > I do, and I can. The overhead of requiring IETF and RFC Editor > process for extensions to a popular-but-obsolete protocol is not > worth it. If someone publishes a new authentication mechanism for > IKEv1 that has significant flaws (and they certainly will), they > publish a new document and it gets a new identifier. This will damp > out fairly quickly, and auth mechanism developers will get more > input before publishing. I think I agree with Paul, but I am not completely sure I understood what he was saying above... :-) Anyways, I think Specification required should be enough for that registry. Other option would really be "Obsoleted protocol, no allocations allowed", but that would upset even more people... I do not really see that much point of requiring people to try to get standard track RFC out just to update the registry, when otherwise the document could be informational or just specified in some other standards body etc. The end result will most likely going to be that people pick number and start using it without bothering to allocate number for it all, if the allocating number is too hard. And getting standards track document to update already obsoleted protocol is going to get other people complaining (including me). As this is the last item in the iana ipsec-registry cleanup, I would like to get this to agenda for example for the Paris meeting and discuss this there and make decision (one way or other) and solve this after the Paris meeting. So my question to working group chairs, would that be ok to discuss this in Paris IETF meeting (depending of course whether we have session there or not), and I would like people to hear any other comments about this here in the mailing list anyways. -- kivinen@iki.fi From yaronf.ietf@gmail.com Fri Feb 10 12:13:31 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F6021F88B2 for ; Fri, 10 Feb 2012 12:13:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.227 X-Spam-Level: X-Spam-Status: No, score=-103.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0I7DJx7cJDAv for ; Fri, 10 Feb 2012 12:13:29 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6050721F8751 for ; Fri, 10 Feb 2012 12:13:29 -0800 (PST) Received: by eekc41 with SMTP id c41so1081940eek.31 for ; Fri, 10 Feb 2012 12:13:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=BjxTHtS8jJ93KJHwGOZj0GVmIOwLPWqeJqUUxECVMY4=; b=V4Do2Q1hkxYNdT7ZQ9L22F7EXmwrSYfKenSm0d/xODkiCa1EIO7wg3VuNO6z0RsMTT mgkc0m3yU880QwrUhNAvly0adBsQhg+fFv6P4F4ZfNok4rSW5ExTlFDP8Wu/q48HupHs hyI/fghfp6NIRrRE8CBqoFjHOSvKVrc09WcuM= Received: by 10.14.119.16 with SMTP id m16mr2452726eeh.124.1328904808492; Fri, 10 Feb 2012 12:13:28 -0800 (PST) Received: from [10.0.0.6] (bzq-79-177-151-176.red.bezeqint.net. [79.177.151.176]) by mx.google.com with ESMTPS id n58sm25880274een.10.2012.02.10.12.13.26 (version=SSLv3 cipher=OTHER); Fri, 10 Feb 2012 12:13:27 -0800 (PST) Message-ID: <4F357A65.20606@gmail.com> Date: Fri, 10 Feb 2012 22:13:25 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Paul Hoffman References: <20162.16194.361337.415232@fireball.kivinen.iki.fi> <20235.3284.301719.250098@fireball.kivinen.iki.fi> <4F340992.5030502@gmail.com> <372E1EC3-5516-447F-AC27-89E584418135@vpnc.org> In-Reply-To: <372E1EC3-5516-447F-AC27-89E584418135@vpnc.org> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, turners@ieca.com, kivinen@iki.fi, stephen.farrell@cs.tcd.ie Subject: Re: [IPsec] Possible update to isakmp-registry X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 20:13:31 -0000 Hi Paul, sorry, I don't understand your statement. Yes, IKEv1 is popular but (formally) obsolete. It is still our responsibility to ensure that it doesn't gain new and insecure extensions in its old age. The way we do it is through the normal IETF/RFC-Ed/IANA bureaucratic processes. Unlike Tero, I don't think people will be adding non-IETF extensions of this sort to IKEv1. New crypto algorithms, maybe. But new authentication methods? I'd be surprised. I'm fine with Tero's proposal to resolve this question in Paris. Thanks, Yaron On 02/09/2012 08:10 PM, Paul Hoffman wrote: > On Feb 9, 2012, at 9:59 AM, Yaron Sheffer wrote: > >> Hi Pearl, Tero, >> >> Regarding the first change (IPsec Auth Methods), I prefer the existing language. Even though IKEv1 has been obsoleted, I think change control of this central piece of the protocol needs to still require a higher bar than just "specification required". >> >> I'm afraid my co-chair disagrees, but he can surely speak for himself... > > I do, and I can. The overhead of requiring IETF and RFC Editor process for extensions to a popular-but-obsolete protocol is not worth it. If someone publishes a new authentication mechanism for IKEv1 that has significant flaws (and they certainly will), they publish a new document and it gets a new identifier. This will damp out fairly quickly, and auth mechanism developers will get more input before publishing. > > --Paul Hoffman > From paul.hoffman@vpnc.org Fri Feb 10 12:35:37 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9CC21F86D6 for ; Fri, 10 Feb 2012 12:35:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJzqYQKC6t2p for ; Fri, 10 Feb 2012 12:35:36 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 985A621F86CA for ; Fri, 10 Feb 2012 12:35:36 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1AKZSnh057746 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 10 Feb 2012 13:35:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1251 From: Paul Hoffman In-Reply-To: <4F357A65.20606@gmail.com> Date: Fri, 10 Feb 2012 12:35:27 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20162.16194.361337.415232@fireball.kivinen.iki.fi> <20235.3284.301719.250098@fireball.kivinen.iki.fi> <4F340992.5030502@gmail.com> <372E1EC3-5516-447F-AC27-89E584418135@vpnc.org> <4F357A65.20606@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.1257) Cc: ipsec@ietf.org, turners@ieca.com, kivinen@iki.fi, stephen.farrell@cs.tcd.ie Subject: Re: [IPsec] Possible update to isakmp-registry X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 20:35:37 -0000 On Feb 10, 2012, at 12:13 PM, Yaron Sheffer wrote: > sorry, I don't understand your statement. Yes, IKEv1 is popular but = (formally) obsolete. It is still our responsibility to ensure that it = doesn't gain new and insecure extensions in its old age. I think you understand my statement but simply disagree with it. :-) I = don't believe that is our responsibility, although we can certainly help = prevent it if the extension writers ask us. If an extension writer = creates an insecure extension, we can point that out, make fun of it on = the mailing list and in the press, and so on; it is not our = responsibility to prevent it for an obsolete protocol. > The way we do it is through the normal IETF/RFC-Ed/IANA bureaucratic = processes. Yes. > Unlike Tero, I don't think people will be adding non-IETF extensions = of this sort to IKEv1. New crypto algorithms, maybe. But new = authentication methods? I'd be surprised. We are often surprised. > I'm fine with Tero's proposal to resolve this question in Paris. I would rather hear much more before then, and maybe even come to = agreement. If we need to have a voice discussion, we could have an open = design team meeting related to this in a week or so. --Paul Hoffman From dharkins@lounge.org Fri Feb 10 14:45:16 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7008021F8526 for ; Fri, 10 Feb 2012 14:45:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.642 X-Spam-Level: X-Spam-Status: No, score=-5.642 tagged_above=-999 required=5 tests=[AWL=0.623, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdFtkadcJaLr for ; Fri, 10 Feb 2012 14:45:15 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 79D2D21F84EF for ; Fri, 10 Feb 2012 14:45:15 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id AA80A1022404C; Fri, 10 Feb 2012 14:45:14 -0800 (PST) Received: from 216.31.249.246 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 10 Feb 2012 14:45:15 -0800 (PST) Message-ID: <2fb6766614c157f89a461585dad59cc0.squirrel@www.trepanning.net> In-Reply-To: <4F357A65.20606@gmail.com> References: <20162.16194.361337.415232@fireball.kivinen.iki.fi> <20235.3284.301719.250098@fireball.kivinen.iki.fi> <4F340992.5030502@gmail.com> <372E1EC3-5516-447F-AC27-89E584418135@vpnc.org> <4F357A65.20606@gmail.com> Date: Fri, 10 Feb 2012 14:45:15 -0800 (PST) From: "Dan Harkins" To: "Yaron Sheffer" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: ipsec@ietf.org, turners@ieca.com, Paul Hoffman , kivinen@iki.fi, stephen.farrell@cs.tcd.ie Subject: Re: [IPsec] Possible update to isakmp-registry X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 22:45:16 -0000 On Fri, February 10, 2012 12:13 pm, Yaron Sheffer wrote: > Hi Paul, > > sorry, I don't understand your statement. Yes, IKEv1 is popular but > (formally) obsolete. It is still our responsibility to ensure that it > doesn't gain new and insecure extensions in its old age. The way we do > it is through the normal IETF/RFC-Ed/IANA bureaucratic processes. > > Unlike Tero, I don't think people will be adding non-IETF extensions of > this sort to IKEv1. New crypto algorithms, maybe. But new authentication > methods? I'd be surprised. SURPRISE! It's me. And I want to add a new authentication method to IKEv1. New, yes; insecure, no. In fact, it makes things _more_ secure because it obviates the need for insecure extensions that have been added to IKEv1 and widely implemented, like XAUTH, because it removes the requirement that a PSK be bound to an IP address and it is resistant to dictionary attack. (And now that I have mentioned this, will you be surprising yourself by proposing a new authentication method for IKEv1 that is resistant to dictionary attack?) Dan. From yaronf.ietf@gmail.com Sat Feb 11 05:02:48 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FEC921F8532 for ; Sat, 11 Feb 2012 05:02:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.351 X-Spam-Level: X-Spam-Status: No, score=-103.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ilbg-4F2TUu0 for ; Sat, 11 Feb 2012 05:02:47 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3F96321F852E for ; Sat, 11 Feb 2012 05:02:47 -0800 (PST) Received: by eekc41 with SMTP id c41so1246006eek.31 for ; Sat, 11 Feb 2012 05:02:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=gbsKDvxWTwSkDq7nei1ePFQCUA+9OZLxE1ftxkBSWQQ=; b=VsTCjwG8o0d7i16nWKL7J0y/g00UESAa8PcZB3+3/Rp0sDGMPvFlnjzTNUhbJi1qP5 17bFcWeqxag9pAjwvABqNK1/t87W14GdtHQeOdcwpcgaw6MpnJce5nZ9++wBHhtfpGhV IZxl66OV71Cq2p3Jq8pFBd4vsZjSQTNQ2LB4I= Received: by 10.213.33.72 with SMTP id g8mr1716205ebd.8.1328965366425; Sat, 11 Feb 2012 05:02:46 -0800 (PST) Received: from [10.0.0.6] (bzq-79-177-151-176.red.bezeqint.net. [79.177.151.176]) by mx.google.com with ESMTPS id c16sm35083043eei.1.2012.02.11.05.02.44 (version=SSLv3 cipher=OTHER); Sat, 11 Feb 2012 05:02:45 -0800 (PST) Message-ID: <4F3666F2.70004@gmail.com> Date: Sat, 11 Feb 2012 15:02:42 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Dan Harkins References: <20162.16194.361337.415232@fireball.kivinen.iki.fi> <20235.3284.301719.250098@fireball.kivinen.iki.fi> <4F340992.5030502@gmail.com> <372E1EC3-5516-447F-AC27-89E584418135@vpnc.org> <4F357A65.20606@gmail.com> <2fb6766614c157f89a461585dad59cc0.squirrel@www.trepanning.net> In-Reply-To: <2fb6766614c157f89a461585dad59cc0.squirrel@www.trepanning.net> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, turners@ieca.com, Paul Hoffman , kivinen@iki.fi, stephen.farrell@cs.tcd.ie Subject: Re: [IPsec] Possible update to isakmp-registry X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2012 13:02:48 -0000 Hi Dan, No surprise at all - I used the term "non-IETF extension". As long as your extension goes through proper IETF process/review, I'm fine with it. I might even support it, since I agree that it adds security to IKEv1/PSK. Other people might argue that we shouldn't confuse the industry by adding major new pieces to IKEv1. Thanks, Yaron On 02/11/2012 12:45 AM, Dan Harkins wrote: > > > On Fri, February 10, 2012 12:13 pm, Yaron Sheffer wrote: >> Hi Paul, >> >> sorry, I don't understand your statement. Yes, IKEv1 is popular but >> (formally) obsolete. It is still our responsibility to ensure that it >> doesn't gain new and insecure extensions in its old age. The way we do >> it is through the normal IETF/RFC-Ed/IANA bureaucratic processes. >> >> Unlike Tero, I don't think people will be adding non-IETF extensions of >> this sort to IKEv1. New crypto algorithms, maybe. But new authentication >> methods? I'd be surprised. > > SURPRISE! It's me. And I want to add a new authentication method > to IKEv1. New, yes; insecure, no. In fact, it makes things _more_ secure > because it obviates the need for insecure extensions that have been added > to IKEv1 and widely implemented, like XAUTH, because it removes the > requirement that a PSK be bound to an IP address and it is resistant to > dictionary attack. > > (And now that I have mentioned this, will you be surprising yourself > by proposing a new authentication method for IKEv1 that is resistant to > dictionary attack?) > > Dan. > > From kivinen@iki.fi Sun Feb 12 08:35:03 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE59C21F8795 for ; Sun, 12 Feb 2012 08:35:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggMq+LBXzmkQ for ; Sun, 12 Feb 2012 08:35:02 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F5D21F8789 for ; Sun, 12 Feb 2012 08:34:55 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id q1CGYfI5015611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Feb 2012 18:34:42 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id q1CGYdi8019651; Sun, 12 Feb 2012 18:34:39 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20279.59935.562617.387762@fireball.kivinen.iki.fi> Date: Sun, 12 Feb 2012 18:34:39 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <4F3666F2.70004@gmail.com> References: <20162.16194.361337.415232@fireball.kivinen.iki.fi> <20235.3284.301719.250098@fireball.kivinen.iki.fi> <4F340992.5030502@gmail.com> <372E1EC3-5516-447F-AC27-89E584418135@vpnc.org> <4F357A65.20606@gmail.com> <2fb6766614c157f89a461585dad59cc0.squirrel@www.trepanning.net> <4F3666F2.70004@gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 12 min X-Total-Time: 13 min Cc: ipsec@ietf.org, turners@ieca.com, stephen.farrell@cs.tcd.ie, Dan Harkins , Paul Hoffman Subject: Re: [IPsec] Possible update to isakmp-registry X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 16:35:03 -0000 Yaron Sheffer writes: > No surprise at all - I used the term "non-IETF extension". As long as > your extension goes through proper IETF process/review, I'm fine with > it. I might even support it, since I agree that it adds security to > IKEv1/PSK. Other people might argue that we shouldn't confuse the > industry by adding major new pieces to IKEv1. Does that mean thay you would accept "IETF Review", when allocating new authentication method, but you would NOT accept "specification required" (or "RFC required", as that include also RFC Editor Independent submission). The "IETF REview" do have proper IETF processes, altought a bit less than what is for required for "Standards Action. I assume the "Standard-track RFC" in the registry actually mean "Standards Action" in the RFC5226 language. The text for IETF Review from the RFC5226 says: ---------------------------------------------------------------------- IETF Review - (Formerly called "IETF Consensus" in [IANA-CONSIDERATIONS]) New values are assigned only through RFCs that have been shepherded through the IESG as AD- Sponsored or IETF WG Documents [RFC3932] [RFC3978]. The intention is that the document and proposed assignment will be reviewed by the IESG and appropriate IETF WGs (or experts, if suitable working groups no longer exist) to ensure that the proposed assignment will not negatively impact interoperability or otherwise extend IETF protocols in an inappropriate or damaging manner. To ensure adequate community review, such documents are shepherded through the IESG as AD-sponsored (or WG) documents with an IETF Last Call. ---------------------------------------------------------------------- Would that be acceptable for you? Would that be acceptable for others? That would be acceptable for me, as I just want something bit easier than current "Standard-Track RFC", i.e. I do not want to add new Standards to the IKEv1... -- kivinen@iki.fi From paul@cypherpunks.ca Sun Feb 12 13:53:54 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A124A21F867E for ; Sun, 12 Feb 2012 13:53:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nnq8UROT5CnC for ; Sun, 12 Feb 2012 13:53:53 -0800 (PST) Received: from letoams.cypherpunks.ca (unknown [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 9D24C21F861D for ; Sun, 12 Feb 2012 13:53:53 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id CDB0C81933; Sun, 12 Feb 2012 16:54:54 -0500 (EST) Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.5/8.14.5/Submit) with ESMTP id q1CLsDWH003443; Sun, 12 Feb 2012 16:54:14 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sun, 12 Feb 2012 16:54:13 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: ipsec@ietf.org, dev@openswan.org Message-ID: User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Paul Wouters Subject: [IPsec] IKEv2 Traffic Selector narrowing questions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 21:53:54 -0000 I have a few design questions on IKEv2 Traffic Selector narrowing Specifically, regarding http://tools.ietf.org/html/rfc5996#section-2.9 1) The responder can propose a narrowed proposal of the initiator's request a) What should the initiator do with packets that suddenly fall outside the new narrowed proposal? drop them? send them in plain text? (in other words, I'm trying to define a "local policy") b) If the initiator agrees to the narrowed proposal, how on earth should it inform the user? Should the user know? (I think so, see a) 2) If the initiator triggers the IKE on a packet, then it should send that packet's source/destination as the first TSi/TSr, and the complete tunnel proposal as the second TSi/TSr. The responder gets to pick which traffic selector to use. a) If the packet is 10.a.b.c to 10.d.e.f, and the policy on the initiator is 10.a.b.0/24 to 10/8, then why would it ever want to give the responder an option to narrow it down to what will eventually become a cascade of /32 <-> /32 Child SA's ? b) If the packet is triggered on some opportunistic encryption policy, eg based on IPSECKEY, then the initiator can reasonably only propose a /32 to /32 policy (and maybe not allow gateway != endpoint), in effect already (and only) creating the packet src/dst as the only valid traffic selector. 3) The first (so implicating important) use case mentioned is: "This could happen when the configurations of the two endpoints are being updated but only one end has received the new information." This seems like a real odd corner case. It reads me as "if we changed the lock on the front door, try this key on the back door". My guess is this is to support clients that were configured for say 10.0.0.0/8, to be narrowed down more specifically, say 10.0.0.0/24 but since the initiator is setting up the tunnel, it might have a need to reach 10.1.2.3/32. Now with that "this packet triggered this IKE request" it could signal this, and the responder could figure out its narrowing won't work for this client. But this just seems a bad patch to a bad starting situation. 4) The next use case is: "It also allows for intentionally different configurations, as when one end is configured to tunnel all addresses and depends on the other end to have the up-to-date list." This really smells like creating 0/0 <-> 0/0 tunnels, or as some vendors call it, "routing based VPNs". I guess the use case is to setup all clients with 0/0 <-> 0/0 and then reconfiguring/narrowing down on the head-end what you really want tunneled. This would then depend on the head-ends changing address range use. I can see the use case here. You want split-tunnel and tell the client which parts to send. It is something you want the client to agree to, though if it is already agreeing to send you everything, I guess it already decided to put all trust in the remote peer. But I believe this case is already covered via XAUTH with ModeCFG type scenarios? In other words, I find it really hard to come up with valid scenario's of narrowing down policy as per RFC 5669 Section 2.9. And as a result, I'm not sure how (and if) I should implement this part of the RFC. Am I wrong in that allowing narrowing on the initiator or responder is not something that should be allowed per-default, but only after being explicitely told to allow it? Or am I missing a (secure!) use case when not allowing narrowing of traffic selectors per default? Paul From nico@cryptonector.com Sun Feb 12 18:31:07 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1434321F865C for ; Sun, 12 Feb 2012 18:31:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ygWQL2MIGvD for ; Sun, 12 Feb 2012 18:31:06 -0800 (PST) Received: from homiemail-a77.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6489F21F8659 for ; Sun, 12 Feb 2012 18:31:06 -0800 (PST) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id 19FA49405E for ; Sun, 12 Feb 2012 18:31:06 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=gUouFAiNW6aMgahdFeWGcviOjDSqSsZDLQ435M65CwMo tMZMv5v8jAho9Zd0ICx2ZtVibP10lrnBsuZyuU/xcsRihn9T5EPNj3OOGp5KeHoh KDr9Ar5Yi2RaGf4Z7XP0fTrPFBSozGwQOC/cyL//LBgO/XA5z7/FfcDgoniVWoY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=dflCs34lMn4W+ELqtpt9A+9K5OU=; b=a6NLKfUxkUX sE2iTX137Byamr8jXPxKpN4r8f5WiCC1hkB4j6QPa9QhUdYfdpV3WVuAmsqWvL2c Q/QjPtFghCDHohVpgMkaj4NXZQ57qTlWrgPw44Wwg6g/TJmpb46Lt04OUz5ekAmH otoTxSjM1TQ/1qUa8zqgBZp9+Ns8Kexo= Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id 0A80E9400B for ; Sun, 12 Feb 2012 18:31:06 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so4358203pbc.31 for ; Sun, 12 Feb 2012 18:31:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.135.137 with SMTP id ps9mr42359230pbb.40.1329100265754; Sun, 12 Feb 2012 18:31:05 -0800 (PST) Received: by 10.68.136.4 with HTTP; Sun, 12 Feb 2012 18:31:05 -0800 (PST) In-Reply-To: References: Date: Sun, 12 Feb 2012 20:31:05 -0600 Message-ID: From: Nico Williams To: Paul Wouters Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org, dev@openswan.org, Paul Wouters Subject: Re: [IPsec] IKEv2 Traffic Selector narrowing questions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 02:31:07 -0000 On Sun, Feb 12, 2012 at 3:54 PM, Paul Wouters wrote: > 1) The responder can propose a narrowed proposal of the initiator's reque= st > > a) What should the initiator do with packets that suddenly fall outside > =C2=A0 the new narrowed proposal? drop them? send them in plain text? > =C2=A0 (in other words, I'm trying to define a "local policy") Local policy is not changed. If local policy requires that packets for some flow be sent with protection and there is no such SA, then the packets don't go. The local node should make a new proposal, possibly narrowed for the particular outgoing packet that's triggering SA negotiation. > b) If the initiator agrees to the narrowed proposal, how on earth should = it > =C2=A0 inform the user? Should the user know? (I think so, see a) Why should the user know? What matters is that policy be enforced. If there's no way to obtain a suitable SA, then you let the user know. > 2) If the initiator triggers the IKE on a packet, then it should send > =C2=A0 that packet's source/destination as the first TSi/TSr, and the com= plete > =C2=A0 tunnel proposal as the second TSi/TSr. The responder gets to pick = which > =C2=A0 traffic selector to use. > > a) If the packet is 10.a.b.c to 10.d.e.f, and the policy on the initiator > =C2=A0 is 10.a.b.0/24 to 10/8, then why would it ever want to give the > =C2=A0 responder an option to narrow it down to what will eventually beco= me > =C2=A0 a cascade of /32 <-> /32 Child SA's ? Because sometimes it's desirable to have per-flow SA pairs. >[...] > In other words, I find it really hard to come up with valid scenario's > of narrowing down policy as per RFC 5669 Section 2.9. And as a result, > I'm not sure how (and if) I should implement this part of the RFC. > > Am I wrong in that allowing narrowing on the initiator or responder is > not something that should be allowed per-default, but only after being > explicitely told to allow it? Or am I missing a (secure!) use case when > not allowing narrowing of traffic selectors per default? Narrowing proposals means having more SA pairs, basically. Does that have a negative impact on security? More, narrower SA pairs -> easier traffic analysis, perhaps. But beyond traffic analysis I see nothing wrong with lots of narrow SA pairs from a security point of view. >From a performance p.o.v. there may be an issue (more SA pairs -> more keys and key schedules -> more cache pressure -> lower performance). Replay protection may affect the choice to narrow traffic selectors, IIUC. Nico -- From sfluhrer@cisco.com Sun Feb 12 21:17:46 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 262F421F85D6 for ; Sun, 12 Feb 2012 21:17:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.374 X-Spam-Level: X-Spam-Status: No, score=-8.374 tagged_above=-999 required=5 tests=[AWL=2.225, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBqmEhrYUoyu for ; Sun, 12 Feb 2012 21:17:45 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id EAC3221F859E for ; Sun, 12 Feb 2012 21:17:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sfluhrer@cisco.com; l=7502; q=dns/txt; s=iport; t=1329110265; x=1330319865; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=DZ99miSbGLGsNrJj/pC4iO5tT6EeR2xPPTP5XB2MqUc=; b=WQlNv5R0ksyS7VKlzuT0skS3AIjDSr6l9SHxTZL8LhyrRi5WuoWbxEmA oejqlQOzL6w8WHfvW/Gu2WygPxKf65Ghim/70Tw/2CoCZctzLcmT005Ko vMnPJ6nn2tkonD0kzyCvv6BxwFhxz1AN1i7nrvSBzkLbbF/t26QYvzLfu Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABKcOE+rRDoH/2dsb2JhbABDr3eBB4FyAQEBAwESARQJCj8FBwQCAQgRBAEBCwYXAQYBRQkIAQEEARIIGodaCZpUAZ1Zi04aDAMCBQQBAwM3HASDJgGDf2MEiEqfbQ X-IronPort-AV: E=Sophos;i="4.73,410,1325462400"; d="scan'208";a="29874892" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 13 Feb 2012 05:17:44 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q1D5Hibs012022; Mon, 13 Feb 2012 05:17:44 GMT Received: from xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 12 Feb 2012 21:17:44 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: HJmg IDmX KB3B K1xy L1Io M33J R8Fu T1qG YC44 ZMMl cA6F dIw+ hMmj qr/3 sOAB vC1S; 4; ZABlAHYAQABvAHAAZQBuAHMAdwBhAG4ALgBvAHIAZwA7AGkAcABzAGUAYwBAAGkAZQB0AGYALgBvAHIAZwA7AHAAYQB1AGwAQABjAHkAcABoAGUAcgBwAHUAbgBrAHMALgBjAGEAOwBwAHcAbwB1AHQAZQByAHMAQAByAGUAZABoAGEAdAAuAGMAbwBtAA==; Sosha1_v1; 7; {E63EDCFF-74C6-44A0-BD3B-0DFAD62F4FFE}; cwBmAGwAdQBoAHIAZQByAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Mon, 13 Feb 2012 05:17:31 GMT; UgBFADoAIABbAEkAUABzAGUAYwBdACAASQBLAEUAdgAyACAAVAByAGEAZgBmAGkAYwAgAFMAZQBsAGUAYwB0AG8AcgAgAG4AYQByAHIAbwB3AGkAbgBnACAAcQB1AGUAcwB0AGkAbwBuAHMA MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {E63EDCFF-74C6-44A0-BD3B-0DFAD62F4FFE} Content-class: urn:content-classes:message Date: Sun, 12 Feb 2012 21:17:31 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] IKEv2 Traffic Selector narrowing questions Thread-Index: Aczp0NUQtjCt8ARNRqascjmQWnJU6AANqXQg References: From: "Scott Fluhrer (sfluhrer)" To: "Paul Wouters" , , X-OriginalArrivalTime: 13 Feb 2012 05:17:44.0216 (UTC) FILETIME=[D0E74180:01CCEA0E] Cc: Paul Wouters Subject: Re: [IPsec] IKEv2 Traffic Selector narrowing questions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 05:17:46 -0000 > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Paul Wouters > Sent: Sunday, February 12, 2012 4:54 PM > To: ipsec@ietf.org; dev@openswan.org > Cc: Paul Wouters > Subject: [IPsec] IKEv2 Traffic Selector narrowing questions >=20 >=20 >=20 > I have a few design questions on IKEv2 Traffic Selector narrowing >=20 > Specifically, regarding http://tools.ietf.org/html/rfc5996#section-2.9 >=20 >=20 > 1) The responder can propose a narrowed proposal of the initiator's > request >=20 > a) What should the initiator do with packets that suddenly fall outside > the new narrowed proposal? drop them? send them in plain text? > (in other words, I'm trying to define a "local policy") If the initiators SPD says that a particular packet should be protected, it'd be the Wrong Thing to send it in the clear just because it fell outside of the proposal that the responder replied with. IMHO, the correct behavior you should do if you have a packet that the SPD says should be encrypted but you don't have any SAs that you can send it with, is to attempt to negotiate an SA that can handle the packet. This is true regardless of whether you have any existing SAs for other packets. And, if the peer refuses to negotiate an SA that accepts the packet, well, I don't see you have any alternative to dropping the packets (unless you can find an alternative route to the destination that doesn't involve the IPsec SPD). >=20 > b) If the initiator agrees to the narrowed proposal, how on earth > should it > inform the user? Should the user know? (I think so, see a) Why would the user care? If you create new SAs on an as-needed basis, so that all the traffic is being encrypted, why would the user care if everything was handled by one SA, or a couple of SAs were used. Now, if the peer rejected the negotiation for some traffic the user was interested in, then yes you should inform him. However, this wouldn't appear to differ from the case that the peer rejected the SAs from the start. >=20 > 2) If the initiator triggers the IKE on a packet, then it should send > that packet's source/destination as the first TSi/TSr, and the > complete > tunnel proposal as the second TSi/TSr. The responder gets to pick > which > traffic selector to use. Not quite. The responder responds with a proposal that is a subset of the union of the proposals that the initiator sent. This subset could be just one of the selectors that the initiator sent, but doesn't have to be. In the example you give in (a) below, the responder could also send a proposal 10.a.b.0/24 to 10.d.e.0/24. >=20 > a) If the packet is 10.a.b.c to 10.d.e.f, and the policy on the > initiator > is 10.a.b.0/24 to 10/8, then why would it ever want to give the > responder an option to narrow it down to what will eventually > become > a cascade of /32 <-> /32 Child SA's ? Perhaps it's to avoid scenarios like "A can negotiate with B (because A's policy is a subset of B's), but B can't negotiate with A (because B proposes a proper superset of what A can accept)". After all, if A couldn't ask that the policy be narrowed, it would have to reject B's entire proposal, even if it could have handled the traffic we were actually interested in. In any case, as above, it is not meant to reduce to SAs that handle traffic source/dest'ed from single IP addresses. >=20 > b) If the packet is triggered on some opportunistic encryption policy, > eg based on IPSECKEY, then the initiator can reasonably only > propose > a /32 to /32 policy (and maybe not allow gateway !=3D endpoint), = in > effect already (and only) creating the packet src/dst as the only > valid traffic selector. >=20 > 3) The first (so implicating important) use case mentioned is: >=20 > "This could happen when the configurations of the two endpoints > are being updated but only one end has received the new > information." >=20 > This seems like a real odd corner case. It reads me as "if we changed > the lock on the front door, try this key on the back door". Doesn't sound like that much of a corner case to me. It's more of "if the two sides has policy that doesn't quite agree, we'll let them agree to the parts of the policy they have in common". Or, are you of the opinion that the two sides should reject negotiations (and all traffic is dropped) until the policy resyncs? > My guess is > this is to support clients that were configured for say 10.0.0.0/8, to > be > narrowed down more specifically, say 10.0.0.0/24 but since the > initiator > is setting up the tunnel, it might have a need to reach 10.1.2.3/32. > Now > with that "this packet triggered this IKE request" it could signal > this, > and the responder could figure out its narrowing won't work for this > client. > But this just seems a bad patch to a bad starting situation. >=20 > 4) The next use case is: >=20 > "It also allows for intentionally different configurations, as when > one > end is configured to tunnel all addresses and depends on the other > end > to have the up-to-date list." >=20 > This really smells like creating 0/0 <-> 0/0 tunnels, or as some > vendors > call it, "routing based VPNs". That's certainly part of it, but I don't believe that's the only case. > I guess the use case is to setup all > clients with 0/0 <-> 0/0 and then reconfiguring/narrowing down on the > head-end what you really want tunneled. This would then depend on the > head-ends changing address range use. I can see the use case here. > You want split-tunnel and tell the client which parts to send. It is > something you want the client to agree to, though if it is already > agreeing > to send you everything, I guess it already decided to put all trust in > the remote peer. But I believe this case is already covered via XAUTH > with > ModeCFG type scenarios? The above can also be useful when ModeCFG isn't being used. >=20 > In other words, I find it really hard to come up with valid scenario's > of narrowing down policy as per RFC 5669 Section 2.9. And as a result, > I'm not sure how (and if) I should implement this part of the RFC. >=20 > Am I wrong in that allowing narrowing on the initiator or responder is > not something that should be allowed per-default, but only after being > explicitely told to allow it? Or am I missing a (secure!) use case when > not allowing narrowing of traffic selectors per default? Are you wrong in suggesting that the RFC should be changed? That, of course, is a matter of opinion. If you ask my opinion, well, IKE always had the provision of the initiator proposing multiple encryption methods (3DES, AES) and the responder selecting a subset. How is this fundamentally different from the initiator proposing selectors, and the responder selecting a subset? If the former is useful, why isn't the latter? In any case, why do you think that there is a security problem with allowing the responder to narrow the selectors? If the responder narrows the selectors (and if the initiator makes sure that this narrowing really is a subset), then the SAs that will be set up with be in according to both SPDs; with selectors that are listed as to be protected, to peers that the SPD allows. I don't see a problem with this. From pwouters@redhat.com Mon Feb 13 05:24:59 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE6FE21F85AA for ; Mon, 13 Feb 2012 05:24:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.048 X-Spam-Level: X-Spam-Status: No, score=-101.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jhsmQuTE5uU for ; Mon, 13 Feb 2012 05:24:59 -0800 (PST) Received: from letoams.cypherpunks.ca (unknown [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0629A21F8587 for ; Mon, 13 Feb 2012 05:24:58 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id 5798581933; Mon, 13 Feb 2012 08:26:08 -0500 (EST) Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.5/8.14.5/Submit) with ESMTP id q1DDQ7Hw021078; Mon, 13 Feb 2012 08:26:07 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 13 Feb 2012 08:26:07 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: "Scott Fluhrer (sfluhrer)" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Mailman-Approved-At: Mon, 13 Feb 2012 08:07:08 -0800 Cc: ipsec@ietf.org, dev@openswan.org Subject: Re: [IPsec] IKEv2 Traffic Selector narrowing questions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 13:27:16 -0000 On Sun, 12 Feb 2012, Scott Fluhrer (sfluhrer) wrote: >> a) What should the initiator do with packets that suddenly fall > outside >> the new narrowed proposal? drop them? send them in plain text? >> (in other words, I'm trying to define a "local policy") > > If the initiators SPD says that a particular packet should be protected, > it'd be the Wrong Thing to send it in the clear just because it fell > outside of the proposal that the responder replied with. Right, so that likely means the initiator cannot allow any narrowing (unless you accept it is okay to start an IKE negotiation for each src/dst combo, which causes lots of delay for the user over establishing one broad SA) > IMHO, the correct behavior you should do if you have a packet that the > SPD says should be encrypted but you don't have any SAs that you can > send it with, is to attempt to negotiate an SA that can handle the > packet. This is true regardless of whether you have any existing SAs > for other packets. And, if the peer refuses to negotiate an SA that > accepts the packet, well, I don't see you have any alternative to > dropping the packets (unless you can find an alternative route to the > destination that doesn't involve the IPsec SPD). Agreed. But the initiator already sent a proposal that it thinks will cover its traffic. The responder's second guessing is what makes this harder. >> b) If the initiator agrees to the narrowed proposal, how on earth >> should it >> inform the user? Should the user know? (I think so, see a) > > Why would the user care? If you create new SAs on an as-needed basis, > so that all the traffic is being encrypted, why would the user care if > everything was handled by one SA, or a couple of SAs were used. Because I need to give the user some feedback if they bring a tunnel up to tell them if it succeeded or not. If part of the range is only covered, then what does one tell the user? The initiator also cannot keep requesting more narrow SA's until its covered all the space (esp in a 10/8 or even 0/0 case). So in the end, part of a tunnel is up and the user might need to know. > Now, if the peer rejected the negotiation for some traffic the user was > interested in, then yes you should inform him. However, this wouldn't > appear to differ from the case that the peer rejected the SAs from the > start. "some traffic" is all the traffic the responder narrowed down... > Not quite. The responder responds with a proposal that is a subset of > the union of the proposals that the initiator sent. This subset could > be just one of the selectors that the initiator sent, but doesn't have > to be. In the example you give in (a) below, the responder could also > send a proposal 10.a.b.0/24 to 10.d.e.0/24. > >> >> a) If the packet is 10.a.b.c to 10.d.e.f, and the policy on the >> initiator >> is 10.a.b.0/24 to 10/8, then why would it ever want to give the >> responder an option to narrow it down to what will eventually >> become >> a cascade of /32 <-> /32 Child SA's ? > > Perhaps it's to avoid scenarios like "A can negotiate with B (because > A's policy is a subset of B's), but B can't negotiate with A (because B > proposes a proper superset of what A can accept)". After all, if A > couldn't ask that the policy be narrowed, it would have to reject B's > entire proposal, even if it could have handled the traffic we were > actually interested in. Right. While I agree encrypting some is better then encrypting none, the confusion goes back to the user. Is the VPN up or not? Well, it's kinda up. As implementor, I have a hard time working with this. > Doesn't sound like that much of a corner case to me. It's more of "if > the two sides has policy that doesn't quite agree, we'll let them agree > to the parts of the policy they have in common". But again, leaving the user in some odd state of having partial vpn connectivity. > Or, are you of the opinion that the two sides should reject negotiations > (and all traffic is dropped) until the policy resyncs? At least that is something I can convey back to the user. >> I guess the use case is to setup all >> clients with 0/0 <-> 0/0 and then reconfiguring/narrowing down on the >> head-end what you really want tunneled. This would then depend on the >> head-ends changing address range use. I can see the use case here. >> You want split-tunnel and tell the client which parts to send. It is >> something you want the client to agree to, though if it is already >> agreeing >> to send you everything, I guess it already decided to put all trust in >> the remote peer. But I believe this case is already covered via XAUTH >> with >> ModeCFG type scenarios? > > The above can also be useful when ModeCFG isn't being used. Yes, but that is the "routed vpn" scenario. >> In other words, I find it really hard to come up with valid scenario's >> of narrowing down policy as per RFC 5669 Section 2.9. And as a result, >> I'm not sure how (and if) I should implement this part of the RFC. >> >> Am I wrong in that allowing narrowing on the initiator or responder is >> not something that should be allowed per-default, but only after being >> explicitely told to allow it? Or am I missing a (secure!) use case > when >> not allowing narrowing of traffic selectors per default? > > Are you wrong in suggesting that the RFC should be changed? That, of > course, is a matter of opinion. If you ask my opinion, well, IKE always > had the provision of the initiator proposing multiple encryption methods > (3DES, AES) and the responder selecting a subset. How is this > fundamentally different from the initiator proposing selectors, and the > responder selecting a subset? If the former is useful, why isn't the > latter? Because that case covers all traffic the initiator wanted, while reducing the address space covers only partialy what the initiator wanted. The question then becomes, did the initiator meant to say "give me all or some of this". And if so, then how does the initiator know which "some" is good and which "some" is bad for the user? > In any case, why do you think that there is a security problem with > allowing the responder to narrow the selectors? If the responder > narrows the selectors (and if the initiator makes sure that this > narrowing really is a subset), then the SAs that will be set up with be > in according to both SPDs; with selectors that are listed as to be > protected, to peers that the SPD allows. I don't see a problem with > this. If I want to setup a tunnel to 10/8 and I only get 10/24, then for 10/24 the tunnel suceeded, but for 10.255.255.0/24 the tunnel failed. The only information I have as implementor is that the user wanted 10/8. So to me the tunnel has failed to establish. But taking that approach just means I always end up rejecting every narrowed down proposal, which I still think is the sane default. I am just reaching out to understand why and how I should allow this narrowing to take place to get the advantages of it without the disavvantages. Paul > From shanna@juniper.net Mon Feb 13 09:54:03 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DDCA21F86D9 for ; Mon, 13 Feb 2012 09:54:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id op9V+YdXZLJu for ; Mon, 13 Feb 2012 09:54:00 -0800 (PST) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 1B89321F8674 for ; Mon, 13 Feb 2012 09:53:53 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKTzlOMKOa/FubLmZ46E5SzitO7uRlx9S1@postini.com; Mon, 13 Feb 2012 09:53:58 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 13 Feb 2012 09:52:19 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Mon, 13 Feb 2012 12:52:19 -0500 From: Stephen Hanna To: Mark Boltz , "Ulliott, Chris" Date: Mon, 13 Feb 2012 12:52:04 -0500 Thread-Topic: [IPsec] NUDGE: Starting work on our new charter items Thread-Index: AQHM3ROI6lryQc3iAUKRSHADDknCmZYmRyGAgAz7bemAB/B6QA== Message-ID: References: <8CAC2292-8A17-4B38-B2DC-D8A4FDB43CEB@vpnc.org>, <20549DD10769DA47A86F0F0FAF8012DD031BF75CC0@PIACHEVEX00.GCHQ.GOV.UK> <383B3239-76E7-4960-8B1E-5A71F4B5AE52@stonesoft.com> In-Reply-To: <383B3239-76E7-4960-8B1E-5A71F4B5AE52@stonesoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EXCLAIMER-MD-CONFIG: f8e27f27-03b2-4c3e-9447-119194e72cb6 Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] NUDGE: Starting work on our new charter items X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 17:54:04 -0000 Mark, Thanks for stepping forward to help with the problem statement and with reviewing the various drafts. In order to maximize the open discussion of these drafts, I think it's best to conduct these discussions on the public ipsec email list. Therefore, I'll be posting a first draft of the problem statement ASAP to get some discussion going. For everyone's reference, the updated ipsecme charter is at http://datatracker.ietf.org/wg/ipsecme/charter It now includes this text relating to the scalable VPN work: --------- In an environment with many IPsec gateways and remote clients that share an established trust infrastructure (in a single administrative domain or across multiple domains), customers want to get on-demand point-to-point IPsec capability for efficiency. However, this cannot be feasibly accomplished only with today's IPsec and IKE due to problems with address lookup, reachability, policy configuration, and so on. The IPsecME Working Group will handle this large scale VPN problem by: * Creating a problem statement document including use cases, definitions and proper requirements for discovery and updates. This document would be solution-agnostic. * Publishing a common solution for the discovery and update problems that will satisfy the requirements in the problem statement document. The working group may standardize one of the vendor solutions, a combination, an superset of such a solution, or a new protocol. * Reviewing and help publish Informational documents describing current vendor proprietary solutions. --------- Thanks, Steve > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Mark Boltz > Sent: Wednesday, February 08, 2012 11:26 AM > To: Ulliott, Chris > Cc: IPsecme WG; Paul Hoffman > Subject: Re: [IPsec] NUDGE: Starting work on our new charter items >=20 > I will volunteer to help review the drafts and develop the > requirements. How should we approach that sharing? Google, this list, > something else? Also, could someone (re-)post the charter with the > objectives again, I can't seem to find it. Alternatively send to me > directly off list. >=20 > I look forward to participating. >=20 > -- > Mark Boltz, CISSP, CISA, NSA-IEM, CSGI > Director, Federal and Mid-Atlantic > e: mark.boltz@stonesoft.com e: federal@stonesoft.com > p: 866.869.4075 c: 571.246.2233 > o: 202.434.8963 f: 703.997.4759 > w: http://www.stonesoft.com >=20 > 1200 G St. NW, Suite 800 > Washington, DC 20005-6705 >=20 > Stonesoft: Network Security. Simplified. >=20 > On Jan 31, 2012, at 7:12 AM, "Ulliott, Chris" > wrote: >=20 > > Paul - count me in, am more than happy to contribute and help review > drafts. Unfortunately getting to Paris could be challenging, but I'll > go and talk nicely to the folk who control the purse strings! > > > > Chris > > > > -----Original Message----- > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On > Behalf Of Paul Hoffman > > Sent: Friday, January 27, 2012 4:49 PM > > To: IPsecme WG > > Subject: [IPsec] NUDGE: Starting work on our new charter items > > > > [[ There has not been enough response yet, by far. ]] > > > > We have a new charter. Do we have any volunteers to start work on the > two documents we committed to work on? > > > > Related: we should consider having a face-to-face meeting at the > upcoming IETF in Paris, but only if there is value for the newly- > chartered work. In my mind, that means both a first draft submitted > *and* interesting questions that would benefit from face-to-face > discussion instead of just work on the list. Do people believe we will > have that? > > > > --Paul Hoffman > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > *********************************************************************** > ***** > > Communications with GCHQ may be monitored and/or recorded > > for system efficiency and other lawful purposes. Any views or > > opinions expressed in this e-mail do not necessarily reflect GCHQ > > policy. This email, and any attachments, is intended for the > > attention of the addressee(s) only. Its unauthorised use, > > disclosure, storage or copying is not permitted. If you are not the > > intended recipient, please notify postmaster@gchq.gsi.gov.uk. > > > > This information is exempt from disclosure under the Freedom of > > Information Act 2000 and may be subject to exemption under > > other UK information legislation. Refer disclosure requests to > > GCHQ on 01242 221491 ext 30306 (non-secure) or email > > infoleg@gchq.gsi.gov.uk > > > > > *********************************************************************** > ***** > > > > > > The original of this email was scanned for viruses by the Government > Secure Intranet virus scanning service supplied by Cable&Wireless > Worldwide in partnership with MessageLabs. (CCTM Certificate Number > 2009/09/0052.) On leaving the GSi this email was certified virus free. > > Communications via the GSi may be automatically logged, monitored > and/or recorded for legal purposes. > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From ynir@checkpoint.com Mon Feb 13 11:28:34 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98D4721F8633 for ; Mon, 13 Feb 2012 11:28:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.464 X-Spam-Level: X-Spam-Status: No, score=-10.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hqq7th5y94eb for ; Mon, 13 Feb 2012 11:28:34 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE5B21F857A for ; Mon, 13 Feb 2012 11:28:33 -0800 (PST) X-CheckPoint: {4F396093-1-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q1DJSSw6017992; Mon, 13 Feb 2012 21:28:28 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 13 Feb 2012 21:28:28 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Mon, 13 Feb 2012 21:28:27 +0200 From: Yoav Nir To: Paul Wouters Date: Mon, 13 Feb 2012 21:28:26 +0200 Thread-Topic: [IPsec] IKEv2 Traffic Selector narrowing questions Thread-Index: AczqhaisSPRg9yC8T2OW8iftZOWxrw== Message-ID: <4265BC7A-017E-4F23-98E2-FB80E73D8032@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "ipsec@ietf.org" , "dev@openswan.org" , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] IKEv2 Traffic Selector narrowing questions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 19:28:34 -0000 On Feb 13, 2012, at 3:26 PM, Paul Wouters wrote: > On Sun, 12 Feb 2012, Scott Fluhrer (sfluhrer) wrote: >=20 >>> a) What should the initiator do with packets that suddenly fall >> outside >>> the new narrowed proposal? drop them? send them in plain text? >>> (in other words, I'm trying to define a "local policy") >>=20 >> If the initiators SPD says that a particular packet should be protected, >> it'd be the Wrong Thing to send it in the clear just because it fell >> outside of the proposal that the responder replied with. >=20 > Right, so that likely means the initiator cannot allow any narrowing > (unless you accept it is okay to start an IKE negotiation for each > src/dst combo, which causes lots of delay for the user over establishing > one broad SA) Not really. Think of an example, where Gw-A has 192.168.3.0/24 behind it, w= hile Gw-B has 192.168.6.0/23 behind it, although on Gw-B it is defined as t= wo /24 subnets.=20 Gw-A might initiate with TS: 192.168.3.0/24<-->192.168.6.0/23, but since th= e triggering packet is 192.168.3.5-->192.168.6.9, the proposal gets narrowe= d to 192.168.3.0/24<-->192.168.6.0/24. If later a 192.168.3.5-->192.168.7.10 packet comes around, the SA won't cov= er it, so it will start a new negotiation that will get narrowed to 192.168= .3.0/24<-->192.168.7.0/24. There is no reason why the initiator cannot allow any narrowing. This is su= pposed to be an improvement over IKEv1 where any mismatch in configuration = between the peers resulted in failure to set up a tunnel. I realize that th= is invalidates the concept of a defined tunnel being either "up" or "down". Yoav= From pwouters@redhat.com Mon Feb 13 12:17:11 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF77521E8010 for ; Mon, 13 Feb 2012 12:17:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.448 X-Spam-Level: X-Spam-Status: No, score=-110.448 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Idtr8U8NcYJL for ; Mon, 13 Feb 2012 12:17:11 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 34A0921F875B for ; Mon, 13 Feb 2012 12:17:11 -0800 (PST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q1DKH1t7002518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Feb 2012 15:17:01 -0500 Received: from thinkpad.nohats.ca (vpn-8-168.rdu.redhat.com [10.11.8.168]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q1DKGxRf018471 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 13 Feb 2012 15:17:00 -0500 Message-ID: <4F396FAB.1030708@redhat.com> Date: Mon, 13 Feb 2012 15:16:43 -0500 From: Paul Wouters User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120131 Thunderbird/10.0 MIME-Version: 1.0 To: Yoav Nir References: <4265BC7A-017E-4F23-98E2-FB80E73D8032@checkpoint.com> In-Reply-To: <4265BC7A-017E-4F23-98E2-FB80E73D8032@checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Cc: "ipsec@ietf.org" , "dev@openswan.org" , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] IKEv2 Traffic Selector narrowing questions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 20:17:11 -0000 On 02/13/2012 02:28 PM, Yoav Nir wrote: > On Feb 13, 2012, at 3:26 PM, Paul Wouters wrote: > >> On Sun, 12 Feb 2012, Scott Fluhrer (sfluhrer) wrote: >> >>>> a) What should the initiator do with packets that suddenly fall >>> outside >>>> the new narrowed proposal? drop them? send them in plain text? >>>> (in other words, I'm trying to define a "local policy") >>> If the initiators SPD says that a particular packet should be protected, >>> it'd be the Wrong Thing to send it in the clear just because it fell >>> outside of the proposal that the responder replied with. >> Right, so that likely means the initiator cannot allow any narrowing >> (unless you accept it is okay to start an IKE negotiation for each >> src/dst combo, which causes lots of delay for the user over establishing >> one broad SA) > Not really. Think of an example, where Gw-A has 192.168.3.0/24 behind it, while Gw-B has 192.168.6.0/23 behind it, although on Gw-B it is defined as two /24 subnets. > > Gw-A might initiate with TS: 192.168.3.0/24<-->192.168.6.0/23, but since the triggering packet is 192.168.3.5-->192.168.6.9, the proposal gets narrowed to 192.168.3.0/24<-->192.168.6.0/24. I'm still looking at it from the user's point of view. Let's say that Sysadmin A brought up the "A to B" tunnel. They think they got the whole /23 covered, but in fact half of what they think is up, is not. Should GwA keep retrying the for either the entire /23 or for the remaining /24 that fell outside the narrowing? > There is no reason why the initiator cannot allow any narrowing. This is supposed to be an improvement over IKEv1 where any mismatch in configuration between the peers resulted in failure to set up a tunnel. I realize that this invalidates the concept of a defined tunnel being either "up" or "down". Right. This is the exact problem I'm trying to handle, and I don't see a good way out. I'm also really afraid people will start demanding I configure 0/0 to them so they can be lazy and I end up with massive overlapping policies to deal with and I won't be able to have more then one vpn up at a time. Paul From pwouters@redhat.com Mon Feb 13 12:24:09 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C62221F874F for ; Mon, 13 Feb 2012 12:24:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.523 X-Spam-Level: X-Spam-Status: No, score=-110.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPF7tKHMUj9Y for ; Mon, 13 Feb 2012 12:24:09 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3F621F8729 for ; Mon, 13 Feb 2012 12:24:08 -0800 (PST) Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q1DKO8YM023029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 13 Feb 2012 15:24:08 -0500 Received: from thinkpad.nohats.ca (vpn-8-168.rdu.redhat.com [10.11.8.168]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q1DKO7HK002985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 13 Feb 2012 15:24:08 -0500 Message-ID: <4F397156.2060102@redhat.com> Date: Mon, 13 Feb 2012 15:23:50 -0500 From: Paul Wouters User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120131 Thunderbird/10.0 MIME-Version: 1.0 To: ipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 Subject: [IPsec] iOSX 5.x and IOX Lion's use of UDP_ENCAP problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 20:24:09 -0000 Hi, There are many IPsec related standards, and I was hoping to use the combined experience of the list to tell me if in fact, these new apple devices have a bug, or whether it is an RFC or draft anywhere. When using L2TP/IPsec mode with IKEv1, the latest iphones/OSX machines, when on public IP, and when no NAT is detected, send UDP_ENCAP packets where the inner IP is the same as the outer IP. On the server, this is a problem. We now need to build tunnels to a random publicly addressable IP. Since that is dangerous and could be hijacking a real IP address, openwan only limits per default to RFC1918 space (and 25/8 since too many North American telco's use this and the UK MoD seems to not care). As a result, to make this work, we need to allow basically any public IP to be tunnelled. Is this indeed a bug in these devices? If so, is there anyone from Apple here that I can talk to and resolve this. Or if this is a feature/draft/rfc, could someone point me to it? Thanks, Paul From nico@cryptonector.com Mon Feb 13 12:30:38 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C343721F873B for ; Mon, 13 Feb 2012 12:30:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.876 X-Spam-Level: X-Spam-Status: No, score=-1.876 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27IzRLZIYGnO for ; Mon, 13 Feb 2012 12:30:38 -0800 (PST) Received: from homiemail-a90.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 2828921F870E for ; Mon, 13 Feb 2012 12:30:38 -0800 (PST) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id DFB0D2AC077 for ; Mon, 13 Feb 2012 12:30:37 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=N1HnVQ7DmlTSErxcXbpvq +pXm4CJTMgI/KEQKXe9hAbigZxCu1OuUttIgCHAptGyJc31+KUPb2sb2cqaMV12f wO62Eo7aKS9Z1EJWiqgLXxjOmgLXG09jUTXyRqjzFS1KBLJ6zP+X2s/uWCK4Ps42 2BcPUjIV+TqdP4rCS5lXLk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=D3VM6uTMax8b6nf2gRJ+ 2c+AfOs=; b=eZhHWEOrYy5Euiq/rGxpjHith1GAhxrmQYK0GZUrbVtpIrTPpYIG edGKuYL7/ainMcaAAnrASwMHQg/FwSUQ8G/XLP+Slny3EyljuxG7JCJVR8jDhOZ5 IxRuZ+PPeHpF8taceF92T9KvXipao8dMxcIdnSq6zxuEUqzop8ClUm0= Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPSA id D06982AC06A for ; Mon, 13 Feb 2012 12:30:37 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so5113443pbc.31 for ; Mon, 13 Feb 2012 12:30:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.226.166 with SMTP id rt6mr50636252pbc.23.1329165037317; Mon, 13 Feb 2012 12:30:37 -0800 (PST) Received: by 10.68.136.4 with HTTP; Mon, 13 Feb 2012 12:30:37 -0800 (PST) In-Reply-To: <4F397156.2060102@redhat.com> References: <4F397156.2060102@redhat.com> Date: Mon, 13 Feb 2012 14:30:37 -0600 Message-ID: From: Nico Williams To: Paul Wouters Content-Type: text/plain; charset=UTF-8 Cc: ipsec@ietf.org Subject: Re: [IPsec] iOSX 5.x and IOX Lion's use of UDP_ENCAP problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 20:30:38 -0000 You can do one thing on the server side: assign an IP address to the client and do NAT in the tunnel. This approach saves you the need to implement address allocation extensions in KE protocols :) (IIRC IKEv1 has no standard address allocation feature.) Nico -- From smoonen@us.ibm.com Mon Feb 13 12:33:56 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1012321E801B for ; Mon, 13 Feb 2012 12:33:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lTFnJAx3eIX for ; Mon, 13 Feb 2012 12:33:55 -0800 (PST) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by ietfa.amsl.com (Postfix) with ESMTP id E213C21F84B6 for ; Mon, 13 Feb 2012 12:33:54 -0800 (PST) Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 13 Feb 2012 15:33:53 -0500 Received: from d01dlp01.pok.ibm.com (9.56.224.56) by e9.ny.us.ibm.com (192.168.1.109) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 13 Feb 2012 15:33:44 -0500 Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id E65AE38C814B; Mon, 13 Feb 2012 15:33:05 -0500 (EST) Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q1DKX28f247264; Mon, 13 Feb 2012 15:33:03 -0500 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q1DKWmd3020781; Mon, 13 Feb 2012 13:32:48 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.63.40.219]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q1DKWmvj020763; Mon, 13 Feb 2012 13:32:48 -0700 In-Reply-To: <4F397156.2060102@redhat.com> References: <4F397156.2060102@redhat.com> X-KeepSent: 9B4B24E4:B8A16DB9-852579A3:00704552; type=4; name=$KeepSent To: Paul Wouters X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: Scott C Moonen Date: Mon, 13 Feb 2012 15:29:56 -0500 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.3 ZX853HP5|January 12, 2012) at 02/13/2012 13:32:47 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12021320-7182-0000-0000-000000C4B79C Cc: ipsec@ietf.org, ipsec-bounces@ietf.org Subject: Re: [IPsec] iOSX 5.x and IOX Lion's use of UDP_ENCAP problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 20:33:56 -0000 Paul, for IKEv2, according to RFC 5996: "If Network Address Translation Traversal (NAT-T) is supported (that is, if NAT_DETECTION_*_IP payloads were exchanged during IKE_SA_INIT), all devices MUST be able to receive and process both UDP-encapsulated ESP and non-UDP-encapsulated ESP packets at any time. Either side can decide whether or not to use UDP encapsulation for ESP irrespective of the choice made by the other side. However, if a NAT is detected, both devices MUST use UDP encapsulation for ESP." I'm not aware of similar statements that you could appeal to for IKEv1, but in the long run you're going to need to accommodate this behavior anyway, at least for IKEv2. Scott Moonen (smoonen@us.ibm.com) Secure Hybrid Cloud and z/OS Communications Server http://www.linkedin.com/in/smoonen From: Paul Wouters To: ipsec@ietf.org Date: 2012-02-13 15:24 Subject: [IPsec] iOSX 5.x and IOX Lion's use of UDP_ENCAP problem Sent by: ipsec-bounces@ietf.org Hi, There are many IPsec related standards, and I was hoping to use the combined experience of the list to tell me if in fact, these new apple devices have a bug, or whether it is an RFC or draft anywhere. When using L2TP/IPsec mode with IKEv1, the latest iphones/OSX machines, when on public IP, and when no NAT is detected, send UDP_ENCAP packets where the inner IP is the same as the outer IP. On the server, this is a problem. We now need to build tunnels to a random publicly addressable IP. Since that is dangerous and could be hijacking a real IP address, openwan only limits per default to RFC1918 space (and 25/8 since too many North American telco's use this and the UK MoD seems to not care). As a result, to make this work, we need to allow basically any public IP to be tunnelled. Is this indeed a bug in these devices? If so, is there anyone from Apple here that I can talk to and resolve this. Or if this is a feature/draft/rfc, could someone point me to it? Thanks, Paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From tjcarlin@iol.unh.edu Mon Feb 13 12:37:37 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45D3621E802B for ; Mon, 13 Feb 2012 12:37:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAMoz2yzJdPR for ; Mon, 13 Feb 2012 12:37:36 -0800 (PST) Received: from exprod5og104.obsmtp.com (exprod5og104.obsmtp.com [64.18.0.178]) by ietfa.amsl.com (Postfix) with SMTP id BF3F521E802A for ; Mon, 13 Feb 2012 12:37:35 -0800 (PST) Received: from postal.iol.unh.edu ([132.177.123.84]) by exprod5ob104.postini.com ([64.18.4.12]) with SMTP ID DSNKTzl0jzh2ZZkWrtnYsmORhmzDJyh7Lij/@postini.com; Mon, 13 Feb 2012 12:37:35 PST Received: from patriot.iol.unh.edu (patriot.iol.unh.edu [132.177.118.220]) by postal.iol.unh.edu (Postfix) with ESMTP id AA0E38F0067; Mon, 13 Feb 2012 15:37:34 -0500 (EST) From: Timothy Carlin Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Feb 2012 15:37:53 -0500 To: IPsecme WG Message-Id: <80C0FB1A-03C7-46FB-89BB-D815B2DFD0B4@iol.unh.edu> Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [IPsec] IKEv2 Traffic Selectors X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 20:37:37 -0000 Hello, During testing, the UNH-IOL has encountered a behavior with regards to = the handling of Traffic Selectors that causes interoperability issues. The issue center around the handling of this quote from RFC 5996, = Section 2.9: =93To enable the responder to choose the appropriate range in this = case, if the initiator has requested the SA due to a data packet, the initiator SHOULD include as the first Traffic Selector in each of TSi and TSr a very specific Traffic Selector including the addresses in the packet triggering the request.=94 We've seen that implementations acting as the responder handle the Very = Specific Traffic Selector in different ways, resulting in = non-interoperability. Some implementations reject the connection, due = to not matching configured selectors, while other implementations accept = only this traffic selector, inadvertently narrowing the tunnel. This also causes a detrimental oddity when the data packet causing SA = creation is an ICMPv6 Echo Request. In this case, both TSi and TSr = indicate ICMPv6, type 80, Code 00. This is a special case, since ICMP = has no source and destination port. What should the proper behavior be = for a packet type with no source and destination port? The UNH-IOL would very much appreciate any thoughts the Working Group = might have regarding this behavior! Best Regards, Timothy Carlin ---- Timothy Carlin UNH-IOL tjcarlin@iol.unh.edu From paul.hoffman@vpnc.org Mon Feb 13 12:41:04 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66A9321E8033 for ; Mon, 13 Feb 2012 12:41:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWyo2YW9gyOI for ; Mon, 13 Feb 2012 12:41:03 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1D821E801B for ; Mon, 13 Feb 2012 12:41:03 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1DKemxJ013956 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 13 Feb 2012 13:40:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4F396FAB.1030708@redhat.com> Date: Mon, 13 Feb 2012 12:40:48 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <74EA2F4C-7259-4D10-8493-D83CE82C4BEB@vpnc.org> References: <4265BC7A-017E-4F23-98E2-FB80E73D8032@checkpoint.com> <4F396FAB.1030708@redhat.com> To: Paul Wouters X-Mailer: Apple Mail (2.1257) Cc: "ipsec@ietf.org" , "dev@openswan.org" , Yoav Nir , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] IKEv2 Traffic Selector narrowing questions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 20:41:04 -0000 On Feb 13, 2012, at 12:16 PM, Paul Wouters wrote: > On 02/13/2012 02:28 PM, Yoav Nir wrote: >> There is no reason why the initiator cannot allow any narrowing. This = is supposed to be an improvement over IKEv1 where any mismatch in = configuration between the peers resulted in failure to set up a tunnel. = I realize that this invalidates the concept of a defined tunnel being = either "up" or "down". >=20 > Right. This is the exact problem I'm trying to handle, and I don't see = a good way out. I'm also really afraid people will start demanding I = configure 0/0 to them so they can be lazy and I end up with massive = overlapping policies to deal with and I won't be able to have more then = one vpn up at a time. If the problem is "the application knows the exact tunnel it needs", = then the solution is that if the responder narrows the tunnel, the IPsec = stack tells the application "you never got a tunnel". IKEv2 was designed around the idea of gateways being the ones that = control the tunnel properties, thus avoiding the API issues to = applications. --Paul Hoffman From ynir@checkpoint.com Mon Feb 13 12:45:24 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D491E21F8575 for ; Mon, 13 Feb 2012 12:45:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.471 X-Spam-Level: X-Spam-Status: No, score=-10.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1lzElkxSMjs for ; Mon, 13 Feb 2012 12:45:24 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id E2C3621F8593 for ; Mon, 13 Feb 2012 12:45:23 -0800 (PST) X-CheckPoint: {4F397295-1-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q1DKjMLq032708; Mon, 13 Feb 2012 22:45:22 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 13 Feb 2012 22:45:21 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Mon, 13 Feb 2012 22:45:20 +0200 From: Yoav Nir To: Paul Wouters Date: Mon, 13 Feb 2012 22:45:14 +0200 Thread-Topic: [IPsec] iOSX 5.x and IOX Lion's use of UDP_ENCAP problem Thread-Index: AczqkGXPrQ0JcHa7R9Kin4gDATvFew== Message-ID: <29D7E149-2FD2-4923-8695-84A5EF0E7DE4@checkpoint.com> References: <4F397156.2060102@redhat.com> In-Reply-To: <4F397156.2060102@redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "ipsec@ietf.org" Subject: Re: [IPsec] iOSX 5.x and IOX Lion's use of UDP_ENCAP problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 20:45:24 -0000 On Feb 13, 2012, at 10:23 PM, Paul Wouters wrote: > Hi, >=20 > There are many IPsec related standards, and I was hoping to use the=20 > combined experience of the list to tell me if in fact, these new apple=20 > devices have a bug, or whether it is an RFC or draft anywhere. >=20 > When using L2TP/IPsec mode with IKEv1, the latest iphones/OSX machines,=20 > when on public IP, and when no NAT is detected, send UDP_ENCAP packets=20 > where the inner IP is the same as the outer IP. >=20 > On the server, this is a problem. We now need to build tunnels to a=20 > random publicly addressable IP. Since that is dangerous and could be=20 > hijacking a real IP address, openwan only limits per default to RFC1918=20 > space (and 25/8 since too many North American telco's use this and the=20 > UK MoD seems to not care). As a result, to make this work, we need to=20 > allow basically any public IP to be tunnelled. >=20 > Is this indeed a bug in these devices? If so, is there anyone from Apple= =20 > here that I can talk to and resolve this. Or if this is a=20 > feature/draft/rfc, could someone point me to it? Hi Paul I'm not sure I follow you. L2TP/IPSec uses transport mode ESP, so the inner= IP is inside the L2TP tunnel. That address is assigned in the IPCP protoco= l by your gateway. So you have a routable address on the outside, and your own chosen address = on the inside.=20 So what is the issue? Yoav= From nico@cryptonector.com Mon Feb 13 13:00:16 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F2121E8015 for ; Mon, 13 Feb 2012 13:00:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2C07S2o6HF48 for ; Mon, 13 Feb 2012 13:00:16 -0800 (PST) Received: from homiemail-a98.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 4496221E8012 for ; Mon, 13 Feb 2012 13:00:16 -0800 (PST) Received: from homiemail-a98.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTP id 17C342C200B for ; Mon, 13 Feb 2012 13:00:16 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=jrDEAO6+WydpQwz1TU7V2 e4ARrykxWJQMenuqlrRJHxqMs49/RGvqZqln0dLeNEJZH9g0hfLy3rpDxtytsgFf aXPvyyb7c0dfBGDKU4gMuR5rBfytqisl9Ab/b2bnzz/R9SLtl0CJFe2DUgbRcV9g 1fEESeBXhjzQaCgYGkEZCg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=wP5GKQAcnAlRfZf2Ct3T lRGCbjM=; b=rOzT5mapEORL+2BLjaSN+nzUbV+QEDlAou07L9Lbb8GGG551lre0 VQUkKrLqgKpWPeZEMt59NEwmSlA0l8pcdIUQ2d+FH9NptIQbps4e4IZ0RPRNxHHZ DOn4MFzzHcXKmgB2pNHvXF4TCQk/jBe+zl0tSRtJ6P1kZ0768qk00Os= Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTPSA id F261B2C2005 for ; Mon, 13 Feb 2012 13:00:15 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so5137021pbc.31 for ; Mon, 13 Feb 2012 13:00:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.241.70 with SMTP id wg6mr50896579pbc.6.1329166815592; Mon, 13 Feb 2012 13:00:15 -0800 (PST) Received: by 10.68.136.4 with HTTP; Mon, 13 Feb 2012 13:00:15 -0800 (PST) In-Reply-To: <74EA2F4C-7259-4D10-8493-D83CE82C4BEB@vpnc.org> References: <4265BC7A-017E-4F23-98E2-FB80E73D8032@checkpoint.com> <4F396FAB.1030708@redhat.com> <74EA2F4C-7259-4D10-8493-D83CE82C4BEB@vpnc.org> Date: Mon, 13 Feb 2012 15:00:15 -0600 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Cc: "ipsec@ietf.org" , "dev@openswan.org" , Paul Wouters , Yoav Nir , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] IKEv2 Traffic Selector narrowing questions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 21:00:16 -0000 Traffic selector narrowing can also have uses in end-to-end IPsec. For example, on Solaris apps can use the IP_SEC_OPT socket option to request IPsec protection, and they can even request narrow SAs such that there's an SA pair for just the connected socket's packet flow, and this can be requested on both, the client and server side of a TCP socket. I don't think narrowing traffic selectors implies that the responder is unwilling to handle traffic covered by the initiator's proposal but not by the responder's narrowed selectors. If the initiator tries again for a different triggering outbound packet it may find that it can tunnel that packet too, and it may find itself having many narrow SAs instead of one big one. So what? Or have I misunderstood narrowing? A tunnel is "up" when bits move. IKE connectivity (specifically being able to establish an IKE_SA) will be a pre-requisite, if you're using IKE anyways. Beyond that bits will move IFF a) local policy allows them to, b) nothing is wrong with the network, the responder, and ultimate end-point. "Bits are not moving" in some cases can only be determined heuristically (by timeouts). So what does "tunnel is up" mean? To me it means local configuration is setup to require tunneling, not that the bits are guaranteed to move. Nico -- From yaronf.ietf@gmail.com Mon Feb 13 13:53:23 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E21F21E8012 for ; Mon, 13 Feb 2012 13:53:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.45 X-Spam-Level: X-Spam-Status: No, score=-103.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-xDJve5CcUQ for ; Mon, 13 Feb 2012 13:53:21 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id CC01121E802D for ; Mon, 13 Feb 2012 13:53:17 -0800 (PST) Received: by eaal12 with SMTP id l12so1932650eaa.31 for ; Mon, 13 Feb 2012 13:53:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ZBbHHTN5QPzD0qRoUvhs/lHGt7OQ4aAR9RuO7ZC362s=; b=NEz8U5YlujL6qb86dsLb+17iSaVm/qT3Foyv8SBUyqlKtuIuFKJRgBZm/mVdYqfEsf NHCBFnhwecbZKSMdovrevV6XIbGo51/idfV8r2AG7Y6zf5MvGaDQvHRzSQNVojbOK01/ 5SZB9ynsDGXBz+A7jcDL6whqv6/EvjGJRBgBE= Received: by 10.213.29.145 with SMTP id q17mr2148002ebc.114.1329169994240; Mon, 13 Feb 2012 13:53:14 -0800 (PST) Received: from [10.0.0.6] (bzq-79-177-151-176.red.bezeqint.net. [79.177.151.176]) by mx.google.com with ESMTPS id a58sm65390414eeb.8.2012.02.13.13.53.11 (version=SSLv3 cipher=OTHER); Mon, 13 Feb 2012 13:53:13 -0800 (PST) Message-ID: <4F398646.60303@gmail.com> Date: Mon, 13 Feb 2012 23:53:10 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Tero Kivinen References: <20162.16194.361337.415232@fireball.kivinen.iki.fi> <20235.3284.301719.250098@fireball.kivinen.iki.fi> <4F340992.5030502@gmail.com> <372E1EC3-5516-447F-AC27-89E584418135@vpnc.org> <4F357A65.20606@gmail.com> <2fb6766614c157f89a461585dad59cc0.squirrel@www.trepanning.net> <4F3666F2.70004@gmail.com> <20279.59935.562617.387762@fireball.kivinen.iki.fi> In-Reply-To: <20279.59935.562617.387762@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, turners@ieca.com, stephen.farrell@cs.tcd.ie, Dan Harkins , Paul Hoffman Subject: Re: [IPsec] Possible update to isakmp-registry X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 21:53:23 -0000 Hi Tero, yes, the text you quote on IETF Review is acceptable to me. I am basically looking for a process that will allow members of this WG to opine on: - Whether the spec is technically sound, interoperable etc. - Whether the spec is secure. - Whether it is appropriate to add it to IKEv1 (i.e. the spec would not damage adoption of IKEv2 and would not create future issues around migration to IKEv2). These goals are provided by the IETF Review process as defined in 5226, but not by the "lower" criteria. Thanks, Yaron On 02/12/2012 06:34 PM, Tero Kivinen wrote: > Yaron Sheffer writes: >> No surprise at all - I used the term "non-IETF extension". As long as >> your extension goes through proper IETF process/review, I'm fine with >> it. I might even support it, since I agree that it adds security to >> IKEv1/PSK. Other people might argue that we shouldn't confuse the >> industry by adding major new pieces to IKEv1. > > Does that mean thay you would accept "IETF Review", when allocating > new authentication method, but you would NOT accept "specification > required" (or "RFC required", as that include also RFC Editor > Independent submission). > > The "IETF REview" do have proper IETF processes, altought a bit less > than what is for required for "Standards Action. > > I assume the "Standard-track RFC" in the registry actually mean > "Standards Action" in the RFC5226 language. > > The text for IETF Review from the RFC5226 says: > > ---------------------------------------------------------------------- > IETF Review - (Formerly called "IETF Consensus" in > [IANA-CONSIDERATIONS]) New values are assigned only through > RFCs that have been shepherded through the IESG as AD- > Sponsored or IETF WG Documents [RFC3932] [RFC3978]. The > intention is that the document and proposed assignment will > be reviewed by the IESG and appropriate IETF WGs (or > experts, if suitable working groups no longer exist) to > ensure that the proposed assignment will not negatively > impact interoperability or otherwise extend IETF protocols > in an inappropriate or damaging manner. > > To ensure adequate community review, such documents are > shepherded through the IESG as AD-sponsored (or WG) > documents with an IETF Last Call. > ---------------------------------------------------------------------- > > Would that be acceptable for you? > > Would that be acceptable for others? > > That would be acceptable for me, as I just want something bit easier > than current "Standard-Track RFC", i.e. I do not want to add new > Standards to the IKEv1... From paul.hoffman@vpnc.org Mon Feb 13 14:24:28 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C4CD21F868A for ; Mon, 13 Feb 2012 14:24:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24ddQ9pd7C4T for ; Mon, 13 Feb 2012 14:24:28 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D3AFD21F8685 for ; Mon, 13 Feb 2012 14:24:27 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1DMOJ4f018491 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 13 Feb 2012 15:24:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4F398646.60303@gmail.com> Date: Mon, 13 Feb 2012 14:24:18 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <91C691BD-7674-4F43-8E1A-14911216BE81@vpnc.org> References: <20162.16194.361337.415232@fireball.kivinen.iki.fi> <20235.3284.301719.250098@fireball.kivinen.iki.fi> <4F340992.5030502@gmail.com> <372E1EC3-5516-447F-AC27-89E584418135@vpnc.org> <4F357A65.20606@gmail.com> <2fb6766614c157f89a461585dad59cc0.squirrel@www.trepanning.net> <4F3666F2.70004@gmail.com> <20279.59935.562617.387762@fireball.kivinen.iki.fi> <4F398646.60303@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.1257) Cc: ipsec@ietf.org, turners@ieca.com, Dan Harkins , Tero Kivinen , stephen.farrell@cs.tcd.ie Subject: Re: [IPsec] Possible update to isakmp-registry X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 22:24:28 -0000 On Feb 13, 2012, at 1:53 PM, Yaron Sheffer wrote: > yes, the text you quote on IETF Review is acceptable to me. I am = basically looking for a process that will allow members of this WG to = opine on: >=20 > - Whether the spec is technically sound, interoperable etc. > - Whether the spec is secure. > - Whether it is appropriate to add it to IKEv1 (i.e. the spec would = not damage adoption of IKEv2 and would not create future issues around = migration to IKEv2). >=20 > These goals are provided by the IETF Review process as defined in = 5226, but not by the "lower" criteria. I still find this to be too heavy-weight for my tastes, but I may be the = only one who thinks so. --Paul Hoffman From mark.boltz@stonesoft.com Mon Feb 13 15:53:51 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7855021F85D9 for ; Mon, 13 Feb 2012 15:53:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NaxwH-u4+6I for ; Mon, 13 Feb 2012 15:53:49 -0800 (PST) Received: from hki-smtp-1b.stonesoft.com (hki-smtp-1b.stonesoft.com [84.34.144.100]) by ietfa.amsl.com (Postfix) with ESMTP id 23C2A21F858F for ; Mon, 13 Feb 2012 15:53:47 -0800 (PST) Received: from hki-smtp-1b.stonesoft.com (localhost.localdomain [127.0.0.1]) by localhost.stonesoft.com (Postfix) with ESMTP id 7A17D39F00BF; Tue, 14 Feb 2012 01:53:41 +0200 (EET) Received: from outlook.stonesoft.com (unknown [172.16.40.22]) by hki-smtp-1b.stonesoft.com (Postfix) with ESMTP id 6C3F739F00B9; Tue, 14 Feb 2012 01:53:41 +0200 (EET) Received: from HKI-EXC-1.stonesoft.com ([fe80::b914:799e:5fe4:7c73]) by HKI-EXC-2.stonesoft.com ([fe80::400e:df46:3369:4741%14]) with mapi id 14.01.0355.002; Tue, 14 Feb 2012 01:53:44 +0200 From: Mark Boltz To: Stephen Hanna Thread-Topic: [IPsec] NUDGE: Starting work on our new charter items Thread-Index: AQHM3ROI6lryQc3iAUKRSHADDknCmZYmRyGAgAz7bemAB/B6QIAARrUA Date: Mon, 13 Feb 2012 23:53:44 +0000 Message-ID: <227D1A69-36CA-468C-AB54-43A3E653BB1B@stonesoft.com> References: <8CAC2292-8A17-4B38-B2DC-D8A4FDB43CEB@vpnc.org>, <20549DD10769DA47A86F0F0FAF8012DD031BF75CC0@PIACHEVEX00.GCHQ.GOV.UK> <383B3239-76E7-4960-8B1E-5A71F4B5AE52@stonesoft.com> In-Reply-To: Accept-Language: en-US, fi-FI Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.0.52] Content-Type: multipart/alternative; boundary="_000_227D1A6936CA468CAB5443A3E653BB1Bstonesoftcom_" MIME-Version: 1.0 Cc: IPsecme WG , "Ulliott, Chris" , Paul Hoffman Subject: Re: [IPsec] NUDGE: Starting work on our new charter items X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 23:53:51 -0000 --_000_227D1A6936CA468CAB5443A3E653BB1Bstonesoftcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Steve, That sounds good. I look forward to the draft and to participating. With respect to the charter, did we get any copy of the informational docum= ents from, e.g., Cisco and Juniper yet on their proprietary versions? And b= efore I get flamed from anyone at Cisco note that by proprietary I mean "si= ngle vendor"; I recognize your claim that the Cisco approach is "standards = based GRE tunnels + routing protocols + IPsec". So take a deep breath and l= et's look at the charter and get that work done, thanks. Disclaimer: all views/opinions expressed are my own, and not those of my em= ployer unless otherwise stated. -- Mark Boltz, CISSP, CISA, NSA-IEM, CSGI Director, Federal and Mid-Atlantic e: mark.boltz@stonesoft.com e: federal@s= tonesoft.com p: 866.869.4075 c: 571.246.2233 o: 202.434.8963 f: 703.997.4759 w: http://www.stonesoft.com 1200 G St. NW, Suite 800 Washington, DC 20005-6705 Stonesoft: Network Security. Simplified. On Feb 13, 2012, at 12:52 PM, Stephen Hanna wrote: Mark, Thanks for stepping forward to help with the problem statement and with reviewing the various drafts. In order to maximize the open discussion of these drafts, I think it's best to conduct these discussions on the public ipsec email list. Therefore, I'll be posting a first draft of the problem statement ASAP to get some discussion going. For everyone's reference, the updated ipsecme charter is at http://datatracker.ietf.org/wg/ipsecme/charter It now includes this text relating to the scalable VPN work: --------- In an environment with many IPsec gateways and remote clients that share an established trust infrastructure (in a single administrative domain or across multiple domains), customers want to get on-demand point-to-point IPsec capability for efficiency. However, this cannot be feasibly accomplished only with today's IPsec and IKE due to problems with address lookup, reachability, policy configuration, and so on. The IPsecME Working Group will handle this large scale VPN problem by: * Creating a problem statement document including use cases, definitions and proper requirements for discovery and updates. This document would be solution-agnostic. * Publishing a common solution for the discovery and update problems that will satisfy the requirements in the problem statement document. The working group may standardize one of the vendor solutions, a combination, an superset of such a solution, or a new protocol. * Reviewing and help publish Informational documents describing current vendor proprietary solutions. --------- Thanks, Steve -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Mark Boltz Sent: Wednesday, February 08, 2012 11:26 AM To: Ulliott, Chris Cc: IPsecme WG; Paul Hoffman Subject: Re: [IPsec] NUDGE: Starting work on our new charter items I will volunteer to help review the drafts and develop the requirements. How should we approach that sharing? Google, this list, something else? Also, could someone (re-)post the charter with the objectives again, I can't seem to find it. Alternatively send to me directly off list. I look forward to participating. -- Mark Boltz, CISSP, CISA, NSA-IEM, CSGI Director, Federal and Mid-Atlantic e: mark.boltz@stonesoft.com e: federal@stonesoft.com p: 866.869.4075 c: 571.246.2233 o: 202.434.8963 f: 703.997.4759 w: http://www.stonesoft.com 1200 G St. NW, Suite 800 Washington, DC 20005-6705 Stonesoft: Network Security. Simplified. On Jan 31, 2012, at 7:12 AM, "Ulliott, Chris" wrote: Paul - count me in, am more than happy to contribute and help review drafts. Unfortunately getting to Paris could be challenging, but I'll go and talk nicely to the folk who control the purse strings! Chris -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Paul Hoffman Sent: Friday, January 27, 2012 4:49 PM To: IPsecme WG Subject: [IPsec] NUDGE: Starting work on our new charter items [[ There has not been enough response yet, by far. ]] We have a new charter. Do we have any volunteers to start work on the two documents we committed to work on? Related: we should consider having a face-to-face meeting at the upcoming IETF in Paris, but only if there is value for the newly- chartered work. In my mind, that means both a first draft submitted *and* interesting questions that would benefit from face-to-face discussion instead of just work on the list. Do people believe we will have that? --Paul Hoffman _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec *********************************************************************** ***** Communications with GCHQ may be monitored and/or recorded for system efficiency and other lawful purposes. Any views or opinions expressed in this e-mail do not necessarily reflect GCHQ policy. This email, and any attachments, is intended for the attention of the addressee(s) only. Its unauthorised use, disclosure, storage or copying is not permitted. If you are not the intended recipient, please notify postmaster@gchq.gsi.gov.uk. This information is exempt from disclosure under the Freedom of Information Act 2000 and may be subject to exemption under other UK information legislation. Refer disclosure requests to GCHQ on 01242 221491 ext 30306 (non-secure) or email infoleg@gchq.gsi.gov.uk *********************************************************************** ***** The original of this email was scanned for viruses by the Government Secure Intranet virus scanning service supplied by Cable&Wireless Worldwide in partnership with MessageLabs. (CCTM Certificate Number 2009/09/0052.) On leaving the GSi this email was certified virus free. Communications via the GSi may be automatically logged, monitored and/or recorded for legal purposes. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_000_227D1A6936CA468CAB5443A3E653BB1Bstonesoftcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Steve,

That sounds good. I look forward to the draft and to participating.&nb= sp;

With respect to the charter, did we get any copy of the informational = documents from, e.g., Cisco and Juniper yet on their proprietary versions? = And before I get flamed from anyone at Cisco note that by proprietary I mea= n "single vendor"; I recognize your claim that the Cisco approach is "standards based GRE tunnels + r= outing protocols + IPsec". So take a deep breath and let's look at= the charter and get that work done, thanks.

Disclaimer: all views/opinions expressed are my own, and not those of = my employer unless otherwise stated.

--
Mark Boltz, CISSP, CISA, NSA-IEM, CSGI
Director, Federal and Mid-Atlantic
e: mark.boltz@stonesoft.co= m   e: fed= eral@stonesoft.com 
p: 866.869.4075           = ;    c: 571.246.2233
o: 202.434.8963           = ;    f: 703.997.4759
w: http://www.stonesoft.com<= br>
1200 G St. NW, Suite 800
Washington, DC 20005-6705

Stonesoft: Network Security. Simplified.

On Feb 13, 2012, at 12:52 PM, Stephen Hanna wrote:

Mark,

Thanks for stepping forward to help with the problem statement
and with reviewing the various drafts. In order to maximize the
open discussion of these drafts, I think it's best to conduct
these discussions on the public ipsec email list. Therefore,
I'll be posting a first draft of the problem statement ASAP
to get some discussion going.

For everyone's reference, the updated ipsecme charter is at
http://datatrack= er.ietf.org/wg/ipsecme/charter
It now includes this text relating to the scalable VPN work:

---------

In an environment with many IPsec gateways and remote clients that share an established trust infrastructure (in a single administrative domain
or across multiple domains), customers want to get on-demand
point-to-point IPsec capability for efficiency. However, this cannot be
feasibly accomplished only with today's IPsec and IKE due to problems
with address lookup, reachability, policy configuration, and so on.

The IPsecME Working Group will handle this large scale VPN problem by:

* Creating a problem statement document including use cases, definitions and proper requirements for discovery and updates. This document would
be solution-agnostic.

* Publishing a common solution for the discovery and update problems
that will satisfy the requirements in the problem statement document.
The working group may standardize one of the vendor solutions, a
combination, an superset of such a solution, or a new protocol.

* Reviewing and help publish Informational documents describing current
vendor proprietary solutions.

---------

Thanks,

Steve

-----Original Message-----
From: ipsec-bounces@ietf.org [mailto:ipsec-bounce= s@ietf.org] On Behalf
Of Mark Boltz
Sent: Wednesday, February 08, 2012 11:26 AM
To: Ulliott, Chris
Cc: IPsecme WG; Paul Hoffman
Subject: Re: [IPsec] NUDGE: Starting work on our = new charter items

I will volunteer to help review the drafts and de= velop the
requirements. How should we approach that sharing= ? Google, this list,
something else? Also, could someone (re-)post the= charter with the
objectives again, I can't seem to find it. Altern= atively send to me
directly off list.

I look forward to participating.

--
Mark Boltz, CISSP, CISA, NSA-IEM, CSGI
Director, Federal and Mid-Atlantic
e: mark.boltz@stonesoft.com   e: federa= l@stonesoft.com
p: 866.869.4075      &nb= sp;        c: 571.246.2233
o: 202.434.8963      &nb= sp;        f: 703.997.4759
w: http://www.stonesoft.com

1200 G St. NW, Suite 800
Washington, DC 20005-6705

Stonesoft: Network Security. Simplified.

On Jan 31, 2012, at 7:12 AM, "Ulliott, Chris= "
<Chris.Ulliott@cesg.gsi.gov.uk> wrote:

Paul - count me in, am more than happy to contrib= ute and help review
drafts.  Unfortunately getting to Paris coul= d be challenging, but I'll
go and talk nicely to the folk who control the pu= rse strings!

Chris

-----Original Message-----
From: ipsec-bounces@ietf.org [mailto:ipsec-bounce= s@ietf.org] On
Behalf Of Paul Hoffman
Sent: Friday, January 27, 2012 4:49 PM
To: IPsecme WG
Subject: [IPsec] NUDGE: Starting work on our new = charter items

[[ There has not been enough response yet, by far= . ]]

We have a new charter. Do we have any volunteers = to start work on the
two documents we committed to work on?

Related: we should consider having a face-to-face= meeting at the
upcoming IETF in Paris, but only if there is valu= e for the newly-
chartered work. In my mind, that means both a fir= st draft submitted
*and* interesting questions that would benefit fr= om face-to-face
discussion instead of just work on the list. Do p= eople believe we will
have that?

--Paul Hoffman

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


*************************************************= **********************
*****
Communications with GCHQ may be monitored and/or = recorded
for system efficiency and other lawful purposes. = Any views or
opinions expressed in this e-mail do not necessar= ily reflect GCHQ
policy.  This email, and any attachments, is= intended for the
attention of the addressee(s) only. Its unauthori= sed use,
disclosure, storage or copying is not permitted. =  If you are not the
intended recipient, please notify postmaster@gchq= .gsi.gov.uk.

This information is exempt from disclosure under = the Freedom of
Information Act 2000 and may be subject to exempt= ion under
other UK information legislation. Refer disclosur= e requests to
GCHQ on 01242 221491 ext 30306 (non-secure) or em= ail
infoleg@gchq.gsi.gov.uk


*************************************************= **********************
*****


The original of this email was scanned for viruse= s by the Government
Secure Intranet virus scanning service supplied b= y Cable&Wireless
Worldwide in partnership with MessageLabs. (CCTM = Certificate Number
2009/09/0052.) On leaving the GSi this email was = certified virus free.
Communications via the GSi may be automatically l= ogged, monitored
and/or recorded for legal purposes.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--_000_227D1A6936CA468CAB5443A3E653BB1Bstonesoftcom_-- From pwouters@redhat.com Mon Feb 13 18:32:02 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B48D221E8043 for ; Mon, 13 Feb 2012 18:32:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.048 X-Spam-Level: X-Spam-Status: No, score=-101.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bM2KGJZURzJe for ; Mon, 13 Feb 2012 18:32:01 -0800 (PST) Received: from letoams.cypherpunks.ca (unknown [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 3534E21F8733 for ; Mon, 13 Feb 2012 18:32:00 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id 9CDF381933; Mon, 13 Feb 2012 21:33:10 -0500 (EST) Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.5/8.14.5/Submit) with ESMTP id q1E2X9WQ004267; Mon, 13 Feb 2012 21:33:10 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 13 Feb 2012 21:33:09 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Yoav Nir In-Reply-To: <29D7E149-2FD2-4923-8695-84A5EF0E7DE4@checkpoint.com> Message-ID: References: <4F397156.2060102@redhat.com> <29D7E149-2FD2-4923-8695-84A5EF0E7DE4@checkpoint.com> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "ipsec@ietf.org" Subject: Re: [IPsec] iOSX 5.x and IOX Lion's use of UDP_ENCAP problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 02:32:02 -0000 On Mon, 13 Feb 2012, Yoav Nir wrote: >> When using L2TP/IPsec mode with IKEv1, the latest iphones/OSX machines, >> when on public IP, and when no NAT is detected, send UDP_ENCAP packets >> where the inner IP is the same as the outer IP. > I'm not sure I follow you. L2TP/IPSec uses transport mode ESP, so the inner IP is inside the L2TP tunnel. That address is assigned in the IPCP protocol by your gateway. I'm sorry, inner IP and outer IP were a bad choice of words. The devices send an Encapsulation Mode attribute 61443 (private use, but generally known as ENCAPSULATION_MODE_UDP_TUNNEL_DRAFTS) and starts using this ESPinUDP where the UDP header has the same public IP as the encapsulated ESP packet. Normally, clients use their pre-NATed IP address for that. > So what is the issue? In roadwarrior connections, imagine I setup my LAN to be 193.110.157.0/24. My public IP is 1.2.3.4. I now setup a connection using ESPinUDP where I negotiate 193.110.157.101/32 as my address on the ESP packet encapsulated in the UDP packet that has 1.2.3.4. Now I will get all the traffic of www.openswan.org (193.110.157.101) that the remote gateway meant to send to www.openswan.org. For this reason, we try to limit the addresses that can be used to RFC1918 addresses. The OSX bug is causing us to have to allow any public IP address for no good reason, as it should not be using ESPinUDP to begin with when it is on an unfiltered public IP. (though the mention that IKEv2 tells us we need to accept this anyway is unfortunate, so we will have to deal with this anyway) The best openswan can do now, is to allow 0/0 with the exception of its own network and the network it assigns via L2TP. And have another layer of packet inspection to avoid sending traffic to the wrong destinations. (like SAref tracking, or Labeled IPsec) Paul From pwouters@redhat.com Mon Feb 13 20:12:51 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4FC621F84F9 for ; Mon, 13 Feb 2012 20:12:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.048 X-Spam-Level: X-Spam-Status: No, score=-101.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mI3B3SjPC3IY for ; Mon, 13 Feb 2012 20:12:51 -0800 (PST) Received: from letoams.cypherpunks.ca (unknown [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 4520C21F84D5 for ; Mon, 13 Feb 2012 20:12:51 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id EBA5981933; Mon, 13 Feb 2012 23:14:00 -0500 (EST) Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.5/8.14.5/Submit) with ESMTP id q1E4DTOp006141; Mon, 13 Feb 2012 23:13:59 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 13 Feb 2012 23:13:29 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Paul Hoffman In-Reply-To: <74EA2F4C-7259-4D10-8493-D83CE82C4BEB@vpnc.org> Message-ID: References: <4265BC7A-017E-4F23-98E2-FB80E73D8032@checkpoint.com> <4F396FAB.1030708@redhat.com> <74EA2F4C-7259-4D10-8493-D83CE82C4BEB@vpnc.org> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "ipsec@ietf.org" , "dev@openswan.org" , Yoav Nir , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] IKEv2 Traffic Selector narrowing questions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 04:12:51 -0000 On Mon, 13 Feb 2012, Paul Hoffman wrote: >>> There is no reason why the initiator cannot allow any narrowing. This is supposed to be an improvement over IKEv1 where any mismatch in configuration between the peers resulted in failure to set up a tunnel. I realize that this invalidates the concept of a defined tunnel being either "up" or "down". >> >> Right. This is the exact problem I'm trying to handle, and I don't see a good way out. I'm also really afraid people will start demanding I configure 0/0 to them so they can be lazy and I end up with massive overlapping policies to deal with and I won't be able to have more then one vpn up at a time. > > If the problem is "the application knows the exact tunnel it needs", then the solution is that if the responder narrows the tunnel, the IPsec stack tells the application "you never got a tunnel". Okay, so in that context, reading section 2.9: To enable the responder to choose the appropriate range in this case, if the initiator has requested the SA due to a data packet, the initiator SHOULD include as the first Traffic Selector in each of TSi and TSr a very specific Traffic Selector including the addresses in the packet triggering the request. Am I right that it is valid to not send the first TSi/TSr of the packet that triggered the IKE initiation? > IKEv2 was designed around the idea of gateways being the ones that control the tunnel properties, thus avoiding the API issues to applications. If you give me a $vendorbox at home to handle the VPN for me, and my box initiates a connection to the mothership, and it narrows it down to half of it, me on my laptop still have no idea why my connection is failing if it trying to hit the other half. I do see the use case where you configure a 0/0 on my $vendorbox and it sets up narrow SAs to the mothership for those addresses is would like to receive, as those indeed do change depending on mothership expansion. So I do think we should support this, but I do think the default of this should be "off". I'll think about how to relay this information back to the user. With NetworkManager integration, this should be possible. Thanks for everyone's input on this, Paul From kivinen@iki.fi Tue Feb 14 06:13:20 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10F4221F8754 for ; Tue, 14 Feb 2012 06:13:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyVmC6aZ1qTE for ; Tue, 14 Feb 2012 06:13:18 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3723121F8750 for ; Tue, 14 Feb 2012 06:13:17 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id q1EECwjk010265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Feb 2012 16:12:58 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id q1EECuAg010698; Tue, 14 Feb 2012 16:12:56 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20282.27624.183320.589559@fireball.kivinen.iki.fi> Date: Tue, 14 Feb 2012 16:12:56 +0200 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: <4265BC7A-017E-4F23-98E2-FB80E73D8032@checkpoint.com> <4F396FAB.1030708@redhat.com> <74EA2F4C-7259-4D10-8493-D83CE82C4BEB@vpnc.org> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 44 min X-Total-Time: 43 min Cc: "ipsec@ietf.org" , "dev@openswan.org" , Yoav Nir , Paul Hoffman , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] IKEv2 Traffic Selector narrowing questions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 14:13:20 -0000 Paul Wouters writes: > On Mon, 13 Feb 2012, Paul Hoffman wrote: > > >>> There is no reason why the initiator cannot allow any narrowing. > >>> This is supposed to be an improvement over IKEv1 where any > >>> mismatch in configuration between the peers resulted in failure > >>> to set up a tunnel. I realize that this invalidates the concept > >>> of a defined tunnel being either "up" or "down". I think your problem is as you think it as concept of "tunnel" being up or down, it would be better to think it as "VPN connection" as defined by "IKEv2 SA" being up or down. I.e. immediatley when you get your first IKEv2 SA (and Child SA) negotiated with the other end your VPN is up. You can now send traffic through that VPN connection to the other end. If there is no Child SA suitable for the traffic defined in the policy, you use IKEv2 SA to create it and send it forward using that Child SA. If that Child SA is not allowed by remote policy, then you drop the packet (and that means you have mismatching policies between the two hosts). You do not need to have all possible SAs you could negotiate with that specific policy up, before you should consider your VPN being up. > >> Right. This is the exact problem I'm trying to handle, and I > >> don't see a good way out. I'm also really afraid people will > >> start demanding I configure 0/0 to them so they can be lazy and I > >> end up with massive overlapping policies to deal with and I won't > >> be able to have more then one vpn up at a time. Unfortunately people are lazy, and quite many system adminstrators want to do exactly that. I myself think 0/0 and ::/0 polices are bad and should not be used, especially as it requires special handling so that your "local network" packets still get sent locally and not sent to the VPN tunnel (for example the http-login page, your dhcp packets, etc). But that seems to be something that system adminstrators want so you might need to implement it anyways. > > If the problem is "the application knows the exact tunnel it > > needs", then the solution is that if the responder narrows the > > tunnel, the IPsec stack tells the application "you never got a > > tunnel". The tunnel is there, it is not just yet actually formed. When you send first packet trying the head to that tunnel it will get automatically created (provided it is allowed by policy). > Okay, so in that context, reading section 2.9: > > To enable the responder to choose the appropriate range in this case, > if the initiator has requested the SA due to a data packet, the > initiator SHOULD include as the first Traffic Selector in each of TSi > and TSr a very specific Traffic Selector including the addresses in > the packet triggering the request. > > Am I right that it is valid to not send the first TSi/TSr of the > packet that triggered the IKE initiation? It is ok not to send the information about the packet if you do not have it. If you have it the RFC says you SHOULD send it. If you do not send it, then other end is STILL allowed to narrow the SA down to whather it thinks it wants the SA to be, but as it does not have any information for which of the possible subsets of the initiators proposal it should narrow to, it might take something that is not useful for the initiator. In that case the responder can also send ADDITIONAL_TS_POSSIBLE notification telling that there would be another possible SA that would more SAs which could be created using the same TS set. > If you give me a $vendorbox at home to handle the VPN for me, and my > box initiates a connection to the mothership, and it narrows it down > to half of it, me on my laptop still have no idea why my connection > is failing if it trying to hit the other half. Your connection is not failing, as when you hit the other half, the IPsec will automatically trigger the IKEv2 CREATE_CHILD_SA exchange and create another SA for that second half. The connection would only fail if you would try to create SA that is NOT allowed by the responder's policy. > I do see the use case where you configure a 0/0 on my $vendorbox and > it sets up narrow SAs to the mothership for those addresses is would > like to receive, as those indeed do change depending on mothership > expansion. So I do think we should support this, but I do think the > default of this should be "off". I'll think about how to relay this > information back to the user. With NetworkManager integration, this > should be possible. Note, that responder is ALWAYS allowed to narrow the TS proposed by the initiator. There is no way to disable that. This is mandatory feature of the IKEv2. The responder does not need to support narrowing itself, but the initiator MUST be able to handle the case where responder decided to narrow the TS. Also you SHOULD always send the data from the packet as first TS if you have packet which triggered the negotiation, as this allows responder to do intelligent and useful narrowing. Lets take an example. The HQ has 10.0.0.0/8 network configured, but because of the adminstrative reasons it is always split up to 10.x.y.0/24 networks. For example each user is given access permission per /24 network, and thats why the gateway is always configured not to allow any subnet larger than /24 in one Child SA. The VPN client wants to connect to the HQ, and in the startup creates the IKEv2 connection to the HQ server. It sends remote TS as: TSi = 192.168.2.11 TSr = 10.0.0.0-10.255.255.255 without the data from packet as it does this on the startup and there is no packet. The server will narrow that down to some 10.x.y.0/24 network, lets say it just takes the first network, i.e. sends narrowed TS back: TSi = 192.168.2.11 TSr = 10.0.0.0-10.0.0.255 N(ADDITIONAL_TS_POSSIBLE) it adds ADDITIONAL_TS_POSSIBLE notification as there would be more SAs that would be possible for the TS initiator proposed. The VPN client now has the VPN connection up to the HQ. Next VPN client tries to start reading email from the mail.hq.example.com. It first connects to the dns server 10.0.0.1 to find out the IP-address of mail.dep1.example.com. This packet goes through the Child SA created in the first step, and it gets reply back saying that dep1 mail server is at the 10.0.22.4. (the 10.0.22.0/24 happen to be the dep1 service network). Now the VPN client tries to send packet to 10.0.22.4 port 25, and notices there is no Child SA for it, but it is allowed by the local policy, so it will trigger new CREATE_CHILD_SA negotiation and sends TS: TSi: TCP,3233,192.168.2.11 192.168.2.11 TSr: TCP,25,10.0.22.4 10.0.0.0-10.255.255.255 sending 2 TS payloads, one for the exact data from the packet, another for the generic policy. The gateway will see this, and will narrow the proposed list into the subset allowed by its policy and making sure the first traffic selector is included in its response. So it will reply with traffic selectors saying: TSi: 192.168.2.11 TSr: 10.0.22.0-10.0.22.255 Note, that it did remove the first initiators traffic selectors, as they are already included in the traffic selectors it responded. Also it did include full 10.0.22.0/24 network as this is what policy says. It does not need to include the ADDITIONAL_TS_POSSIBLE as it was able to fullfill the requirement that the first TS fits in to the returned SA and after fullfilling that requirement there was only one subset which was allowed, i.e. if the client would resend that same TS set again, it would create exactly same (and only that) response back. There would not be any other possible answer from the server. Next if VPN client tries to connect to the some other network which it is not allowed to i.e. tries to connect to the 10.0.23.4 it tries with another CREATE_CHILD_SA exchange with traffic selectors: TSi: TCP,2323,192.168.2.11 192.168.2.11 TSr: TCP,80,10.0.23.4 10.0.0.0-10.255.255.255 Now the HQ SGW says that this user is NOT allowed to connect to the 10.0.23.0/24 network, and sgw starts processing the operations as defined in the RFC5996: ---------------------------------------------------------------------- The responder performs the narrowing as follows: o If the responder's policy does not allow it to accept any part of the proposed Traffic Selectors, it responds with a TS_UNACCEPTABLE Notify message. o If the responder's policy allows the entire set of traffic covered by TSi and TSr, no narrowing is necessary, and the responder can return the same TSi and TSr values. o If the responder's policy allows it to accept the first selector of TSi and TSr, then the responder MUST narrow the Traffic Selectors to a subset that includes the initiator's first choices. In this example above, the responder might respond with TSi being (198.51.100.43 - 198.51.100.43) with all ports and IP protocols. o If the responder's policy does not allow it to accept the first selector of TSi and TSr, the responder narrows to an acceptable subset of TSi and TSr. ---------------------------------------------------------------------- It notices, that yes, it would be able to allow some parts of the TS, so it will not reply with TS_UNACCEPTABLE. Then it checks whether it can allow the whole set, and finds out that it cannot, so it needs to do narrowing. The next check fails also, as it notices that it cannot allow this users to access the 10.0.23.4 machine, so it cannot do intelligent narrowing. Now it is left ot the last option. I.e. it needs to narrow this down to something that will not be useful for the user. Which of the possible subsets it takes is completely implementation dependant. It might take the same way out it took when you created the first SA, i.e. return 10.0.0.0-10.0.0.255. Or it might intelligently notice that you already have Child SA for that range, so lets not create overlapping range, lets take next one from the policy which is not already covered by the SAs we have. The next one might be 10.0.22.0-10.0.22.255, which it also have. The next one after that might be 10.0.44.0-10.0.44.255, so it might return TSi: 192.168.2.11 TSr: 10.0.44.0-10.0.44.255 N(ADDITIONAL_TS_POSSIBLE) and add the ADDITIONAL_TS_POSSIBLE as there is still more possible subsets it has not yet used. Anyways the responder will see that the trigger for the packet did create Child SA, but when it tries to send packet again, it will not find usable Child SA for it, so it might trigger again. Normally you would not want it to go to loop to creating multiple exachanges, so you would have some kind of negative cache marking that this kind of packet triggered already lately, so do not trigger again for similar packets for next n seconds. This last part of the processing is not really very clean, it would be better if there would be clean error code returned by the responder, but as the data from the packet was added bit late to the IKEv2 specification, we didn't want to change the TS format to add for example a bit for it, but instead hacked it in as being first TS in the list. Also as some people considered it important to allow NOT sending the data from packet, we cannot mandate it always being there, so there is no real way for responder knowing whether it is there or not, and special processing depending whether it is there or not is not done. As this last case is anyways failure case, where the there either is policy mismatch or the user is trying to do something he is not allowed (i.e. attack), this is not very common case and thats why there might not be need to "optimize" that corner case. -- kivinen@iki.fi From kivinen@iki.fi Tue Feb 14 06:45:38 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD8121F877E for ; Tue, 14 Feb 2012 06:45:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.283 X-Spam-Level: X-Spam-Status: No, score=-102.283 tagged_above=-999 required=5 tests=[AWL=-0.284, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pWuKk11n2Uh for ; Tue, 14 Feb 2012 06:45:37 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3BE921F8776 for ; Tue, 14 Feb 2012 06:45:36 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id q1EEjV4K029789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Feb 2012 16:45:31 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id q1EEjUuT001410; Tue, 14 Feb 2012 16:45:30 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=unknown Content-Transfer-Encoding: quoted-printable Message-ID: <20282.29578.645732.514715@fireball.kivinen.iki.fi> Date: Tue, 14 Feb 2012 16:45:30 +0200 From: Tero Kivinen To: Timothy Carlin In-Reply-To: <80C0FB1A-03C7-46FB-89BB-D815B2DFD0B4@iol.unh.edu> References: <80C0FB1A-03C7-46FB-89BB-D815B2DFD0B4@iol.unh.edu> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 25 min X-Total-Time: 31 min Cc: IPsecme WG Subject: [IPsec] IKEv2 Traffic Selectors X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 14:45:38 -0000 Timothy Carlin writes: > Hello, >=20 > During testing, the UNH-IOL has encountered a behavior with regards > to the handling of Traffic Selectors that causes interoperability > issues. >=20 > The issue center around the handling of this quote from RFC 5996, > Section 2.9: >=20 > =93To enable the responder to choose the appropriate range in this c= ase, > if the initiator has requested the SA due to a data packet, the > initiator SHOULD include as the first Traffic Selector in each of TS= i > and TSr a very specific Traffic Selector including the addresses in > the packet triggering the request.=94 >=20 >=20 > We've seen that implementations acting as the responder handle the > Very Specific Traffic Selector in different ways, resulting in > non-interoperability. Some implementations reject the connection, > due to not matching configured selectors, while other > implementations accept only this traffic selector, inadvertently > narrowing the tunnel. Both of these types of implementation are not really following the spirit of the IKEv2 RFC. The ones who reject the connection, only support startup style SAs, and nothing else (which is allowed by IKEv2, but it is very limited implementation). The others which only accept only this traffic selectors, usually are limited to exactly one traffic selector, i.e. they do not support multiple traffic selectors (which again is allowed by IKEv2, but again is very limited implementation). I would myself consider both of them as broken IKEv2 implementations, and not to be used outside the very specific scenarios. Most of these are IKEv1 implementations hacked to support IKEv2 very quickly and in their hacking they didn't want to support multiple traffic selectors in the same SA, as that would change the IPsec packet engine also. > This also causes a detrimental oddity when the data packet causing > SA creation is an ICMPv6 Echo Request. In this case, both TSi and > TSr indicate ICMPv6, type 80, Code 00. This is a special case, > since ICMP has no source and destination port. What should the > proper behavior be for a packet type with no source and destination > port=3F The RFC4301 section 4.4.1.3 has text about the ICMP "port" selectors, but that text really only covers the policy parts. When filling up the data from the packet information to the TS, this is not that much applicable, but on the other hand the first TS is also matched against the local policy, so they should be compatible. For the first TS matching the packet, I think best would be to use both src and dst "port" selectors as same value, i.e. copy the value to both fields. On the other hand reading 4.4.1.3 and matching the case C and D: ---------------------------------------------------------------------- C. If a system is willing to send traffic with a particular "port" value but NOT receive traffic with that kind of port value, the system's traffic selectors are set as follows in the relevant SPD entry: Local's next layer protocol =3D ICMP "port" selector =3D Remote's next layer protocol =3D ICMP "port" selector =3D OPAQUE D. To indicate that a system is willing to receive traffic with a particular "port" value but NOT send that kind of traffic, the system's traffic selectors are set as follows in the relevant SPD entry: Local's next layer protocol =3D ICMP "port" selector =3D OPAQUE Remote's next layer protocol =3D ICMP "port" selector =3D For example, if a security gateway is willing to allow systems behind it to send ICMP traceroutes, but is not willing to let outside systems run ICMP traceroutes to systems behind it, then the security gateway's traffic selectors are set as follows in the relevant SPD entry: Local's next layer protocol =3D 1 (ICMPv4) "port" selector =3D 30 (traceroute) Remote's next layer protocol =3D 1 (ICMPv4) "port" selector =3D OPAQUE ---------------------------------------------------------------------- (I.e. Local =3D> incoming from the clear side, going to the SA, remote =3D> incoming from SA, going to the clear side).=20 This would mean that if SGW has policy that allows clients to ping it but not anything behind the SGW to ping out that would be the case C, i.e. SGWs Local's policy part would say ICMP echo request and that would match the incoming TSr, and the SGWs Remote's policy part would say OPAQUE (i.e. TSi). For the normal narrowing rules to work this would require the initiator system to use: TSi=3DICMP, OPAQUE TSr=3DICMP, echo request I.e that would match the C case and would also case the case where the SGWs policy says TSi=3DICMP, ANY, TSr=3DICMP, ANY. If you do what I proposed earlier by putting both TSi and TSr same echo request, that would not match the OPAQUE, and the policy negotiation would fail. On the other hand using OPAQUE might cause other implementations to fail... That is if I read the RFC4301 properly... On the other hand how many implementations have really implemented that part of the ICMP filtering, I think most of the implementations do not really care about the ICMP type and code, and am not sure how many really implement ICMP OPAQUE parts... > The UNH-IOL would very much appreciate any thoughts the Working > Group might have regarding this behavior!=20 --=20 kivinen@iki.fi From kivinen@iki.fi Thu Feb 16 06:12:04 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C67A321F8794 for ; Thu, 16 Feb 2012 06:12:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwCPDZspIIjN for ; Thu, 16 Feb 2012 06:12:00 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id B851821F8697 for ; Thu, 16 Feb 2012 06:11:59 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id q1GEBlPH021761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Feb 2012 16:11:47 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id q1GEBkX6018609; Thu, 16 Feb 2012 16:11:46 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20285.3746.270920.626776@fireball.kivinen.iki.fi> Date: Thu, 16 Feb 2012 16:11:46 +0200 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: <4F397156.2060102@redhat.com> <29D7E149-2FD2-4923-8695-84A5EF0E7DE4@checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 25 min X-Total-Time: 33 min Cc: "ipsec@ietf.org" , Yoav Nir Subject: Re: [IPsec] iOSX 5.x and IOX Lion's use of UDP_ENCAP problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 14:12:05 -0000 Paul Wouters writes: > On Mon, 13 Feb 2012, Yoav Nir wrote: > > >> When using L2TP/IPsec mode with IKEv1, the latest iphones/OSX machines, > >> when on public IP, and when no NAT is detected, send UDP_ENCAP packets > >> where the inner IP is the same as the outer IP. > > > I'm not sure I follow you. L2TP/IPSec uses transport mode ESP, so > > the inner IP is inside the L2TP tunnel. That address is assigned > > in the IPCP protocol by your gateway. > > I'm sorry, inner IP and outer IP were a bad choice of words. > > The devices send an Encapsulation Mode attribute 61443 (private use, but > generally known as ENCAPSULATION_MODE_UDP_TUNNEL_DRAFTS) and starts > using this ESPinUDP where the UDP header has the same public IP as the > encapsulated ESP packet. Normally, clients use their pre-NATed IP > address for that. Are you really telling me they are using a private numbers from the internet draft that expired more than 10 years ago, and which is not compatible with the RFC3947 (which (which was published January 2005, i.e. 7 years ago). Also note that those private numbers were only present up until draft-ietf-ipsec-nat-t-ike version 04 and they were removed at the 05 version as the NAT-T protocol changed in the incompatible way, i.e the NAT-T protocol used when using those private numbers is different than what is defined in the RFC3947. Does what you said above mean, that they do not support RFC3947 at all? Or it is just that they send multiple vendor IDs for NAT-T and other end happened to select some vendor id based on some draft, not the RFC version? If it is the latter, just make sure your implementations prefer the RFC version instead of the draft version (or think about removing the draft versions completely, they are not really supposed to be out there anymore). In the later RFCs (i.e. IKEv2 NAT-T) it was explicitly mentioned that both ends can enable NAT-T even when no nat is found, so that kind of usage is completly legal for those setups. The RFC3947 says that if there is no NAT between (i.e. inner and outer IP are same) then: If there is no NAT box between, there is no point in wasting bandwidth by adding UDP encapsulation of packets. Thus, UDP- Encapsulation SHOULD NOT be used. I.e. it is SHOULD NOT, which means you still might need to support receiving UPD encapsulated ESP packets even when you do not have NAT between. > > So what is the issue? > > In roadwarrior connections, imagine I setup my LAN to be > 193.110.157.0/24. My public IP is 1.2.3.4. I now setup a connection > using ESPinUDP where I negotiate 193.110.157.101/32 as my address on > the ESP packet encapsulated in the UDP packet that has 1.2.3.4. Now > I will get all the traffic of www.openswan.org (193.110.157.101) that > the remote gateway meant to send to www.openswan.org. For this reason, > we try to limit the addresses that can be used to RFC1918 addresses. This kind of limitations are not part of the IPsec. They can be part of the default policy, but must be specified in the policy. I.e. if the policy says other end can only has inner IP address of 10.0.0.0/8 then that limits what other end can do. If there is no such policy then everything is allowed. > The OSX bug is causing us to have to allow any public IP address for > no good reason, as it should not be using ESPinUDP to begin with > when it is on an unfiltered public IP. (though the mention that > IKEv2 tells us we need to accept this anyway is unfortunate, so we > will have to deal with this anyway) I am not sure it is bug in OSX, as there might be completely valid reasons why they decide to go against that SHOULD in the RFC3947. On the other hand if they used the some old internet draft version of the NAT-T, I do not have any idea whether that allowed it or not (and I am not interested to read 10 year old drafts just to find out what those now expired drafts said the now obsoleted protocol might want to do). > The best openswan can do now, is to allow 0/0 with the exception of its > own network and the network it assigns via L2TP. And have another layer > of packet inspection to avoid sending traffic to the wrong destinations. > (like SAref tracking, or Labeled IPsec) How does this differ from using normal tunnel mode ESP? If the other end creates SA which selectors overlap some public addresses, you need to do exactly same checks. On the other hand it does not really matter if you forward all openswan.org traffic to the tunnel unless you happen to be router processing openswan.org traffic. In normal case the openswan.org traffic does not come to your SGW at all. Normally allowing other end to claim to be any IP-address is considered bad for anyways, but restricting them to only steal private address does not help. So even if you have setup which says the addresses inside the tunnel must be from RFC1918 address spaces, that would still allow client to steal traffic intended for some other client, or to your local network. I think I must be missing something in your scenario. -- kivinen@iki.fi From ynir@checkpoint.com Thu Feb 16 06:29:08 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2E7421F871D for ; Thu, 16 Feb 2012 06:29:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.462 X-Spam-Level: X-Spam-Status: No, score=-10.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhjcVPQJaVOo for ; Thu, 16 Feb 2012 06:29:07 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id EFABB21F8700 for ; Thu, 16 Feb 2012 06:29:06 -0800 (PST) X-CheckPoint: {4F3D0EC9-0-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q1GET5Ia007411; Thu, 16 Feb 2012 16:29:05 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 16 Feb 2012 16:29:04 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Thu, 16 Feb 2012 16:29:02 +0200 From: Yoav Nir To: Tero Kivinen Date: Thu, 16 Feb 2012 16:29:05 +0200 Thread-Topic: [IPsec] iOSX 5.x and IOX Lion's use of UDP_ENCAP problem Thread-Index: Aczst1Q1X7qRKbyvTBK2Q0cWa3z6DA== Message-ID: <0F43FB4F-4917-4CFC-ACCF-E36599DF16E7@checkpoint.com> References: <4F397156.2060102@redhat.com> <29D7E149-2FD2-4923-8695-84A5EF0E7DE4@checkpoint.com> <20285.3746.270920.626776@fireball.kivinen.iki.fi> In-Reply-To: <20285.3746.270920.626776@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "ipsec@ietf.org" , Paul Wouters Subject: Re: [IPsec] iOSX 5.x and IOX Lion's use of UDP_ENCAP problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 14:29:08 -0000 On Feb 16, 2012, at 4:11 PM, Tero Kivinen wrote: > Paul Wouters writes: >> On Mon, 13 Feb 2012, Yoav Nir wrote: >>=20 >>>> When using L2TP/IPsec mode with IKEv1, the latest iphones/OSX machines= , >>>> when on public IP, and when no NAT is detected, send UDP_ENCAP packets >>>> where the inner IP is the same as the outer IP. >>=20 >>> I'm not sure I follow you. L2TP/IPSec uses transport mode ESP, so >>> the inner IP is inside the L2TP tunnel. That address is assigned >>> in the IPCP protocol by your gateway.=20 >>=20 >> I'm sorry, inner IP and outer IP were a bad choice of words. >>=20 >> The devices send an Encapsulation Mode attribute 61443 (private use, but >> generally known as ENCAPSULATION_MODE_UDP_TUNNEL_DRAFTS) and starts >> using this ESPinUDP where the UDP header has the same public IP as the >> encapsulated ESP packet. Normally, clients use their pre-NATed IP >> address for that. >=20 > Are you really telling me they are using a private numbers from the > internet draft that expired more than 10 years ago, and which is not > compatible with the RFC3947 (which (which was published January 2005, > i.e. 7 years ago). They don't always do that. But looking at their MainMode packet 1 in wiresh= ark, They send the following VIDs: - RFC 3947 Negotiation of the NAT-Traversal in the IKE - draft-ietf-ipsec-nat-t-ike - draft-ietf-ipsec-nat-t-ike-08 - draft-ietf-ipsec-nat-t-ike-07 - draft-ietf-ipsec-nat-t-ike-06 - draft-ietf-ipsec-nat-t-ike-05 - draft-ietf-ipsec-nat-t-ike-04 - draft-ietf-ipsec-nat-t-ike-03 - draft-ietf-ipsec-nat-t-ike-02 - draft-ietf-ipsec-nat-t-ike-02\n - RFC 3706 DPD (Dead Peer Detection) I guess what they later do depends on what VID they get in the reply. There= were quite a few versions of Windows server that returned 90cb80=85427b1f = (draft-ietf-ipsec-nat-t-ike-02\n), so maybe Paul's implementation was a sur= prise for iOS. From pwouters@redhat.com Thu Feb 16 06:42:15 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E88521F871C for ; Thu, 16 Feb 2012 06:42:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.048 X-Spam-Level: X-Spam-Status: No, score=-101.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oziyC9yorST9 for ; Thu, 16 Feb 2012 06:42:14 -0800 (PST) Received: from letoams.cypherpunks.ca (unknown [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id C81A221F8715 for ; Thu, 16 Feb 2012 06:42:14 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id 481C08198D; Thu, 16 Feb 2012 09:43:19 -0500 (EST) Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.5/8.14.5/Submit) with ESMTP id q1GEhHsc001103; Thu, 16 Feb 2012 09:43:18 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 16 Feb 2012 09:43:17 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Yoav Nir In-Reply-To: <0F43FB4F-4917-4CFC-ACCF-E36599DF16E7@checkpoint.com> Message-ID: References: <4F397156.2060102@redhat.com> <29D7E149-2FD2-4923-8695-84A5EF0E7DE4@checkpoint.com> <20285.3746.270920.626776@fireball.kivinen.iki.fi> <0F43FB4F-4917-4CFC-ACCF-E36599DF16E7@checkpoint.com> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=UTF-8 Content-Transfer-Encoding: 8BIT Cc: "ipsec@ietf.org" , Tero Kivinen Subject: Re: [IPsec] iOSX 5.x and IOX Lion's use of UDP_ENCAP problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 14:42:15 -0000 On Thu, 16 Feb 2012, Yoav Nir wrote: >> Are you really telling me they are using a private numbers from the >> internet draft that expired more than 10 years ago, and which is not >> compatible with the RFC3947 (which (which was published January 2005, >> i.e. 7 years ago). > > They don't always do that. But looking at their MainMode packet 1 in wireshark, They send the following VIDs: > - RFC 3947 Negotiation of the NAT-Traversal in the IKE > - draft-ietf-ipsec-nat-t-ike > - draft-ietf-ipsec-nat-t-ike-08 > - draft-ietf-ipsec-nat-t-ike-07 > - draft-ietf-ipsec-nat-t-ike-06 > - draft-ietf-ipsec-nat-t-ike-05 > - draft-ietf-ipsec-nat-t-ike-04 > - draft-ietf-ipsec-nat-t-ike-03 > - draft-ietf-ipsec-nat-t-ike-02 > - draft-ietf-ipsec-nat-t-ike-02\n > - RFC 3706 DPD (Dead Peer Detection) > > I guess what they later do depends on what VID they get in the reply. There were quite a few versions of Windows server that returned 90cb80…427b1f (draft-ietf-ipsec-nat-t-ike-02\n), so maybe Paul's implementation was a surprise for iOS. I'll make sure this is not an implementation issue on our side. Did any large deployment switch to removing all the draft VIDs? If so, how many problems did that cause? I'd be happy to remove the ancient drat cruft, especially if it increases interoperability. Paul From ynir@checkpoint.com Thu Feb 16 06:49:33 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B50621F87A1 for ; Thu, 16 Feb 2012 06:49:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.468 X-Spam-Level: X-Spam-Status: No, score=-10.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8M7QNzl3iHET for ; Thu, 16 Feb 2012 06:49:32 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id B3F4121F8789 for ; Thu, 16 Feb 2012 06:49:31 -0800 (PST) X-CheckPoint: {4F3D1391-2-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q1GEnTcR013614; Thu, 16 Feb 2012 16:49:29 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 16 Feb 2012 16:49:29 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Thu, 16 Feb 2012 16:49:29 +0200 From: Yoav Nir To: Paul Wouters Date: Thu, 16 Feb 2012 16:49:32 +0200 Thread-Topic: [IPsec] iOSX 5.x and IOX Lion's use of UDP_ENCAP problem Thread-Index: Aczsui94ekPN3/LOSfqPLQJS6HL5pg== Message-ID: References: <4F397156.2060102@redhat.com> <29D7E149-2FD2-4923-8695-84A5EF0E7DE4@checkpoint.com> <20285.3746.270920.626776@fireball.kivinen.iki.fi> <0F43FB4F-4917-4CFC-ACCF-E36599DF16E7@checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "ipsec@ietf.org" , Tero Kivinen Subject: Re: [IPsec] iOSX 5.x and IOX Lion's use of UDP_ENCAP problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 14:49:33 -0000 On Feb 16, 2012, at 4:43 PM, Paul Wouters wrote: > On Thu, 16 Feb 2012, Yoav Nir wrote: >=20 >>> Are you really telling me they are using a private numbers from the >>> internet draft that expired more than 10 years ago, and which is not >>> compatible with the RFC3947 (which (which was published January 2005, >>> i.e. 7 years ago). >>=20 >> They don't always do that. But looking at their MainMode packet 1 in wir= eshark, They send the following VIDs: >> - RFC 3947 Negotiation of the NAT-Traversal in the IKE >> - draft-ietf-ipsec-nat-t-ike >> - draft-ietf-ipsec-nat-t-ike-08 >> - draft-ietf-ipsec-nat-t-ike-07 >> - draft-ietf-ipsec-nat-t-ike-06 >> - draft-ietf-ipsec-nat-t-ike-05 >> - draft-ietf-ipsec-nat-t-ike-04 >> - draft-ietf-ipsec-nat-t-ike-03 >> - draft-ietf-ipsec-nat-t-ike-02 >> - draft-ietf-ipsec-nat-t-ike-02\n >> - RFC 3706 DPD (Dead Peer Detection) >>=20 >> I guess what they later do depends on what VID they get in the reply. Th= ere were quite a few versions of Windows server that returned 90cb80=85427b= 1f (draft-ietf-ipsec-nat-t-ike-02\n), so maybe Paul's implementation was a = surprise for iOS. >=20 > I'll make sure this is not an implementation issue on our side. >=20 > Did any large deployment switch to removing all the draft VIDs? If so, > how many problems did that cause? I'd be happy to remove the ancient > drat cruft, especially if it increases interoperability. Our implementation supports the RFC and "draft-02\n", which is what Microso= ft clients added in some service pack of XP. We reply according to the las= t recognized NAT-T VID, which in this case is the draft-02\n one.=20 When we do this, we don't get any weird encapsulation modes like you do. D= o you reply with the RFC one? Yoav From iana-shared@icann.org Thu Feb 16 10:49:13 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2110E11E8074 for ; Thu, 16 Feb 2012 10:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.693 X-Spam-Level: X-Spam-Status: No, score=-0.693 tagged_above=-999 required=5 tests=[AWL=0.614, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSMYW2M2f5xW for ; Thu, 16 Feb 2012 10:49:08 -0800 (PST) Received: from pechora8.dc.icann.org (unknown [IPv6:2620:0:2830:201::1:74]) by ietfa.amsl.com (Postfix) with ESMTP id 55DF621F87E9 for ; Thu, 16 Feb 2012 10:49:08 -0800 (PST) Received: from request1.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by pechora8.dc.icann.org (8.13.8/8.13.8) with ESMTP id q1GImgVm008270; Thu, 16 Feb 2012 13:49:02 -0500 Received: from request1.lax.icann.org (localhost.localdomain [127.0.0.1]) by request1.lax.icann.org (8.13.8/8.13.8) with ESMTP id q1GImgJN008156; Thu, 16 Feb 2012 18:48:42 GMT Received: (from apache@localhost) by request1.lax.icann.org (8.13.8/8.13.8/Submit) id q1GImeGc008151; Thu, 16 Feb 2012 18:48:41 GMT From: "Pearl Liang via RT" In-Reply-To: References: <20162.16194.361337.415232@fireball.kivinen.iki.fi> Message-ID: Precedence: bulk X-RT-Loop-Prevention: IANA RT-Ticket: IANA #111200 Managed-by: RT 3.8.HEAD (http://www.bestpractical.com/rt/) RT-Originator: pearl.liang@icann.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Date: Thu, 16 Feb 2012 18:48:40 +0000 X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.3 (pechora8.dc.icann.org [192.0.46.74]); Thu, 16 Feb 2012 13:49:04 -0500 (EST) Cc: ipsec@ietf.org, turners@ieca.com, liang@icann.org, kivinen@iki.fi, stephen.farrell@cs.tcd.ie Subject: [IPsec] [IANA #111200] [old message] Possible update to isakmp-registry X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Reply-To: iana-matrix@iana.org List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 18:49:13 -0000 Hi, Tero, Thank you for the reply. Please see comments marked with [pl]. On Fri Feb 10 14:00:28 2012, kivinen@iki.fi wrote: > Pearl Liang via RT writes: > > - For Registry Name: IPSEC Authentication Methods (Value 3) > > > Registry Name: IPSEC Authentication Methods (Value 3) > > > Current: Standards-track RFC > > > > > > There is nothing about this in the RFC2409, so I would say either "RFC > > > required" or "Specification required" would be ok. There is draft > > > http://tools.ietf.org/html/draft-harkins-ike-iana-update-00 already > > > proposing this change. > > > > Question1: since a new document is in work to update this, > > the registration procedures will be updated when the document is made > > to IETF Last call. Would it be okay to not change the listed > > registration procedures at this time? > > As there seems to be different opinions about this in the IPsecME WG, > I think it might be better to leave this for now, and then we can work > on that issue by using the draft-harkins-ike-iana-update document as > our placeholder. > > I myself do think that as the current Standards-track RFC requirement > is not mentioned in any RFCs, we do not necessarely need RFC to change > it (and I think publishing RFC just to change one unspecified > registration policy is not really needed). > > On the other hand we do need to have concencus on the issue among the > working group, so after we reach that, we can come back to you, > regardless whether we publish separate document about that issue or > not (which is separate issue we need to decide). > > So leave it as it is for now, and we work on this issue in the IPsecME > WG. > [pl] No action. > > - For Registry Name: PRF (Value 13) > > > Registry Name: PRF (Value 13) > > > Current: Standards-track or Informational RFC > > > > > > There is nothing about this in the RFC2409, so I would say either "RFC > > > required" or "Specification required" would be ok. > > > > > > > Question2: Would it be sufficient to list "RFC required" only? > > Yes that would also be acceptable, but "Specification required" would > be more inline with other cryptographic algorithms specified in the > RFC2409 (encryption algorithm, hash algorithm etc), so I would prefer > "Specification required". > > The exact text in RFC2409 for similar registries is: > > Requests for assignment of new encryption algorithm values must be > accompanied by a reference to a standards-track or Informational > RFC or a reference to published cryptographic literature which > describes this algorithm. > [pl] I changed the reg procedures to "Specification required" for the sub-registry 'PRF' at http://www.iana.org/assignments/ipsec-registry. > > - For these 'early assignment' registrations as per > > ietf-ipsec-ike-ecc-groups, you commented the following: > > > > > > 6 EC2NGF163Random2 > > > > 7 EC2NGF163Koblitz > > > > 8 EC2NGF283Random > > > > 9 EC2NGF283Koblitz > > > > 10 EC2NGF409Random > > > > 11 EC2NGF409Koblitz > > > > 12 EC2NGF571Random > > > > 13 EC2NGF571Koblitz > > > > > > These are from the > > > http://tools.ietf.org/html/draft-ietf-ipsec-ike-ecc-groups-04 version, > > > i.e. the registry was updated at some point in 2002 even when the > > > registry had registration policy of "RFC Required" and the document > > > was still draft (and was never published as RFC). > > > > > > I think you should remove "Panjwani" and "Blake-Wilson" and put > > > "ipsec-ike-ecc-groups" for all of them, and put some down a footnote > > > saying that the registry was updated too early and the draft never > > > made it to the RFC, but as these values might be used by some > > > implementations they are left there in the registry, but new > > > implementations should not use them. Also the reference could point > > > out that the values in the registry match the -04 version of the > > > document. > > > > [pl] I have removed the version number from the draft string. (I was > > unable to locate those assignments (e.g. EC2NGF163Random2) in version 4.) > > I have also remove both "Panjwani" and "Blake-Wilson" from the registry. > > I have also marked the draft-ipsec-ike-ecc-group as expired in > > the registry since it has never made it to an RFC. > > Regarding the footnote, I've drafted something as follows: > > > > [[ > > Note: these values were reserved as per draft-ipsec-ike-ecc-groups which > > never made it to the RFC. These values might be used by some > > implementations as currently registered in the registry, but new > > implementations should not use them. > > ]] > > > > Question: does the above look okay? Please comment. When I receive > > your edits, I will add the "Note" to the registry. > > That note seems to be ok. > > > Please see: http://www.iana.org/assignments/ipsec-registry > [pl] Done. I'll submit this for conversion to XML as the source. If you see any errors, please let us know. > Your changes seem to be ok. > > BTW, is there any way to get diffs to the registries, in the same way > you can get diffs to the drafts. It would be useful when checking out > what has changed in the registry and when. > > Do you keep old versions of the registries and if so, is there a way > to fetch those using http so I could use rfcdiff (or wdiff, or make > separate tool for that) to make side by side diffs of the registries. > [pl] we do not offer this at this time, however we can consider what you have proposed when developing improvements to the website, which is in process right now. > > When you have updates for the isakmp-registry, please send them > > to us. > > I will come back when I have time to go through that one. Okay. Thank you. Best, ~pearl From tso@zteusa.com Thu Feb 16 21:08:29 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40F9521E802F; Thu, 16 Feb 2012 21:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.354 X-Spam-Level: X-Spam-Status: No, score=-1.354 tagged_above=-999 required=5 tests=[AWL=0.484, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oW1lCNmEjx7M; Thu, 16 Feb 2012 21:08:28 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id AEE9421E8026; Thu, 16 Feb 2012 21:08:27 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 12280433787882; Fri, 17 Feb 2012 12:40:08 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 29761.433787882; Fri, 17 Feb 2012 13:07:58 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q1H587MJ044264; Fri, 17 Feb 2012 13:08:07 +0800 (GMT-8) (envelope-from tso@zteusa.com) In-Reply-To: References: <000001cce005$2833bf40$789b3dc0$%pothulam@huawei.com> To: ipsec@ietf.org, ipsec-bounces@ietf.org MIME-Version: 1.0 X-KeepSent: 2831B8F4:B7078535-882579A7:001B648F; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: tso@zteusa.com Date: Thu, 16 Feb 2012 21:06:00 -0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-02-17 13:08:09, Serialize complete at 2012-02-17 13:08:09 Content-Type: multipart/alternative; boundary="=_alternative 001C3303882579A7_=" X-MAIL: mse02.zte.com.cn q1H587MJ044264 Subject: [IPsec] Kind Reminder: Need your feedback for draft-so-ipsecme-ikev2-cpext-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 05:08:29 -0000 This is a multipart message in MIME format. --=_alternative 001C3303882579A7_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 RGVhciBJUHNlYyBleHBlcnRzLA0KDQpTaW5jZSB0d28gd2Vla3MgYWdvLCBJIHVwZGF0ZWQgYW5k IGFkdmVydGlzZWQgdGhlIGF2YWlsYWJpbGl0eSBvZiBteSAiMDEiIA0KdmVyc2lvbiBvZiB0aGUg ZHJhZnQsIEkgaGF2ZSBub3QgeWV0IHJlY2VpdmVkIGFueSBuZXcgdGVjaG5pY2FsIGNvbW1lbnQu DQoNCkhlbmNlLCBJIHdvdWxkIGxpa2UgdG8gdGFrZSB0aGUgb3Bwb3J0dW5pdHkgdG8gaW52aXRl IHlvdSB0byBleGFtaW5lIG15IA0KZHJhZnQgdG8gc2VlIGlmIHlvdSBoYXZlIGFueSBzcGVjaWZp YyBjb25jZXJuIG9yIHF1ZXN0aW9uIHRvd2FyZHMgdGhpcyANCmRyYWZ0LiANCg0KWW91ciB2YWx1 YWJsZSBjb21tZW50cyBhcmUgdHJ1bHkgYXBwcmVjaWF0ZWQuICBUaGFua3MgaW4gYWR2YW5jZS4g DQpUcmljY2kgDQoNCj4+Pj4+IEFic3RyYWN0IG9mIGRyYWZ0LXNvLWlwc2VjbWUtaWtldjItY3Bl eHQtMDEudHh0ID4+Pj4+DQpBYnN0cmFjdA0KSVBTZWMgSUtFdjIsIFJGQyA1OTk2IFtSRkM1OTk2 XSwgaGFzIGJlZW4gYWRvcHRlZCBieSBtYW55IHN0YW5kYXJkaXplZCANCm5ldHdvcmsgc29sdXRp b25zIHRvIHByb3ZpZGUgdGhlIHNlY3VyZSB0cmFuc3BvcnQgYmV0d2VlbiBuZXR3b3JrIGVsZW1l bnRzIA0Kb3ZlciB0aGlyZCBwYXJ0eeKAmXMgaW5mcmFzdHJ1Y3R1cmUuICBGb3IgZXhhbXBsZSwg dGhlIGVtZXJnaW5nIEZpeGVkIE1vYmlsZSANCkNvbnZlcmdlbmNlIChGTUMpIG5ldHdvcmsgc29s dXRpb24gdGhhdCBpbnZvbHZlcyBGZW10b2NlbGwgZGVwbG95bWVudCANCnJlcXVpcmVzIHRoZSBt b2JpbGUgb3BlcmF0b3LigJlzIEZlbXRvY2VsbCBBUCB0byBsZXZlcmFnZSB0aGUgSVBTZWMgSUtF djIgdG8gDQpzdXBwb3J0IG11dHVhbCBhdXRoZW50aWNhdGlvbiBhbmQgcmVtb3RlIElQIGFkZHJl c3MgY29uZmlndXJhdGlvbiBhcyB3ZWxsIA0KYXMgb3RoZXIgYXV0byBjb25maWd1cmF0aW9uIHN1 cHBvcnQgb3ZlciB0aGUgYnJvYWRiYW5kIGZpeGVkIG5ldHdvcmsgKEJCRikgDQpvZiB3aGljaCB0 aGUgbW9iaWxlIGFuZCBmaXhlZCBuZXR3b3JrcyBtYXkgYmUgb3BlcmF0ZWQgYnkgdHdvIGRpZmZl cmVudCANCm9wZXJhdG9ycy4NCk1vc3Qgb2YgdG9kYXkgYnJvYWRiYW5kIGZpeGVkIG5ldHdvcmtz IGFyZSBzdGlsbCByZWx5aW5nIG9uIHRoZSBJUHY0IA0KcHJpdmF0ZSBhZGRyZXNzaW5nIHBsYW4g dG8gc3VwcG9ydCBpdHMgYXR0YWNoZWQgZGV2aWNlcyBpbmNsdWRpbmcgdGhlIA0KbW9iaWxlIG9w ZXJhdG9y4oCZcyBGZW10b2NlbGwgQVAuICBIZW5jZSwgdGhlIHByaXZhdGUgSVB2NCBhZGRyZXNz aW5nIGFuZCANCk5ldHdvcmsgQWRkcmVzcyBhbmQgUG9ydCBUcmFuc2xhdGlvbiAoTkEoUClUKSBz dXBwb3J0IG1vc3RseSBsaWtlbHkgc3RheXMgDQpmb3IgbWFueSB5ZWFycyB0byBjb21lLiANCklu IEZNQyBpbnRlcndvcmtpbmcgc2NlbmFyaW8sIHRoZXJlIGlzIGEgbmVlZCBmb3IgdGhlIG1vYmls ZSBuZXR3b3JrIHRvIA0KcGFzcyBvbiBpdCBtb2JpbGUgc3Vic2NyaWJlcnPigJkgcG9saWNpZXMg dG8gdGhlIGJyb2FkYmFuZCBmaXhlZCBuZXR3b3JrIA0KKEJCRikgdG8gbWFpbnRhaW4gdGhlIHNl cnZpY2UgbGV2ZWwgYWdyZWVtZW50IChTTEEpIGFuZCB0byBzdXBwb3J0IHJlbW90ZSANCm5ldHdv cmsgbWFuYWdlbWVudC4gSW4gYWRkaXRpb24sIGEgYnJvYWRiYW5kIGZpeGVkIG5ldHdvcmsgKEJC RikgbWF5IA0KcGFydG5lcnNoaXAgd2l0aCBtb3JlIHRoYW4gb25lIG1vYmlsZSBvcGVyYXRvci4g IFRoZXJlZm9yZSBpdCBpcyBpbXBvcnRhbnQgDQpmb3IgdGhlIEJCRiBhbmQgdGhlIG1vYmlsZSBu ZXR3b3JrIHRvIGJlIGFibGUgdG8gb3ZlcmNvbWUgdGhlIGxpbWl0YXRpb24gDQpvZiB0aGUgcHJp dmF0ZSBJUHY0IGFkZHJlc3NpbmcgYW5kIHRvIGJlIGFibGUgdG8gaWRlbnRpZnkgdGhlIHVzZXLi gJlzIA0Kc3Vic2NyaXB0aW9uIGFzIHdlbGwgYXMgdG8gZGV0ZXJtaW5lIHRoZSBsb2NhdGlvbiBv ZiB0aGUgRmVtdG9jZWxsIEFQIHRoYXQgDQpzZXJ2ZXMgaXRzIG1vYmlsZSB1c2VyIG92ZXIgdGhl IEJCRiBuZXR3b3JrLiANClRoaXMgZG9jdW1lbnQgcHJlc2VudHMgdGhlIHByb2JsZW1zIGZvciB0 aGUgSVBTZWMgdHVubmVsaW5nIHN1cHBvcnQgd2l0aCANCnByaXZhdGUgSVB2NCBhZGRyZXNzaW5n IGZvciBGTUMgaW50ZXJ3b3JraW5nIGFuZCBwcm9wb3NlcyBhIHNpbXBsZSANCmV4dGVuc2lvbiB0 byB0aGUgSUtFdjIgdG8gcmVzb2x2ZSB0aGUgaXNzdWVzLiAgDQoNCg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlv biBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWls IGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1h aWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUg YXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0 byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4N ClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRl bnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBv ciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUg bWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9m IHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZv ciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 001C3303882579A7_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPkRlYXIgSVBzZWMgZXhwZXJ0cyw8L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPlNpbmNlIHR3byB3ZWVr cyBhZ28sIEkgdXBkYXRlZCBhbmQgYWR2ZXJ0aXNlZA0KdGhlIGF2YWlsYWJpbGl0eSBvZiBteSAm cXVvdDswMSZxdW90OyB2ZXJzaW9uIG9mIHRoZSBkcmFmdCwgSSBoYXZlIG5vdA0KeWV0IHJlY2Vp dmVkIGFueSBuZXcgdGVjaG5pY2FsIGNvbW1lbnQuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj5IZW5jZSwgSSB3b3VsZCBsaWtlIHRvIHRha2UgdGhlIG9w cG9ydHVuaXR5DQp0byBpbnZpdGUgeW91IHRvIGV4YW1pbmUgbXkgZHJhZnQgdG8gc2VlIGlmIHlv dSBoYXZlIGFueSBzcGVjaWZpYyBjb25jZXJuDQpvciBxdWVzdGlvbiB0b3dhcmRzIHRoaXMgZHJh ZnQuICZuYnNwOzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJp ZiI+WW91ciB2YWx1YWJsZSBjb21tZW50cyBhcmUgdHJ1bHkgYXBwcmVjaWF0ZWQuDQombmJzcDtU aGFua3MgaW4gYWR2YW5jZS4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNl cmlmIj5UcmljY2kgPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNl cmlmIj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBBYnN0cmFjdCBvZiA8Yj48dT5kcmFmdC1zby1pcHNl Y21lLWlrZXYyLWNwZXh0LTAxLnR4dDwvdT48L2I+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzwvZm9u dD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPkFic3RyYWN0PC9mb250Pg0K PHA+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij5JUFNlYyBJS0V2MjxiPiwgPC9iPlJG QyA1OTk2IFtSRkM1OTk2XSw8Yj4NCjwvYj5oYXMgYmVlbiBhZG9wdGVkIGJ5IG1hbnkgc3RhbmRh cmRpemVkIG5ldHdvcmsgc29sdXRpb25zIHRvIHByb3ZpZGUNCnRoZSBzZWN1cmUgdHJhbnNwb3J0 IGJldHdlZW4gbmV0d29yayBlbGVtZW50cyBvdmVyIHRoaXJkIHBhcnR54oCZcyBpbmZyYXN0cnVj dHVyZS4NCiZuYnNwO0ZvciBleGFtcGxlLCB0aGUgZW1lcmdpbmcgRml4ZWQgTW9iaWxlIENvbnZl cmdlbmNlIChGTUMpIG5ldHdvcmsNCnNvbHV0aW9uIHRoYXQgaW52b2x2ZXMgRmVtdG9jZWxsIGRl cGxveW1lbnQgcmVxdWlyZXMgdGhlIG1vYmlsZSBvcGVyYXRvcuKAmXMNCkZlbXRvY2VsbCBBUCB0 byBsZXZlcmFnZSB0aGUgSVBTZWMgSUtFdjIgdG8gc3VwcG9ydCBtdXR1YWwgYXV0aGVudGljYXRp b24NCmFuZCByZW1vdGUgSVAgYWRkcmVzcyBjb25maWd1cmF0aW9uIGFzIHdlbGwgYXMgb3RoZXIg YXV0byBjb25maWd1cmF0aW9uDQpzdXBwb3J0IG92ZXIgdGhlIGJyb2FkYmFuZCBmaXhlZCBuZXR3 b3JrIChCQkYpIG9mIHdoaWNoIHRoZSBtb2JpbGUgYW5kDQpmaXhlZCBuZXR3b3JrcyBtYXkgYmUg b3BlcmF0ZWQgYnkgdHdvIGRpZmZlcmVudCBvcGVyYXRvcnMuPC9mb250Pg0KPHA+PGZvbnQgc2l6 ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij5Nb3N0IG9mIHRvZGF5IGJyb2FkYmFuZCBmaXhlZCBuZXR3 b3Jrcw0KYXJlIHN0aWxsIHJlbHlpbmcgb24gdGhlIElQdjQgcHJpdmF0ZSBhZGRyZXNzaW5nIHBs YW4gdG8gc3VwcG9ydCBpdHMgYXR0YWNoZWQNCmRldmljZXMgaW5jbHVkaW5nIHRoZSBtb2JpbGUg b3BlcmF0b3LigJlzIEZlbXRvY2VsbCBBUC4gJm5ic3A7SGVuY2UsIHRoZQ0KcHJpdmF0ZSBJUHY0 IGFkZHJlc3NpbmcgYW5kIE5ldHdvcmsgQWRkcmVzcyBhbmQgUG9ydCBUcmFuc2xhdGlvbiAoTkEo UClUKQ0Kc3VwcG9ydCBtb3N0bHkgbGlrZWx5IHN0YXlzIGZvciBtYW55IHllYXJzIHRvIGNvbWUu ICZuYnNwOzwvZm9udD4NCjxwPjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVyIE5ldyI+SW4gRk1D IGludGVyd29ya2luZyBzY2VuYXJpbywgdGhlcmUNCmlzIGEgbmVlZCBmb3IgdGhlIG1vYmlsZSBu ZXR3b3JrIHRvIHBhc3Mgb24gaXQgbW9iaWxlIHN1YnNjcmliZXJz4oCZIHBvbGljaWVzDQp0byB0 aGUgYnJvYWRiYW5kIGZpeGVkIG5ldHdvcmsgKEJCRikgdG8gbWFpbnRhaW4gdGhlIHNlcnZpY2Ug bGV2ZWwgYWdyZWVtZW50DQooU0xBKSBhbmQgdG8gc3VwcG9ydCByZW1vdGUgbmV0d29yayBtYW5h Z2VtZW50LiBJbiBhZGRpdGlvbiwgYSBicm9hZGJhbmQNCmZpeGVkIG5ldHdvcmsgKEJCRikgbWF5 IHBhcnRuZXJzaGlwIHdpdGggbW9yZSB0aGFuIG9uZSBtb2JpbGUgb3BlcmF0b3IuDQombmJzcDtU aGVyZWZvcmUgaXQgaXMgaW1wb3J0YW50IGZvciB0aGUgQkJGIGFuZCB0aGUgbW9iaWxlIG5ldHdv cmsgdG8gYmUNCmFibGUgdG8gb3ZlcmNvbWUgdGhlIGxpbWl0YXRpb24gb2YgdGhlIHByaXZhdGUg SVB2NCBhZGRyZXNzaW5nIGFuZCB0byBiZQ0KYWJsZSB0byBpZGVudGlmeSB0aGUgdXNlcuKAmXMg c3Vic2NyaXB0aW9uIGFzIHdlbGwgYXMgdG8gZGV0ZXJtaW5lIHRoZSBsb2NhdGlvbg0Kb2YgdGhl IEZlbXRvY2VsbCBBUCB0aGF0IHNlcnZlcyBpdHMgbW9iaWxlIHVzZXIgb3ZlciB0aGUgQkJGIG5l dHdvcmsuICZuYnNwOw0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3 Ij48Yj5UaGlzIGRvY3VtZW50IHByZXNlbnRzIHRoZSBwcm9ibGVtcw0KZm9yIHRoZSBJUFNlYyB0 dW5uZWxpbmcgc3VwcG9ydCB3aXRoIHByaXZhdGUgSVB2NCBhZGRyZXNzaW5nIGZvciBGTUMgaW50 ZXJ3b3JraW5nDQphbmQgcHJvcG9zZXMgYSBzaW1wbGUgZXh0ZW5zaW9uIHRvIHRoZSBJS0V2MiB0 byByZXNvbHZlIHRoZSBpc3N1ZXMuPC9iPg0KJm5ic3A7PC9mb250Pg0KPGJyPjxwcmU+DQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRF Jm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJz cDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwm bmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtz ZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11 bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7 bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFp bnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0 dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2Ym bmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZu YnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZu YnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNw O2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2Ym bmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNw O3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91 Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJz cDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3Im bmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtl eHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhv c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5i c3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7 dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3Bh bSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 001C3303882579A7_=-- From pwouters@redhat.com Fri Feb 17 08:42:58 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D60BB21F8549 for ; Fri, 17 Feb 2012 08:42:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.549 X-Spam-Level: X-Spam-Status: No, score=-110.549 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJQE98cnOwZP for ; Fri, 17 Feb 2012 08:42:58 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id E551B21E801F for ; Fri, 17 Feb 2012 08:42:57 -0800 (PST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q1HGguM2000711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 17 Feb 2012 11:42:56 -0500 Received: from bofh.nohats.ca (vpn-11-70.rdu.redhat.com [10.11.11.70]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q1HGgtGr001409 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 17 Feb 2012 11:42:56 -0500 Message-ID: <4F3E83CE.9060807@redhat.com> Date: Fri, 17 Feb 2012 11:43:58 -0500 From: Paul Wouters User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120131 Thunderbird/10.0 MIME-Version: 1.0 To: ipsec@ietf.org References: <4F397156.2060102@redhat.com> <29D7E149-2FD2-4923-8695-84A5EF0E7DE4@checkpoint.com> <20285.3746.270920.626776@fireball.kivinen.iki.fi> <0F43FB4F-4917-4CFC-ACCF-E36599DF16E7@checkpoint.com> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Subject: Re: [IPsec] iOSX 5.x and IOX Lion's use of UDP_ENCAP problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 16:42:58 -0000 On 02/16/2012 09:49 AM, Yoav Nir wrote: > > On Feb 16, 2012, at 4:43 PM, Paul Wouters wrote: > >> On Thu, 16 Feb 2012, Yoav Nir wrote: >> >>>> Are you really telling me they are using a private numbers from the >>>> internet draft that expired more than 10 years ago, and which is not >>>> compatible with the RFC3947 (which (which was published January 2005, >>>> i.e. 7 years ago). >>> >>> They don't always do that. But looking at their MainMode packet 1 in wireshark, They send the following VIDs: >>> - RFC 3947 Negotiation of the NAT-Traversal in the IKE >>> - draft-ietf-ipsec-nat-t-ike >>> - draft-ietf-ipsec-nat-t-ike-08 >>> - draft-ietf-ipsec-nat-t-ike-07 >>> - draft-ietf-ipsec-nat-t-ike-06 >>> - draft-ietf-ipsec-nat-t-ike-05 >>> - draft-ietf-ipsec-nat-t-ike-04 >>> - draft-ietf-ipsec-nat-t-ike-03 >>> - draft-ietf-ipsec-nat-t-ike-02 >>> - draft-ietf-ipsec-nat-t-ike-02\n >>> - RFC 3706 DPD (Dead Peer Detection) >>> >>> I guess what they later do depends on what VID they get in the reply. There were quite a few versions of Windows server that returned 90cb80…427b1f (draft-ietf-ipsec-nat-t-ike-02\n), so maybe Paul's implementation was a surprise for iOS. >> >> I'll make sure this is not an implementation issue on our side. >> >> Did any large deployment switch to removing all the draft VIDs? If so, >> how many problems did that cause? I'd be happy to remove the ancient >> drat cruft, especially if it increases interoperability. > > Our implementation supports the RFC and "draft-02\n", which is what Microsoft clients added in some service pack of XP. We reply according to the last recognized NAT-T VID, which in this case is the draft-02\n one. > > When we do this, we don't get any weird encapsulation modes like you do. Do you reply with the RFC one? It turns out we had a special check on OSX and did some workaround for a bug that AFAIK is no longer there (involving sending a 0.0.0.0 NAT-OA), and fell back to a draft instead of rfc version. I also removed sending some of the draft vendorids. This together seems to have resolved the problem, and OSX/iOS can now properly connect from public as well as through NAT-T. Thanks for all the feedback from everyone! Paul From pwouters@redhat.com Wed Feb 22 13:50:03 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E109821F8532 for ; Wed, 22 Feb 2012 13:50:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.048 X-Spam-Level: X-Spam-Status: No, score=-101.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drfBlvTtDdn6 for ; Wed, 22 Feb 2012 13:50:03 -0800 (PST) Received: from letoams.cypherpunks.ca (unknown [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 6B81F21F8525 for ; Wed, 22 Feb 2012 13:50:02 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id 562538193E for ; Wed, 22 Feb 2012 16:50:53 -0500 (EST) Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.5/8.14.5/Submit) with ESMTP id q1MLoq65008805 for ; Wed, 22 Feb 2012 16:50:53 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 22 Feb 2012 16:50:52 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: ipsec@ietf.org Message-ID: User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: [IPsec] (IKEv2) ICMP traffic selector question on ICMP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 21:50:04 -0000 Hi, I am wondering how to set the traffic selector to allow "all icmp" http://tools.ietf.org/html/rfc5996#section-3.13.1 Start Port (2 octets, unsigned integer) - Value specifying the smallest port number allowed by this Traffic Selector. For protocols for which port is undefined (including protocol 0), or if all ports are allowed, this field MUST be zero. ICMP and ICMPv6 Type and Code values, as well as Mobile IP version 6 (MIPv6) mobility header (MH) Type values, are represented in this field as specified in Section 4.4.1.1 of [IPSECARCH]. ICMP Type and Code values are treated as a single 16-bit integer port number, with Type in the most significant eight bits and Code in the least significant eight bits. MIPv6 MH Type values are treated as a single 16-bit integer port number, with Type in the most significant eight bits and the least significant eight bits set to zero. If I use the above description, I would set the protocol to 1, but I cannot set startport to 0, as that would mean to only allow Type 0 with Code 0, which means "ICMP Reply"? The text is further confusing because it states "this field MUST be zero" for portless protocols, and then immediately breaks that rule by stating what I think is an exception to that rule? Paul From smoonen@us.ibm.com Wed Feb 22 20:23:39 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F3C21E8027 for ; Wed, 22 Feb 2012 20:23:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQ8oCf5nhMZx for ; Wed, 22 Feb 2012 20:23:38 -0800 (PST) Received: from e38.co.us.ibm.com (e38.co.us.ibm.com [32.97.110.159]) by ietfa.amsl.com (Postfix) with ESMTP id D77A021E8013 for ; Wed, 22 Feb 2012 20:23:36 -0800 (PST) Received: from /spool/local by e38.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 22 Feb 2012 21:23:36 -0700 Received: from d03dlp01.boulder.ibm.com (9.17.202.177) by e38.co.us.ibm.com (192.168.1.138) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 22 Feb 2012 21:23:26 -0700 Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id 88C0AC40008; Wed, 22 Feb 2012 21:23:25 -0700 (MST) Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q1N4NO21158804; Wed, 22 Feb 2012 21:23:25 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q1N4NOXe010939; Wed, 22 Feb 2012 21:23:24 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.63.40.219]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q1N4NOE9010936; Wed, 22 Feb 2012 21:23:24 -0700 In-Reply-To: References: X-KeepSent: E0FA62D8:21A1709C-852579AD:0017D5B8; type=4; name=$KeepSent To: Paul Wouters X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: Scott C Moonen Date: Wed, 22 Feb 2012 23:22:43 -0500 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.3 ZX853HP5|January 12, 2012) at 02/22/2012 21:23:24 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12022304-5518-0000-0000-00000271399B Cc: ipsec@ietf.org, ipsec-bounces@ietf.org Subject: Re: [IPsec] (IKEv2) ICMP traffic selector question on ICMP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 04:23:39 -0000 Hi Paul, To express all ICMP[v6] types and codes, you would use a start port value of 0 (0x00:00), and an end port value of 65535 (0xFF:FF). To express all MIPv6 types, you would use a start port value of 0 (0x00:00), and an end port value of 65280 (0xFF:00). Scott Moonen (smoonen@us.ibm.com) Secure Hybrid Cloud and z/OS Communications Server http://www.linkedin.com/in/smoonen From: Paul Wouters To: ipsec@ietf.org Date: 2012-02-22 16:50 Subject: [IPsec] (IKEv2) ICMP traffic selector question on ICMP Sent by: ipsec-bounces@ietf.org Hi, I am wondering how to set the traffic selector to allow "all icmp" http://tools.ietf.org/html/rfc5996#section-3.13.1 Start Port (2 octets, unsigned integer) - Value specifying the smallest port number allowed by this Traffic Selector. For protocols for which port is undefined (including protocol 0), or if all ports are allowed, this field MUST be zero. ICMP and ICMPv6 Type and Code values, as well as Mobile IP version 6 (MIPv6) mobility header (MH) Type values, are represented in this field as specified in Section 4.4.1.1 of [IPSECARCH]. ICMP Type and Code values are treated as a single 16-bit integer port number, with Type in the most significant eight bits and Code in the least significant eight bits. MIPv6 MH Type values are treated as a single 16-bit integer port number, with Type in the most significant eight bits and the least significant eight bits set to zero. If I use the above description, I would set the protocol to 1, but I cannot set startport to 0, as that would mean to only allow Type 0 with Code 0, which means "ICMP Reply"? The text is further confusing because it states "this field MUST be zero" for portless protocols, and then immediately breaks that rule by stating what I think is an exception to that rule? Paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From tjcarlin@iol.unh.edu Fri Feb 24 06:39:30 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9E421F853B for ; Fri, 24 Feb 2012 06:39:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klCmdMhf2DIG for ; Fri, 24 Feb 2012 06:39:29 -0800 (PST) Received: from exprod5og115.obsmtp.com (exprod5og115.obsmtp.com [64.18.0.246]) by ietfa.amsl.com (Postfix) with SMTP id 792A021F8610 for ; Fri, 24 Feb 2012 06:39:25 -0800 (PST) Received: from postal.iol.unh.edu ([132.177.123.84]) by exprod5ob115.postini.com ([64.18.4.12]) with SMTP ID DSNKT0ehHHBkYa3gdzV7sddcWEMFX5Q3O4h6@postini.com; Fri, 24 Feb 2012 06:39:28 PST Received: from patriot.iol.unh.edu (patriot.iol.unh.edu [132.177.118.220]) by postal.iol.unh.edu (Postfix) with ESMTP id 08EA08F0075; Fri, 24 Feb 2012 09:39:24 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Timothy Carlin In-Reply-To: <20282.29578.645732.514715@fireball.kivinen.iki.fi> Date: Fri, 24 Feb 2012 09:39:52 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <80C0FB1A-03C7-46FB-89BB-D815B2DFD0B4@iol.unh.edu> <20282.29578.645732.514715@fireball.kivinen.iki.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.1251.1) Cc: IPsecme WG Subject: Re: [IPsec] IKEv2 Traffic Selectors X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 14:39:30 -0000 Hi Tero, Thank you for your comments. This was along the same lines as what we = suspected. Regards, Tim Carlin On Feb 14, 2012, at 9:45 AM, Tero Kivinen wrote: > Timothy Carlin writes: >> Hello, >>=20 >> During testing, the UNH-IOL has encountered a behavior with regards >> to the handling of Traffic Selectors that causes interoperability >> issues. >>=20 >> The issue center around the handling of this quote from RFC 5996, >> Section 2.9: >>=20 >> =93To enable the responder to choose the appropriate range in this = case, >> if the initiator has requested the SA due to a data packet, the >> initiator SHOULD include as the first Traffic Selector in each of TSi >> and TSr a very specific Traffic Selector including the addresses in >> the packet triggering the request.=94 >>=20 >>=20 >> We've seen that implementations acting as the responder handle the >> Very Specific Traffic Selector in different ways, resulting in >> non-interoperability. Some implementations reject the connection, >> due to not matching configured selectors, while other >> implementations accept only this traffic selector, inadvertently >> narrowing the tunnel. >=20 > Both of these types of implementation are not really following the > spirit of the IKEv2 RFC. >=20 > The ones who reject the connection, only support startup style SAs, > and nothing else (which is allowed by IKEv2, but it is very limited > implementation). >=20 > The others which only accept only this traffic selectors, usually are > limited to exactly one traffic selector, i.e. they do not support > multiple traffic selectors (which again is allowed by IKEv2, but again > is very limited implementation). >=20 > I would myself consider both of them as broken IKEv2 implementations, > and not to be used outside the very specific scenarios. >=20 > Most of these are IKEv1 implementations hacked to support IKEv2 very > quickly and in their hacking they didn't want to support multiple > traffic selectors in the same SA, as that would change the IPsec > packet engine also. >=20 >> This also causes a detrimental oddity when the data packet causing >> SA creation is an ICMPv6 Echo Request. In this case, both TSi and >> TSr indicate ICMPv6, type 80, Code 00. This is a special case, >> since ICMP has no source and destination port. What should the >> proper behavior be for a packet type with no source and destination >> port? >=20 > The RFC4301 section 4.4.1.3 has text about the ICMP "port" selectors, > but that text really only covers the policy parts. When filling up the > data from the packet information to the TS, this is not that much > applicable, but on the other hand the first TS is also matched against > the local policy, so they should be compatible. >=20 > For the first TS matching the packet, I think best would be to use > both src and dst "port" selectors as same value, i.e. copy the value > to both fields. >=20 > On the other hand reading 4.4.1.3 and matching the case C and D: >=20 > ---------------------------------------------------------------------- > C. If a system is willing to send traffic with a particular > "port" value but NOT receive traffic with that kind of > port value, the system's traffic selectors are set as > follows in the relevant SPD entry: >=20 > Local's > next layer protocol =3D ICMP > "port" selector =3D >=20 > Remote's > next layer protocol =3D ICMP > "port" selector =3D OPAQUE >=20 > D. To indicate that a system is willing to receive traffic > with a particular "port" value but NOT send that kind of > traffic, the system's traffic selectors are set as follows > in the relevant SPD entry: >=20 > Local's > next layer protocol =3D ICMP > "port" selector =3D OPAQUE >=20 > Remote's > next layer protocol =3D ICMP > "port" selector =3D >=20 > For example, if a security gateway is willing to allow > systems behind it to send ICMP traceroutes, but is not > willing to let outside systems run ICMP traceroutes to > systems behind it, then the security gateway's traffic > selectors are set as follows in the relevant SPD entry: >=20 > Local's > next layer protocol =3D 1 (ICMPv4) > "port" selector =3D 30 (traceroute) >=20 > Remote's > next layer protocol =3D 1 (ICMPv4) > "port" selector =3D OPAQUE > ---------------------------------------------------------------------- >=20 > (I.e. Local =3D> incoming from the clear side, going to the SA, remote > =3D> incoming from SA, going to the clear side).=20 >=20 > This would mean that if SGW has policy that allows clients to ping it > but not anything behind the SGW to ping out that would be the case C, > i.e. SGWs Local's policy part would say ICMP echo request and that > would match the incoming TSr, and the SGWs Remote's policy part would > say OPAQUE (i.e. TSi). For the normal narrowing rules to work this > would require the initiator system to use: >=20 > TSi=3DICMP, OPAQUE > TSr=3DICMP, echo request >=20 > I.e that would match the C case and would also case the case where the > SGWs policy says TSi=3DICMP, ANY, TSr=3DICMP, ANY. If you do what I > proposed earlier by putting both TSi and TSr same echo request, that > would not match the OPAQUE, and the policy negotiation would fail. On > the other hand using OPAQUE might cause other implementations to > fail... >=20 > That is if I read the RFC4301 properly... >=20 > On the other hand how many implementations have really implemented > that part of the ICMP filtering, I think most of the implementations > do not really care about the ICMP type and code, and am not sure how > many really implement ICMP OPAQUE parts... >=20 >> The UNH-IOL would very much appreciate any thoughts the Working >> Group might have regarding this behavior!=20 > --=20 > kivinen@iki.fi