Subject: [IPsec] [IPSec]: IKEv2 configuration payload extension for draft-so-ipsecme-ikev2-cpext-00.txt

From: Dharmanandana Reddy Pothula <[email-masked]>
Date: Fri, 03 Feb 2012 19:49:10 +0530

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

---

From: [email-masked]
Date: Tue, 7 Feb 2012 08:38:27 -0800

Dear Dharmanandane, 

Sincerely sorry for the delay to respond to you. 

Thank you very much for your comments on my draft. 

Yes, I fully agree with your understanding.  The reason that I did not 
include these two parameters in the draft's sample control flow because 
the existing IKEv2 RFC 5996 have already the procedures that describe the 
detection of NAT.  Hence, I only want to describe the minimum that 
explains the proposal from the draft. 

Hoping that it is acceptable to you. 

Thanks again for your kind suggestion.
Tricci 

Dharmanandana Reddy Pothula <[email-masked]> 
02/03/2012 06:19 AM
Please respond to
[email-masked]

To
[email-masked]
cc
[email-masked]
Subject
[IPSec]: IKEv2 configuration payload extension for 
draft-so-ipsecme-ikev2-cpext-00.txt

Hi Tricci,

 
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,

--------------------------------------------------------
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.

---

From: [email-masked]
Date: Tue, 7 Feb 2012 17:57:54 -0800

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