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

From: Sam Hartman <[email-masked]>
Date: Wed, 12 Feb 2014 15:52:17 -0500

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

---

From: Jouni <[email-masked]>
Date: Wed, 12 Feb 2014 22:58:40 +0200

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:

> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext

---

From: Sam Hartman <[email-masked]>
Date: Wed, 12 Feb 2014 16:02:14 -0500

>>>>> "Jouni" == Jouni  <[email-masked]> writes:

    Jouni> One serious suggestion is just dropping the Diameter
    Jouni> considerations unless you really insist doing one. We have
    Jouni> not required one for some time already and that has not been
    Jouni> an issue during the publication process.

Great suggestion!
It's there only because back when I was on the IESG they seemed to be
required and I assumed they still were.

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 12 Feb 2014 15:14:06 -0600

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

---

From: Sam Hartman <[email-masked]>
Date: Wed, 12 Feb 2014 16:16:58 -0500

>>>>> "Behcet" == Behcet Sarikaya <[email-masked]> writes:

    Behcet>    Hi Jouni, RADIUS - Diameter interworking is important for
    Behcet> fmc (fixed mobile convergence), as you know the fixed
    Behcet> network uses RADIUS and 3GPP uses Diameter. So for example
    Behcet> when authenticating UE when connected via Wi-Fi to a fixed
    Behcet> broadband network, this interworking is needed.  Regards,

Excellent.

well, if you want to provide text for
draft-hartman-radext-bigger-packets section 4 I'll be happy to review
and if we get consensus on it include it.

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 12 Feb 2014 23:22:46 +0200

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 <[email-masked]> 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
> 
>

---

From: Alan DeKok <[email-masked]>
Date: Sat, 15 Feb 2014 17:41:17 -0500

Behcet Sarikaya wrote:
> Diameter. So for example when authenticating UE when connected via Wi-Fi
> to a fixed broadband network, this interworking is needed.

  The Diameter considerations could say something like:

Diameter already supports packets of 64K octets.  So any "large" RADIUS
packet can be transported in Diameter as-is.  Otherwise, any gateway
which does RADIUS to Diameter, or Diameter to RADIUS transport, MUST
follow this specification for any RADIUS interaction.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 18 Feb 2014 10:56:43 -0500

>>>>> "Alan" == Alan DeKok <[email-masked]> writes:

    Alan> Behcet Sarikaya wrote:
    >> 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.

    Alan>   The Diameter considerations could say something like:

    Alan> Diameter already supports packets of 64K octets.  So any
    Alan> "large" RADIUS packet can be transported in Diameter as-is.
    Alan> Otherwise, any gateway which does RADIUS to Diameter, or
    Alan> Diameter to RADIUS transport, MUST follow this specification
    Alan> for any RADIUS interaction.

Yeah, that's the easy part.
The hard part is what to do about the  response-length attribute.
I wrote up some of the issues in a previous message.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 18 Feb 2014 12:12:48 -0500

> The hard part is what to do about the  response-length attribute.

  To first order, it's irrelevant to Diameter.

  Inside of a Diameter routing system, packets of 64K are supported.  So
no changes or recommendations are required.

  Inside of a Diameter routing system, the Response-Length attribute can
be transported "as-is".  So no changes or recommendations are required.

  The issue is with RADIUS to Diameter gateways.

  My point is that these gateways implement RADIUS.  So any requirements
 are just requirements on the RADIUS portions.  These requirements are
already specified in the document.

> I wrote up some of the issues in a previous message.

  I can't find any comments related to Diameter and Response-Length in
previous messages.

  Alan DeKok.

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 19 Feb 2014 09:48:08 +0200

RFC4005bis i.e. to be RFC7155 has obsoleted all the automatic 
RADIUS-Diameter translation. It really is up to a specific
deployment and a specific document to define one. No one is
going to ask you for one from the process point of view but
you are of course free to do one. Though,  I would argue that
you need to go greater lengths than a paragraph to explain
Diameter considerations for this specification.

- Jouni