Re: [radext] Help with diameter considerations for draft-hartman-radext-bigger-packets

Jouni Korhonen <jouni.nospam@gmail.com> Wed, 12 February 2014 21:22 UTC

Return-Path: <jouni.nospam@gmail.com>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34A5C1A06CE for <radext@ietfa.amsl.com>; Wed, 12 Feb 2014 13:22:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 S_CmxDHrTB-y for <radext@ietfa.amsl.com>; Wed, 12 Feb 2014 13:22:51 -0800 (PST)
Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 586081A06E3 for <radext@ietf.org>; Wed, 12 Feb 2014 13:22:51 -0800 (PST)
Received: by mail-lb0-f174.google.com with SMTP id l4so7480327lbv.5 for <radext@ietf.org>; Wed, 12 Feb 2014 13:22:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=tNDTk02T+tgBr+Sy32DXgU/NpYlX7x2T42oVcaA80Vw=; b=sVSFavUrl7lBKyjXgomgj9aR/gA1ZlZBG5+1yc22z99p6vJ8NA1eYMuq7iY4io0iXn BkYlivPn50a/KAHRLAcSyJOr+f9Ka+WvHupwOztDZkVTSkZCbltWX+KC+Tf4McQWsAdT 3a9c13f3DTD7dVoykZt7moQQY/kO2jUaWiI84c1xMS4lbeLNPF3JdKVI7gLQJeuyVoxC +zhd5YVM46mkSgoVNOcpJVGvIfaPZiU8OvqchIm72VX0PHj7d7IOqdSKg2nbMAwSna1S s3yXwut47G4RhADjhX6tXaE9lc9dr5pbCnoSSFqP3fwR/PQHTzabEsD0YnV/IakIUC+j h1NQ==
X-Received: by 10.152.201.197 with SMTP id kc5mr3314lac.77.1392240169775; Wed, 12 Feb 2014 13:22:49 -0800 (PST)
Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id ya9sm25231897lbb.2.2014.02.12.13.22.46 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 12 Feb 2014 13:22:47 -0800 (PST)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen <jouni.nospam@gmail.com>
In-Reply-To: <CAC8QAcePKh4KC=8fY69N4HWPfk=-XXCYxZRwf-uTq07jO3qYsQ@mail.gmail.com>
Date: Wed, 12 Feb 2014 23:22:46 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <9E7529E0-AA1D-4345-9C3D-B844932719BF@gmail.com>
References: <tsl4n44rr3y.fsf@mit.edu> <CCE45314-4EFE-4C64-9794-85006392F834@gmail.com> <CAC8QAcePKh4KC=8fY69N4HWPfk=-XXCYxZRwf-uTq07jO3qYsQ@mail.gmail.com>
To: sarikaya@ieee.org
X-Mailer: Apple Mail (2.1510)
Cc: Sam Hartman <hartmans@painless-security.com>, "radext@ietf.org" <radext@ietf.org>
Subject: Re: [radext] Help with diameter considerations for draft-hartman-radext-bigger-packets
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 12 Feb 2014 21:22:54 -0000

When you do your 3GPP/BBF interface specification (or update some existing 3GPP/BBF specification) define the translation/interworking in that spec. IMHO that's where it belongs since the logic & implementation will anyway be very deployment specific. Defining a translation for anything than very basic & simple authentication has proven to be just handwaving in IETF space.

- Jouni


On Feb 12, 2014, at 11:14 PM, Behcet Sarikaya <sarikaya2012@gmail.com> wrote:

> Hi Jouni,
> 
> RADIUS - Diameter interworking is important for fmc (fixed mobile convergence), as you know the fixed network uses RADIUS and 3GPP uses Diameter. So for example when authenticating UE when connected via Wi-Fi to a fixed broadband network, this interworking is needed.
> 
> Regards,
> 
> Behcet
> 
> 
> On Wed, Feb 12, 2014 at 2:58 PM, Jouni <jouni.nospam@gmail.com> wrote:
> 
> One serious suggestion is just dropping the Diameter considerations
> unless you really insist doing one. We have not required one for some
> time already and that has not been an issue during the publication
> process.
> 
> - Jouni
> 
> 
> On Feb 12, 2014, at 10:52 PM, Sam Hartman wrote:
> 
> >
> >
> > Hi folks.  I could use some help with the diameter considerations
> > section for draft-hartman-radext-bigger-packets.
> >
> > First, what value should  a proxy forwarding from a diameter client to a
> > radius server include for the maximum-response-length attribute?
> >
> > When forwarding from radius towards a diameter server, what should
> > happen with regard to the maximum-response-length attribute:
> >
> > * Strip it as diameter doesn't expect it
> >
> > * Keep it if present.  Perhaps diameter will trim down its response
> >
> > * Insert it  if the transport in the radius direction is UDP--after all,
> >  might as well let diameter know what's going on.
> >
> > Another thing to consider here is interactions with
> > radius-diameter-radius situations.
> >
> > --Sam
> >
> > _______________________________________________
> > radext mailing list
> > radext@ietf.org
> > https://www.ietf.org/mailman/listinfo/radext
> 
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext
>