IETF Logo Mail Archive

Re: [radext] Extended IDs

"Naiming Shen (naiming)" <naiming@cisco.com> Wed, 13 December 2017 02:07 UTC

Return-Path: <naiming@cisco.com>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D051127909 for <radext@ietfa.amsl.com>; Tue, 12 Dec 2017 18:07:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level:
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 pvGdjlupxc02 for <radext@ietfa.amsl.com>; Tue, 12 Dec 2017 18:07:37 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88838126CBF for <radext@ietf.org>; Tue, 12 Dec 2017 18:07:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2292; q=dns/txt; s=iport; t=1513130857; x=1514340457; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=nSZQpeGEnyfc1JlZ2K5Hi5FO/MnUdLRysgK5CN53jJY=; b=U1sE+Hca2A0Fl3+LP/Bg146blLrs3kRUZTgAluZXZclp+fKElB55PD3I UjIaAzfcagg+1zujd5GfFsm85Bq8UqokTD4zdvmeZ8+IM7b5lCiMOKocI bBjAB2zbFrzu33hoVQs7X1d07zy0zsSQ2jBcXIaASAai88BPL/v3M0+wu c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DYAQCSijBa/4YNJK1dGQEBAQEBAQEBAQEBAQcBAQEBAYM+gVonB4N7mSaBfZcRghUKggGDOgIahG5BFgEBAQEBAQEBAWsohSMBAQEBAgEjEToLBQsCAQgYAgImAgICMBUQAgQOBYogCKg2gieKYAEBAQEBAQEBAQEBAQEBAQEBAQEBAR2BD4JUgguDaIMCgy+BWBaDFTGCMgEEoxcClSSTZ5Y3AhEZAYE6ASYKKIFObxU6KgGBfoRVeIk6gRUBAQE
X-IronPort-AV: E=Sophos;i="5.45,396,1508803200"; d="scan'208";a="113758052"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Dec 2017 02:07:36 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id vBD27aTV017225 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Dec 2017 02:07:36 GMT
Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 12 Dec 2017 20:07:36 -0600
Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1320.000; Tue, 12 Dec 2017 20:07:36 -0600
From: "Naiming Shen (naiming)" <naiming@cisco.com>
To: Peter Deacon <peterd@iea-software.com>
CC: "radext@ietf.org" <radext@ietf.org>
Thread-Topic: [radext] Extended IDs
Thread-Index: AQHTKHKrqtJDphnIu0Ga679ujWV4vKMqT+8AgBZxrICAAJ7zgIAADIgAgAACGYCAAAuaAIAABy4A
Date: Wed, 13 Dec 2017 02:07:36 +0000
Message-ID: <B41EF4CD-309C-4E0F-BE7A-B77A244DA421@cisco.com>
References: <fef698a5-9802-c9be-04d7-1e869651c988@restena.lu> <dfd0ff02-c9e8-7253-4fb4-1e6def3e93b2@restena.lu> <933E6F70-A7C1-4168-9AC9-F925EF78D9E2@jisc.ac.uk> <AE2036D0-1294-45B5-A0D7-16F91E0B4248@cisco.com> <alpine.WNT.2.21.1.1712121615090.2252@smurf> <EE3BB1A7-EAD9-4BE1-9EA2-B780580E5C95@cisco.com> <alpine.WNT.2.21.1.1712121704430.2252@smurf>
In-Reply-To: <alpine.WNT.2.21.1.1712121704430.2252@smurf>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.32.173.17]
Content-Type: text/plain; charset="utf-8"
Content-ID: <BAB108D59892564D8AFE7E00032770D3@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/smbRP9XHnmnBZBEmuEZnBUfmK68>
Subject: Re: [radext] Extended IDs
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Dec 2017 02:07:40 -0000

> On Dec 12, 2017, at 5:41 PM, Peter Deacon <peterd@iea-software.com> wrote:
> 
> On Wed, 13 Dec 2017, Naiming Shen (naiming) wrote:
> 
>> then the Client which initiated this can detect the returned packets, and terminate the extended-ID scheme. it’s up to the implementation to detect this.
> 
> How specifically can this be achieved?  What is your proposal?  Risks? Implementation complexity?

As the draft currently specified, the server-status message returned by the proxy/server has to match
the specified pattern/bits; the returned authentication-reply message has to match the id, extended-id,
if not there is an error. if the error is accumulated, the radius-client should know. simple to implement.

> 
>> also I can not imaging the server-status will be returned to the Client correctly in this case to ‘fool’ the Client the Proxy-A supports this feature.
> 
> Does extended id draft support manual configuration?

The draft specifiies the mechanism, not the operations. But my patch for this draft on FreeRadius,
does support manual configuration on the client and proxy. I sent my patch to this mailing list
months ago. This is the way to show how simple this mechanism. With client/proxy/server, with
tested on UDP/TCP, total of 200 lines of C code.

> 
> The question on the table is not whether extended id is good or bad in a vacuum.  The question is which of the options is technically the better option on the merits.

I understand. This is why I think draft-chen is the better one. simple, not overloading
the original radius header definitions, easy to implement.

Regards,
- Naiming

> 
> regards,
> Peter

v2.23.0 | Report a Bug | By Email