Re: [Secauth] Please be volunteer to comment--- Summary of Telco on 19 December 2014

Rafa Marin Lopez <rafa@um.es> Tue, 13 January 2015 10:45 UTC

Return-Path: <rafa@um.es>
X-Original-To: secauth@ietfa.amsl.com
Delivered-To: secauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6461A8A8E for <secauth@ietfa.amsl.com>; Tue, 13 Jan 2015 02:45:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXlYd9UnusF8 for <secauth@ietfa.amsl.com>; Tue, 13 Jan 2015 02:45:50 -0800 (PST)
Received: from xenon24.um.es (xenon24.um.es [155.54.212.164]) by ietfa.amsl.com (Postfix) with ESMTP id 691421A8836 for <secauth@ietf.org>; Tue, 13 Jan 2015 02:45:50 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by xenon24.um.es (Postfix) with ESMTP id 2F7B1B75; Tue, 13 Jan 2015 11:45:49 +0100 (CET)
X-Virus-Scanned: by antispam in UMU at xenon24.um.es
Received: from xenon24.um.es ([127.0.0.1]) by localhost (xenon24.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CEUn322Qj+Fd; Tue, 13 Jan 2015 11:45:49 +0100 (CET)
Received: from [192.168.1.45] (26.Red-81-36-109.dynamicIP.rima-tde.net [81.36.109.26]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon24.um.es (Postfix) with ESMTPSA id 3AEE9B40; Tue, 13 Jan 2015 11:45:46 +0100 (CET)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Rafa Marin Lopez <rafa@um.es>
In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A7014D9FD0@lhreml504-mbs.china.huawei.com>
Date: Tue, 13 Jan 2015 11:45:45 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <84829CAD-0B52-4AD7-94A3-D98E555A9188@um.es>
References: <814D0BFB77D95844A01CA29B44CBF8A7014D9FD0@lhreml504-mbs.china.huawei.com>
To: Hosnieh Rafiee <hosnieh.rafiee@huawei.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secauth/WTq2snO3TI9ykbjOD-CvIE_lL-Y>
Cc: secauth@ietf.org
Subject: Re: [Secauth] Please be volunteer to comment--- Summary of Telco on 19 December 2014
X-BeenThere: secauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list <secauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secauth>, <mailto:secauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secauth/>
List-Post: <mailto:secauth@ietf.org>
List-Help: <mailto:secauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secauth>, <mailto:secauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Jan 2015 10:45:53 -0000

Hi Hosnieh:

Let me focus in the use case 1 to provide my comments.

The communication between SDN controllers (east-west interface) may be based in several protocols: RADIUS and Diameter. Or for example JSON (that is the case of trust routers https://tools.ietf.org/html/draft-mrw-abfab-trust-router-02 ). For Diameter, most probably there is no Diameter application of doing that but I am not sure. What it is true is 3g/4g operators have already defined ways of doing roaming so they may exchange SLA information in some way. It would be worthy asking them. 

For the case of southbound API, and the use case 1, I may use CAPWAP (http://tools.ietf.org/html/rfc5415). In fact, it seems others have thought about it https://wiki.opendaylight.org/view/Project_Proposals:CAPWAP. By the way, for the fast handoff and security between access points, IEEE 802.21a may be used since it allows a centralized way of doing authentication that (http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6704478) . So the PoS could be part of the SDN controller.

Another alternative, as well, it is to extend OpenFlow to provide this kind of function (e.g. distribution security policies and cryptographic material to the switch). Unfortunately, OpenFlow is not standardized in the IETF. For example, we are considering here at the University a model where IKE is in the SDN controller and IPsec in the switch. Now, how do we enforce IPsec security policies and cryptographic keys to the "switch"? Most probably an extension of OpenFlow would be the best and easier. But again that extension should be discussed in other place.

Best Regards.

El 08/01/2015, a las 14:28, Hosnieh Rafiee <hosnieh.rafiee@huawei.com> escribió:

> Folks,
> 
> Happy new year! I hope you start a good year and enjoyed your new year holiday and ready to activate the group again :-)
> 
> Here is the summary of the meeting
> - Presentation of available standards, secauth use cases, its possible scope,  
> - To remove use case 4 related to authentication of IoT to cloud system and only focus on SDN related solution
> - Discussion about adding the exact place (a picture or slide) to show where a protocol is missing and the exact scope of secauth.
> 
> Enclosed you can find the revision of slides used for the telco discussion on 19 December to consider the comments received during telco. Again thanks Alex, Rafa, Gabriel, Alan for sharing their opinions. 
> 
> Comments are welcomed. If you see something is unclear on slide and need any discussion just share it on the mailinglist.
> 
> 
> Thanks,
> Best,
> Hosnieh
> <secauth_SDN architecture_8.1.2015.pdf>_______________________________________________
> Secauth mailing list
> Secauth@ietf.org
> https://www.ietf.org/mailman/listinfo/secauth

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es
-------------------------------------------------------