So if I understand this correctly, the notarized data contains the acceptable 
mode and the allowed member groups, signed (and time-limited?) by the SeGW.

The tunneled protocol between the FAP and the core network would change, so 
that instead of the FAP sending unsubstantiated claims, it would replay the 
notarized data from the SeGW. Wouldn't this require an update of both core 
network components, SeGW and FAPs?

I would think that the SeGW could instead look at the decrypted protocol 
between the FAP and the core network  (it is decrypting it after all), and 
block it if it contains "lies". A change like this would require modifying only 
the SeGW. I may be showing some serious firewall vendor bias here...

Anyway, yes, your clarification helped me very much.

Regarding the term "notarized", I would prefer not to bring in a new term that 
is burdened with other meaning. But legal notaries are obscure enough that it 
doesn't matter much. Perhaps some explanation as to what it means in the draft 
would help.


You are correct in the draft, that it is out of scope for the working group 
what the exact content of the new attribute is. However, the CP payload is 
contained in the biggest packet of all of IKE - the IKE_AUTH packets. Can you 
tell us how large these attributes may be? Since IKE is still UDP-only, size 
matters very much.

Thanks

Yoav

________________________________
From: zong.zaif...@zte.com.cn [mailto:zong.zaif...@zte.com.cn]
Sent: 21 January 2012 11:08
To: Yoav Nir
Cc: ipsec@ietf.org
Subject: 答复: Re: [IPsec] [IPSec]: New Version Notification for 
draft-zong-ipsecme-ikev2-cpext4femto-00.txt


Hi Yoav:

Thank you for your email. Regarding to your question on "what is the malicious 
FAP lying about", I would like to give you some further background. In real 
femto deployment, not every mobile terminal is allowed to attach via an FAP. In 
fact, in the real deployment, there are 3 kinds of FAPs: open mode FAP, close 
mode FAP, and hybrid mode FAP. The open mode means that the FAP is open to 
everyone, close mode means the FAP only allows a closed group of members to 
access, and the hybrid mode means that the FAP is open to everyone, but only a 
closed group of members will have higher priority or have authority to visit 
certain resources.

According to some SDO (e.g. 3GPP), the access control of the mobile terminals 
attaching via a FAP is done in core network, thus, it is the core network that 
decide whether the mobile terminal can attach to an FAP. In order to help the 
core network make decision on whether the mobile terminal can attach to an FAP, 
the FAP needs to send information, such as the mode of the FAP, and the allowed 
member group of the FAP, to the core network. A compromised FAP could send 
false mode and false allowed member group to the core network, so that a not 
allowed mobile terminal could be allowed by the core network.

I wish the above clarification helps you understand the problem.

Regarding to the term notarized, since I am green to this group, I am not sure, 
do you prefer to replace the notarize with signature? Please let me know, thank 
you!


BR
Zaifeng




Yoav Nir <y...@checkpoint.com>

2012-01-21 15:30

收件人
"<zong.zaif...@zte.com.cn> <zong.zaif...@zte.com.cn>"        
<zong.zaif...@zte.com.cn>
抄送
"ipsec@ietf.org" <ipsec@ietf.org>
主题
Re: [IPsec] [IPSec]: New Version Notification for        
draft-zong-ipsecme-ikev2-cpext4femto-00.txt





Hi Zaifeng

Reading your draft, I'm trying to understand the problem you are solving. It is 
about the FAP being compromised and sending false information through the 
tunnel.

What is the malicious FAP lying about?
How does sending some information (does "notarized" mean "signed"?) from the 
SeGW to the (compromised) FAP help?

One general comment: "notarized" is a legal term, similar to "signature". 
Although there is some analogy between the legal concept of signature and the 
digital signatures, such analogies only go so far. Using such a borrowed term 
has IMHO led to more confusion than clarity. I would rather not use legal terms 
in protocols (although "protocol" is also a borrowed term)

Thanks,

Yoav

On Jan 20, 2012, at 8:40 AM, <zong.zaif...@zte.com.cn> 
<zong.zaif...@zte.com.cn> wrote:

>
> Hi Folks:
>
> There is a new draft available that some of you may be interested
> in looking at.
>
> The draft is available via the following link:
> http://www.ietf.org/id/draft-zong-ipsecme-ikev2-cpext4femto-00.txt
>
> Please send your comments to the list. Thanks!
>
>
> BR
> Zaifeng



_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to