[Pana] Doubt regarding Stateless response to PCI msg

Raja ashok <raja.ashok@huawei.com> Sat, 20 August 2016 12:12 UTC

Return-Path: <raja.ashok@huawei.com>
X-Original-To: pana@ietfa.amsl.com
Delivered-To: pana@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9030B12D5A8 for <pana@ietfa.amsl.com>; Sat, 20 Aug 2016 05:12:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.457
X-Spam-Level:
X-Spam-Status: No, score=-5.457 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no
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 4BizoDDVDhQG for <pana@ietfa.amsl.com>; Sat, 20 Aug 2016 05:12:43 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F37BF127077 for <Pana@ietf.org>; Sat, 20 Aug 2016 05:12:41 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUS10231; Sat, 20 Aug 2016 12:12:38 +0000 (GMT)
Received: from BLREML408-HUB.china.huawei.com (10.20.4.47) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sat, 20 Aug 2016 13:12:37 +0100
Received: from BLREML502-MBX.china.huawei.com ([10.20.5.202]) by BLREML408-HUB.china.huawei.com ([10.20.4.47]) with mapi id 14.03.0235.001; Sat, 20 Aug 2016 17:42:25 +0530
From: Raja ashok <raja.ashok@huawei.com>
To: "basavaraj.patil@nokia.com" <basavaraj.patil@nokia.com>, "alper.yegin@yegin.org" <alper.yegin@yegin.org>, "jari.arkko@piuha.net" <jari.arkko@piuha.net>, "Pana@ietf.org" <Pana@ietf.org>
Thread-Topic: Doubt regarding Stateless response to PCI msg
Thread-Index: AdH63BvYrgtQo/A7QCqvc1R26cM98A==
Date: Sat, 20 Aug 2016 12:12:24 +0000
Message-ID: <FDFEA8C9B9B6BD4685DCC959079C81F5E18DE5AE@blreml502-mbx>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.213.121]
Content-Type: multipart/related; boundary="_004_FDFEA8C9B9B6BD4685DCC959079C81F5E18DE5AEblreml502mbx_"; type="multipart/alternative"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.57B84938.0021, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 85bf03953da090dfe17fee27c62b514e
Archived-At: <https://mailarchive.ietf.org/arch/msg/pana/izaBMSY9gY74yCf_SrAHHbCcT_I>
Subject: [Pana] Doubt regarding Stateless response to PCI msg
X-BeenThere: pana@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Protocol for carrying Authentication for Network Access <pana.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pana>, <mailto:pana-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pana/>
List-Post: <mailto:pana@ietf.org>
List-Help: <mailto:pana-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pana>, <mailto:pana-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Aug 2016 12:12:45 -0000

Hi All,

I am having a small doubt in PANA handshake of RFC 5191. Can you please clarify me.

PAA can respond to PCI msg in a stateless manner, by sending Cookie (as new AVP) in 1st PAR msg (similar to DTLS). This Cookie AVP was there in initial draft of RFC 5191, but in final RFC it is not there.  When I searched the mail list I got the below reason for removing Cookie AVP. But Still the suggested mechanism requires a state to be maintained with minimal information(Cookie, Initial seq, session ID). But this is still vulnerable to a DoS attack by flooding PCI msg.

So My doubt is, Is there any security loophole, if a Vendor specific Cookie AVP is used instead of minimal state maintenance. Please clarify my doubt.

$ Info from Old mail chain:
$  #2 Stateless handshake
$     * Simplification of the stateless handshake - Removal of L-bit ?
$        - Need to keep a minimum state to be maintained (cookie, initial seq)
$        - Adding PSR retransmission to this state is not a big issue
$     * Solution:
$        - Remove distinction between stateless and stateful
$        - Remove cookie avp
$        - Remove L-flag
$        - PSR re-transmission may be turned off if PAA wants to be stateless

Regards,
Ashok
________________________________
Raja Ashok V K
华为技术有限公司 Huawei Technologies Co., Ltd.
[Company_logo]

Phone:
Fax:
Mobile:
Email:
地址:深圳市龙岗区坂田华为基地 邮编:518129
Huawei Technologies Co., Ltd.
Bangalore, India.
http://www.huawei.com
________________________________
本邮件及其附件含有华为公司的保密信息,仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中
的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!
This e-mail and its attachments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!