Subject: Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt

From: [email-masked]
Date: Wed, 1 Feb 2012 00:58:54 -0800

Dear Dharmanandana, 

Thank you for your clarification. 

Yes, as YinXing's understanding, once the FAP and SeGW are mutually 
authenticated, the SeGW will then notarize the info that was provided by 
FAP (in Client_Notarized_Info) into a form of signature, and the signature 
will then be fed back to the FAP. 

In the Femto architecture, there is a direct interface between the FAP and 
the Mobile Core Network.  The signaling path between the FAP and the 
Mobile Core Network is protected by the IPsec tunnel that was established 
between the FAP and SeGW. 

The FAP will then imbedded the SeGW's notarized signature into FAP 
signaling communication with the Mobile Core Network of which the 
signaling is part of the IPSec payload.  Hence, it is totally transparent 
to the SeGW.  The notarized signature is just containing some FAP's 
specific configuration info - i.e. NOT every single packet between the FAP 
and the Mobile Core Network will be notarized.  It is a very small 
specific configuration info regarding to FAP which is specific to the 
particular mobile technology (i.e. 3GPP, 3GPP2, WiMAX etc.) and the 
corresponding mobile operator. 

Hoping that I was able to answer your question clearly. 

As ZaiFeng is back from her holiday.  I will leave the rest of further 
question back to her. 

Sincerely thanks for your kind attention to this draft. Cheers.
Tricci 

Dharmanandana Reddy Pothula <[email-masked]> 
Sent by: [email-masked]
01/31/2012 02:43 AM
Please respond to
[email-masked]

To
[email-masked]
cc
[email-masked], [email-masked], [email-masked]
Subject
Re: [IPsec] [IPSec]: New Version Notification for 
draft-zong-ipsecme-ikev2-cpext4femto-00.txt

Hi Tricci,
 
Thanks for your explanation. I get your point why notarized signature 
required, but my question is not about notarizing every packet. Let me ask 
my question in different way, Is FAP sends notarized signature in every 
IPSec packet to core network? As I understand from the draft that before 
accepting every IPSec packet, core network validate the notarized 
signature. Where is this notarized signature placed in every IPSec packet?
Thanks,
Dharmanandana Reddy Pothula
 
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, January 25, 2012 1:26 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; 
[email-masked]
Subject: Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipse 
cme-ikev 
 
Dear Dharmanandana, 

I hope that I address you correctly.  If not, please pardon my ignorance. 

As this week is spring festival, ZaiFeng is not available.  Hence, I would 
like to respond to you on behalf of her.   

Could you please kind see my responses to you inline below.  Many thanks. 
Tricci 

5pt;font-family:"Arial","sans-serif"'>Dharmanandana Reddy 
<[email-masked]> 
Sent by: [email-masked] 
01/24/2012 04:04 AM 

Please respond to
[email-masked]

To
[email-masked] 
cc
[email-masked] 
Subject
Re: [IPsec] [IPSec]: New Version Notification for 
draft-zong-ipsecme-ikev2-cpext4femto-00.txt

Hi Zaifeng, 
  
I have following questions and concerns about your proposed solution "The 
FAP will then send the FAP information together with the corresponding 
SeGW notarized signature to its mobile operator's core network. The core 
network verifies the FAP information by validating the SeGW notarized 
signature prior to the acceptance of the information". 
Is every ip packet carries SeGW notarized signature after server sends 
notarized signature to the client? if not, what's the point in returning 
notarized signature to the client? I believe yes, if so, It will increase 
percentage of overhead per packet and may impact quality of real time 
voice and video. 

Tricci > You ask a very legitimate question.  May be our draft is not 
clear enough to explain the main motivation of this draft for target of 
the attack.   

Tricci > The main concern is not about the attack for "unauthorized FAP" 
to send any data to the mobile core network.  The main concern is about 
the attack of the "unauthorized FAP" to send the "false" configuration 
information (e.g. such as changing the FAP from "Closed" to become "O pen" 
;false" access control related information (e.g. allowing a 3GPP UE which 
is supposed to be allowed to access the FAP and to have the access 
privileage to the FAP - i.e. CSG info alteration, etc.).  Once the FAP's 
configuration and access control management are authenticated via the 
support of the notarization by the SeGW, then, the rest of the 3GPP UEs' 
access to the FAP can follow the existing access control and UE-based 
authentication/authorization procedures at the UE level's.   

