Dear Tero, Thank you for your interests on my draft.
Please see my responses to you inline below. Cheers. Tricci Tero Kivinen <[email protected]> Sent by: [email protected] 03/15/2012 05:17 PM To [email protected], [email protected] cc Subject [IPsec] Comments to draft-so-ipsecme-ikev2-cpext-01 I think I am completely lost with this draft. If I have understood correctly the basic setup is: UE -- FAP -- NAT --- SeGW --- Mobile network ^ ^ | \--- Public IP+Port \-- Private IP and the problem is that the Mobile network needs to know the Public IP+Port assigned by the NAT. Tricci > First of all, hoping that you and I have the common understanding that, the portion of the network that deploys NAT is the fixed network and its corresponding operator is NOT the same operator who runs the mobile network. However, the FAP is attached to the fixed network with IPSec tunnel established over the fixed network which assigns the private-IP to the FAT and assigns the public-IP at the NAT. At the same time, the SeGW is resided at the mobile network and has no direct interface towards the fixed network nor standardized interface connecting to the mobile network (even though it is part of the mobile network). SeGW is operated as the firewall for the mobile network and has absolutely no mobile-standardized interface to communicate with any of the mobile network element. Tricci > It is very important to understand the actual femto deployment today. Hoping that you can accept this. It seems to say: 1) SeGW has this information but it cannot pass it forward Tricci > SeGW has no standardized interface to communicate any mobile network element 2) Reason being that there is no justification to require FAP spcific changes in SeGW Tricci > Yes. Because SeGW is off-the-shelf firewall product and is not specific designed for Femto deployment. 3) And it is outside the scope is document to add interface which could be used to pass on SeGWs knowledge forward Tricci > Yes. It is outside the scope of IETF to define the interface on the Femto for different mobile technologies that deploy Femto 4) I.e. SeGW cannot be modified Tricci > No, this is not what I have described. What I have explained is that, SeGW cannot be modified to standardize a "specific" interface for a specific mobile technology. However, we can modify the SeGW for the standard protocol that it supports, e.g. IKEv2/IPSEC. Hoping that you can understand the differences between interface vs. protocol. and this draft tries to fix this by 1) Modify the SeGW to support completely new configuration payload attribute Tricci > IMHO opinion, configuration is designed to support different types of configuration info as long as it is associated with the IKE-peer. Extending an existing protocol which is designed to be extensible is far more easier to modify an existing network component which is designed to be off-the-shelf, and it is definitely far more simple than to change the existing Femto network architecture just to support this "new" interface. 2) Send this Public IP + Port inside that configuration payload attribute to FAP Tricci > Yes. Please note that, as of today many IPSec deployment, including over the Femto network, the configuration payload has already been used by the SeGW to carry the IKE-client source inner-IP info assigned by the DHCP server back to the IKE-client. Please check RFC-5996. The different between my draft and this existing function is to have the SeGW to carry the "NATed" IKE-client source outer-IP info back to the IKE-client. 3) FAP then probably sends it forward to other side of SeGW? Tricci > Sorry, this is incorrect. The FAP has the standardized interface towards the mobile network. Once the IPSec tunnel is established, all the data and control info are carried within the IPSec-tunnel's payload. They are totally transparent to the SeGW. SeGW is just a firewall pipe and it cannot see inside the IPSec-tunnel's payload. The key point is that, FAP has the standardized interface to its associated mobile network for a given mobile technology and SeGW does not. I should point out that quite a many of the security gateways already have ways to find out the public IP address+port of the IKE peer, just because it is usually needed for statistics. Why do you think security gateway vendors would add support to this very FAP specific feature, and not add the much more commonly usable feature of getting information and statistics about the existing IKE and IPsec SAs? Tricci > Sorry, I respectfully disagree with your assessment. Today IKE/IPSec framework is missing a capability to allow the IKE-client to learn about its NATed IP-address. This problem is well understood and hence, there is another IETF RFC-5389 that I have mentioned in my draft is trying to resolve this issue. Unfortunately, the design of RFC-5389 cannot fit into the Femto network architecture which in general involves two different types of network operators who manage two different parts of the network segment. Tricci > Hence, this NATed issue is generic, however, we don't have a generic solution so far to solve this issue. And I believe that my draft resolve this issue in a generic way. It happens Femto network architecture is the one which breaks the solution offered by RFC-5389. I think it would be much better to write document which documents what kind of API is wanted from the SeGW to get this information (and that document does not need to be IETF document). Tricci > Again, please refer to the existing RFC-5996 for the Configuration Payload support for carrying the source inner-ip of the IKE-client from IKE-server (i.e. SeGW) back to the IKE-client. The idea is nothing new. The different is just the inner vs. outer IP-addr. That's all. Tricci > Thank you very much for your patient to read through this long email responses from me. Cheers. -- [email protected] _______________________________________________ IPsec mailing list [email protected] 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.
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
