Hi Yoav: Thanks for your email and sorry for my late response. Since Tricci has answered some of your questions, I would like to focus on "time-limited" issue. From my understanding, those FAP information (e.g. mode and allowed memeber groups) are relatively stable, hence, I assume the change of these information is quite rare, only in case the network is re-configured. Wouldn't you think that it is reasonable to assume that the FAP need to restart when the network is reconfigured? Since there is the femto management system, it is not hard to reboot the FAP by issuing an order from the femto management system remotely, without the involvement of human interference. Hence, I assumed that the core network always get the information from FAP, and the SeGW will not need to replay the notarized data to the core network. Does this make sense to you?
Thanks! BR Zaifeng Yoav Nir <[email protected]> 2012-01-22 23:04 收件人 "'[email protected]'" <[email protected]> 抄送 "[email protected]" <[email protected]> 主题 RE: Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt 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: [email protected] [mailto:[email protected]] Sent: 21 January 2012 11:08 To: Yoav Nir Cc: [email protected] 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 <[email protected]> 2012-01-21 15:30 收件人 "<[email protected]> <[email protected]>" <[email protected]> 抄送 "[email protected]" <[email protected]> 主题 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, <[email protected]> <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/ipsec