Tricci > Of course, once the UE is authenticated and to allow access to 
the FAP, whatever the UE sends is beyond the control of the FAP just as 
what is happened today for any mobile device.  Isn't it?   
  
if every ip packet carries SeGW notarized signature, How and where this 
signature carried inside ip packet? cations inside IPsec packet 
processing? Is this processing happens outside of IPsec? is it outside 
scope of this document? It would be great, if some of these aspects are 
addressed in the draft. 
  
Tricci > Since I have already explained to you that, we are not proposing 
to notarize every single packet sent by FAP.  Hence, I don't think that I 
need to respond to your rest of the questions above.   

Tricci > THANK YOU for asking a good question.  Cheers. 

Thanks, 
  
Dharmanandana Reddy Pothula. 
  
& yle='font-size:10.0pt;font-family:"Arial","sans-serif"'>  
 _______________________________________________
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. R
 ecipient
bsp;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-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: [email-masked]
Date: Thu, 2 Feb 2012 16:21:02 +0800

Hi Dharmanandana:

The notarized signature will not be sent oin every IPSec packet. It will 
be sent to core network when the FAP registers to the core network inside 
the signalling between the FAP and core network. After it is registered to 
the core network, the FAP is activated to accept attachment of mobile 
terminals. I wish this clarifies. Thanks!

BR
Zaifeng

2012-01-31 18:43
请答复 给

收件人
[email-masked]
抄送
[email-masked], [email-masked], [email-masked]
主题
RE: [IPsec] [IPSec]: New Version Notification for 
draft-zong-ipsecme-ikev2-cpext4femto-00.txt

Hi Tricci,

Subject: Re: [IPsec] [IPSec]: New Version Notification for 
draft-zong-ipsecme-ikev 
 
Dear Dharmanandana, 

Please respond to

To
[email-masked] 
cc
[email-masked] 
Subject

Hi Zaifeng, 

