Subject: [IPsec] Comments to draft-so-ipsecme-ikev2-cpext-01

From: Tero Kivinen <[email-masked]>
Date: Fri, 16 Mar 2012 02:17:46 +0200

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.

It seems to say:

1) SeGW has this information but it cannot pass it forward
2) Reason being that there is no justification to require
   FAP spcific changes in SeGW
3) And it is outside the scope is document to add interface which
   could be used to pass on SeGWs knowledge forward
4) I.e. SeGW cannot be modified

and this draft tries to fix this by

1) Modify the SeGW to support completely new configuration payload
   attribute 
2) Send this Public IP + Port inside that configuration payload
   attribute to FAP 
3) FAP then probably sends it forward to other side of SeGW?

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?

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).
-- 
[email-masked]

---

From: [email-masked]
Date: Thu, 15 Mar 2012 19:10:18 -0800

Dear Tero,

Thank you for your interests on my draft. 

Please see my responses to you inline below. 

Cheers.
Tricci 

Tero Kivinen <[email-masked]> 
Sent by: [email-masked]
03/15/2012 05:17 PM

To
[email-masked], [email-masked]
cc

Subject
[IPsec] Comments to draft-so-ipsecme-ikev2-cpext-01

 

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.  

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.   

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-masked]
_______________________________________________
IPsec mailing list
[email-masked]
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.

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 16 Mar 2012 05:56:21 +0200

> interface to communicate with any of the mobile network element. 

That was how I understood it. 

> Tricci > SeGW has no standardized interface to communicate any mobile 

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. 

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

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

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

> to have the SeGW to carry the "NATed" IKE-client source outer-IP info back 

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.

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

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

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

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

> is nothing new.  The different is just the inner vs. outer IP-addr. That's 

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-masked]

---

From: [email-masked]
Date: Thu, 15 Mar 2012 20:19:27 -0800

Dear Tero, 

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) 
it is....

Please have a great day.  Cheers.
Tricci 

03/15/2012 08:56 PM

To
[email-masked]
cc
[email-masked]
Subject
Re: [IPsec] Comments to draft-so-ipsecme-ikev2-cpext-01