|Main Archive Page > Month Archives > ipsec archives|
Thank you again for your patient to read through my long reply and to
provide me your long reply.
Please allow me to make a shorter reply to you this time to explain that
why your proposal for defining API does NOT work, even though I am happy
to further discuss with your email responses below another time.
I presume that you are referring to the API to interface with IKE/IPSEC
protocol (as you said, you are - As an OEM IPsec toolkit vendor I myself
), correct? Well, unfortunately, the network element which could use this
API is the network element that deploys IKE/IPSEC, isn't it?
FYI, within the mobile network, other than the SeGW communicates with the
FAP, there is no other network element communicate with the SeGW via
IPSec. Hence, may I ask you, how could this API can help?
If you would like to suggest another protocol to add on an API, could you
please clarify which particular protocol that you have in mind?
Without a standardized interface between the SeGW with the other network
element within the mobile network, I sincerely don't know how could you
make it work?
If you have a chance, please ask any network operator to give them two
choices to solve their problem:
(A) Modifying their existing network deployment with an added "new"
interface with new protocol, or
(B) Modifying an existing protocol with simple software change
I am sure that the operator will be happy to give you a right answer - (B)
Please have a great day. Cheers.
Tero Kivinen <email@example.com>
Sent by: firstname.lastname@example.org
03/15/2012 08:56 PM
Re: [IPsec] Comments to draft-so-ipsecme-ikev2-cpext-01
> Tricci > First of all, hoping that you and I have the common
> that, the portion of the network that deploys NAT is the fixed network
> 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
> the FAT and assigns the public-IP at the NAT. At the same time, the
> is resided at the mobile network and has no direct interface towards the
> fixed network nor standardized interface connecting to the mobile
> (even though it is part of the mobile network). SeGW is operated as the
> firewall for the mobile network and has absolutely no
> 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
> specific mobile technology. However, we can modify the SeGW for the
> standard protocol that it supports, e.g. IKEv2/IPSEC. Hoping that you
> 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
> Tricci > IMHO opinion, configuration is designed to support different
> types of configuration info as long as it is associated with the
> Extending an existing protocol which is designed to be extensible is
> 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
> existing Femto network architecture just to support this "new"
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
> 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
> 3) FAP then probably sends it forward to other side of SeGW?
> Tricci > Sorry, this is incorrect. The FAP has the standardized
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
> data and control info are carried within the IPSec-tunnel's payload.
> are totally transparent to the SeGW. SeGW is just a firewall pipe and
> cannot see inside the IPSec-tunnel's payload. The key point is that,
> 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
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
> 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.
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@example.com _______________________________________________ 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.
IPsec mailing list