[email protected] writes: > 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.
That was how I understood it. > 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 But as I commented most of the product do have non-standard methods of getting that information out, and getting standardized API on those is in the same order of difficulty than getting that configuration payload support added to those products. > 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. Which means they will not support this feature now, and most likely will not support it in the future, as the only use for it is in the femto deployment, and as you mentioned those are off-the-shelf products not specific to 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. As an OEM IPsec toolkit vendor I myself would much rather add standardized api to give this information to the mobile network than start adding some hack about configuration payloads. Especially as the standardized api can be used by different deployments, but this configuration payload support is completely femto specific. Also we do have internal apis for getting that information already, so making suitable wrapper to export the apis as needed is not that much work. For example I think in our toolkit you can get the information you need by http statistics interface which has all the open IKEv2 SAs, their addresses, statistics etc. > 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. All of those do require changes to the code, which means that after that it will nto be off-the-shelf product anymore. I see no reason to add that kind of femto specific hack to general IPsec implementation, especially as there are cleaner ways to do the same thing. Am still not sure what the FAP does with the IP-address and what kind of attacks can malicious FAP do, as if the information about the IP-address is reflected by the FAP and not from the SeGW, the information cannot be trusted. > > > 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. DHCP server address is CONFIOGURATION parameter. IKE client source outer-IP infor is NOT. There is big fundamental difference there. Am not saying it cannot be done, I am saying it should not be done that way. > 3) FAP then probably sends it forward to other side of SeGW? > Tricci > Sorry, this is incorrect. The FAP has the standardized interface So FAP does NOT send that information to the mobile network, but only uses it himself? > 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. Here you do seem to indicate that the FAP do send the information through the IPsec tunnel to the other side of SeGW, to the mobile network, which seems to indicate that my original statement was correct. How does the mobile network know that FAP does not fake or lie about the address it is sending? > 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. Yes it is missing that feature. It is missing lots of other features (for example it does not know the current phase of the moon). That does not mean we need to add them all, and even when someone thinks it would be good idea. And even when someone writes documentation about that, it does not mean vendors actually implement them. > 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. That specific information has no meaning for the IPsec or IKE, so there is no point of adding it as part of IPsec/IKE. > 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 strongly disagree. I do not think this is generic issue, but I consider it very femto specific. > 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. I am very familiar with RFC5996, and there is big fundamental difference bithween the inner vs outer IP-address. Inner address is configuration information transmitted from the SGW to the client, and client itself uses it to create virtual interfaces etc. It is required for certain kinds of setups. Outer address has no use for IPsec or for IKE. It is not configuration information, but just one data readily available in the SGW, and something that is not useful for the client itself. In your cases the FAP client does not need the address, it is the network behind the security gateway which needs it. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