information (e.g. such as changing the FAP from "Closed" to become "Open" 

  

Thanks, 

confidential. Recipient
system.

---

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

Zaifeng / Tricci,

Yes, I understood, so there is no impact on performance of UE access. Thanks
for your clarification.  I feel It would be nice, if you can touch upon some
of these points in the draft, so the use case will be appreciated well and
also the main motivation of this draft may need little more explanation like
as you explained in previous emails. Of course these points may be outside
scope of this draft, since IKE payloads used for authorization decisions, It
would be appropriate to know in and around of it. 

Regards,

From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, February 02, 2012 1:51 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: 答复: RE: [IPsec] [IPSec]: New Version Notification for
draft-zong-ipsecme-ikev2-cpext4femto-00.txt

Hi Dharmanandana: 

The notarized signature will not be sent oin every IPSec packet. It will be
sent to core network when the FAP registers to the core network inside the
signalling between the FAP and core network. After it is registered to the
core network, the FAP is activated to accept attachment of mobile terminals.
I wish this clarifies. Thanks! 

BR 
Zaifeng

2012-01-31 18:43 

请答复 给

收件人

[email-masked] 

抄送

主题

		

Hi Tricci, 
  
Thanks for your explanation. I get your point why notarized signature
required, but my question is not about notarizing every packet. Let me ask
my question in different way, Is FAP sends notarized signature in every
IPSec packet to core network? As I understand from the draft that before
accepting every IPSec packet, core network validate the notarized signature.
Where is this notarized signature placed in every IPSec packet? 
Thanks, 
Dharmanandana Reddy Pothula 

Dear Dharmanandana, 

01/24/2012 04:04 AM 

Please respond to

To 

[email-masked] 

cc

[email-masked] 

Subject

  

Hi Zaifeng, 
 
I have following questions and concerns about your proposed solution "The
FAP will then send the FAP information together with the corresponding SeGW
notarized signature to its mobile operator's core network. The core network
verifies the FAP information by validating the SeGW notarized signature
prior to the acceptance of the information". 
Is every ip packet carries SeGW notarized signature after server sends
notarized signature to the client? if not, what's the point in returning
notarized signature to the client? I believe yes, if so, It will increase
percentage of overhead per packet and may impact quality of real time voice
and video. 

Tricci > You ask a very legitimate question.  May be our draft is not clear
enough to explain the main motivation of this draft for target of the
attack.   

Tricci > The main concern is not about the attack for "unauthorized FAP" to
send any data to the mobile core network.  The main concern is about the
attack of the "unauthorized FAP" to send the "false" configuration
information (e.g. such as changing the FAP from "Closed" to become "Open"
;false" access control related information (e.g. allowing a 3GPP UE which is
supposed to be allowed to access the FAP and to have the access privileage
to the FAP - i.e. CSG info alteration, etc.).  Once the FAP's configuration
and access control management are authenticated via the support of the
notarization by the SeGW, then, the rest of the 3GPP UEs' access to the FAP
can follow the existing access control and UE-based
authentication/authorization procedures at the UE level's.   

Tricci > Of course, once the UE is authenticated and to allow access to the
FAP, whatever the UE sends is beyond the control of the FAP just as what is
happened today for any mobile device.  Isn't it?   
 
if every ip packet carries SeGW notarized signature, How and where this
signature carried inside ip packet? cations inside IPsec packet processing?
Is this processing happens outside of IPsec? is it outside scope of this
document? It would be great, if some of these aspects are addressed in the
draft. 
 
Tricci > Since I have already explained to you that, we are not proposing to
notarize every single packet sent by FAP.  Hence, I don't think that I need
to respond to your rest of the questions above.   

Thanks, 

& yle='font-size:10.0pt;font-family:"Arial","sans-serif"'>  
_______________________________________________
IPsec mailing list
[email-masked]
 <https://www.ietf.org/mailman/listinfo/ipsec>
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. Recipient
bsp;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: Dharmanandana Reddy Pothula <[email-masked]>
Date: Tue, 07 Feb 2012 16:56:01 +0530

Hi Zaifeng,

Suppose authentication succeeds but verification fails due to false
information sent by FAP, so IPSec tunnel will not be up, so Is there any
response from responder to Initiator indicating IKE message received with
false configuration information from FAP? How to address this particular
error scenario?

Regards,

 

Hi Dharmanandana: 

BR 
Zaifeng

2012-01-31 18:43 

请答复 给

收件人

[email-masked] 

抄送

主题

		

Hi Tricci, 

  
Dear Dharmanandana, 

01/24/2012 04:04 AM 

Please respond to

To 

[email-masked] 

cc

[email-masked] 

Subject

  

Hi Zaifeng, 

 

Thanks,

---

From: Dharmanandana Reddy Pothula <[email-masked]>
Date: Tue, 07 Feb 2012 17:47:35 +0530

Hi Zaifeng,

About error condition, Is there any plan to add new error message types to
Notify payload to handle verification fail scenarios? I feel it would
appropriate to inform FAP, so this helps FAP to correct if misconfigured.

I have one more question about the proposed solution. Can’t we handle
verifying FAP configuration information inside Femto Gateway? Femto Gateway
can inform security gateway to bring down the tunnel, if verification fails.
Anyway false information submission very unlikely scenario, so why we need
to make this config payload exchange as part of regular IKE negotiation? I
feel addition of more config payloads might impact tunnel setup rate.

Regards,

Hi Dharmanandana: 

BR 
Zaifeng

2012-01-31 18:43 

请答复 给

收件人

[email-masked] 

抄送

主题

		

Hi Tricci, 

  
Dear Dharmanandana, 

01/24/2012 04:04 AM 

Please respond to

To 

[email-masked] 

cc

[email-masked] 

Subject

  

Hi Zaifeng, 

 

Thanks,

---

From: [email-masked]
Date: Wed, 8 Feb 2012 10:32:48 +0800

Hi Dharmanandana:

The IPSec tunnel establishment will not be impacted by this draft, if the 
initiator send some wrong information to responder, it will be detected by 
the responder, and the responder can replace the wrong information with 
correct ones. It is like IP address configuration, the client may request 
a specific IP address or not, the server can anyway choose a different 
one. The responder (i.e. SeGW) will choose correct FAP configuration 
information, and sign this information, so that the FAP will not be able 
to change it. This FAP configuration information will later be sent by the 
FAP to the core network (inside the IPsec tunnel as payload of signalling 
between FAP and core network), and the core network will verify the 
information based on the signature. 

BR
Zaifeng

2012-02-07 19:26

收件人
[email-masked]
抄送
[email-masked], [email-masked], [email-masked]
主题
RE: RE: [IPsec] [IPSec]: New Version Notification for 
draft-zong-ipsecme-ikev2-cpext4femto-00.txt

Hi Zaifeng,

Hi Dharmanandana: 

BR 
Zaifeng

请答复 给

收件人
[email-masked] 
抄送

Hi Tricci, 

Thanks, 

Dear Dharmanandana, 

Please respond to

To 
[email-masked] 
cc
[email-masked] 
Subject

Hi Zaifeng, 

 

Thanks,

---

From: [email-masked]
Date: Wed, 8 Feb 2012 11:34:31 +0800

Dharmanandana Reddy Pothula <[email-masked]> wrote on 
2012-02-07 20:17:35:

> Hi Zaifeng,
> 
> About error condition, Is there any plan to add new error message 
> types to Notify payload to handle verification fail scenarios? I 
> feel it would appropriate to inform FAP, so this helps FAP to 
> correct if misconfigured.
> 
> I have one more question about the proposed solution. Can’t we 
> handle verifying FAP configuration information inside Femto Gateway?
> Femto Gateway can inform security gateway to bring down the tunnel, 
> if verification fails. Anyway false information submission very 
> unlikely scenario, so why we need to make this config payload 
> exchange as part of regular IKE negotiation? I feel addition of more
> config payloads might impact tunnel setup rate.
> 
The reason why we have this draft is to enable femto gateway (or other 
core network entities in certain scenarios) to verify the FAP 
configuration information. But the problem is the femto gateway does not 
have the capability to do so according to femto architecture, because the 
FAP is not authenticated by femto gateway and there is no interface 
between femto gateway and the entities which are responsible for the 
authentication of the FAP (i.e. the SeGW). Of course, if the femto 
architecture could be changed, e.g. adding an interface between SeGW and 
core network, could solve the problem too, but that has the architectural 
impacts, hence, I think the change is huge. 

> The notarized signature will not be sent oin every IPSec packet. It 
> will be sent to core network when the FAP registers to the core 
> network inside the signalling between the FAP and core network. 
> After it is registered to the core network, the FAP is activated to 
> accept attachment of mobile terminals. I wish this clarifies. Thanks! 
> 
> BR 
> Zaifeng
> 
> 

> RE: [IPsec] [IPSec]: New Version Notification for draft-zong-
> ipsecme-ikev2-cpext4femto-00.txt
> 
> 
> 
> 
> 
> 
> Hi Tricci, 
> 
> Thanks for your explanation. I get your point why notarized 
> signature required, but my question is not about notarizing every 
> packet. Let me ask my question in different way, Is FAP sends 
> notarized signature in every IPSec packet to core network? As I 
> understand from the draft that before accepting every IPSec packet, 
> core network validate the notarized signature. Where is this 
> notarized signature placed in every IPSec packet? 
> Thanks, 
> Subject: Re: [IPsec] [IPSec]: New Version Notification for draft-
> zong-ipsecme-ikev 
> 
> Dear Dharmanandana, 
> 
> As this week is spring festival, ZaiFeng is not available.  Hence, I
> would like to respond to you on behalf of her. 
> 

> Re: [IPsec] [IPSec]: New Version Notification for draft-zong-
> ipsecme-ikev2-cpext4femto-00.txt
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Hi Zaifeng, 
> 
> I have following questions and concerns about your proposed solution
> "The FAP will then send the FAP information together with the 
> corresponding SeGW notarized signature to its mobile operator's core
> network. The core network verifies the FAP information by validating
> the SeGW notarized signature prior to the acceptance of the 
information". 
> Is every ip packet carries SeGW notarized signature after server 
> sends notarized signature to the client? if not, what's the point in
> returning notarized signature to the client? I believe yes, if so, 
> It will increase percentage of overhead per packet and may impact 
> quality of real time voice and video. 
> 
> Tricci > You ask a very legitimate question.  May be our draft is 
> not clear enough to explain the main motivation of this draft for 
> target of the attack. 
> 
> Tricci > The main concern is not about the attack for "unauthorized 
> FAP" to send any data to the mobile core network.  The main concern 
> is about the attack of the "unauthorized FAP" to send the "false" 
> configuration information (e.g. such as changing the FAP from 
> "Closed" to become "Open" ;false" access control related information
> (e.g. allowing a 3GPP UE which is supposed to be allowed to access 
> the FAP and to have the access privileage to the FAP - i.e. CSG info
> alteration, etc.).  Once the FAP's configuration and access control 
> management are authenticated via the support of the notarization by 
> the SeGW, then, the rest of the 3GPP UEs' access to the FAP can 
> follow the existing access control and UE-based 
> Tricci > Of course, once the UE is authenticated and to allow access
> to the FAP, whatever the UE sends is beyond the control of the FAP 
> just as what is happened today for any mobile device.  Isn't it? 
> 
> if every ip packet carries SeGW notarized signature, How and where 
> this signature carried inside ip packet? cations inside IPsec packet
> processing? Is this processing happens outside of IPsec? is it 
> outside scope of this document? It would be great, if some of these 
> aspects are addressed in the draft. 
> 
> Tricci > Since I have already explained to you that, we are not 
> proposing to notarize every single packet sent by FAP.  Hence, I 
> don't think that I need to respond to your rest of the questions above.  

> ZTE Information Security Notice: The information contained in this 
> mail is solely property of the sender's organization. This mail 
> communication is confidential. Recipient
> bsp;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. 
system.

---

From: [email-masked]
Date: Thu, 16 Feb 2012 21:06:00 -0800

Dear IPsec experts,

Since two weeks ago, I updated and advertised the availability of my "01" 
version of the draft, I have not yet received any new technical comment.

Hence, I would like to take the opportunity to invite you to examine my 
draft to see if you have any specific concern or question towards this 
draft. 

Your valuable comments are truly appreciated.  Thanks in advance. 
Tricci 

>>>>> Abstract of draft-so-ipsecme-ikev2-cpext-01.txt >>>>>
Abstract
IPSec IKEv2, RFC 5996 [RFC5996], has been adopted by many standardized 
network solutions to provide the secure transport between network elements 
over third party’s infrastructure.  For example, the emerging Fixed Mobile 
Convergence (FMC) network solution that involves Femtocell deployment 
requires the mobile operator’s Femtocell AP to leverage the IPSec IKEv2 to 
support mutual authentication and remote IP address configuration as well 
as other auto configuration support over the broadband fixed network (BBF) 
of which the mobile and fixed networks may be operated by two different 
operators.
Most of today broadband fixed networks are still relying on the IPv4 
private addressing plan to support its attached devices including the 
mobile operator’s Femtocell AP.  Hence, the private IPv4 addressing and 
Network Address and Port Translation (NA(P)T) support mostly likely stays 
for many years to come. 
In FMC interworking scenario, there is a need for the mobile network to 
pass on it mobile subscribers’ policies to the broadband fixed network 
(BBF) to maintain the service level agreement (SLA) and to support remote 
network management. In addition, a broadband fixed network (BBF) may 
partnership with more than one mobile operator.  Therefore it is important 
for the BBF and the mobile network to be able to overcome the limitation 
of the private IPv4 addressing and to be able to identify the user’s 
subscription as well as to determine the location of the Femtocell AP that 
serves its mobile user over the BBF network. 
This document presents the problems for the IPSec tunneling support with 
private IPv4 addressing for FMC interworking and proposes a simple 
extension to the IKEv2 to resolve the issues.