Subject: Re: [radext] RADEXT charter

From: Alejandro Perez Mendez <[email-masked]>
Date: Tue, 05 Jun 2012 11:59:28 +0200

Dear all,

we have uploaded a new version of "Support of fragmentation of RADIUS 
packets" (draft-perez-radext-radius-fragmentation). You can find it at 
http://www.ietf.org/id/draft-perez-radext-radius-fragmentation-02.txt.

Most significant changes are:

  * New section discussing about the actual chunk size and why they
    cannot be 4096 bytes-length exactly. Includes a brief description of
    the mechanism for discovering the amount of data to be reserved for
    Proxy-State attributes.
  * State attribute. New section discussing how to deal with State
    attribute.
  * Proxies. New section discussing implications when leading with proxies.

Comments are welcome.

Regards,
Alejandro

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Tue, 05 Jun 2012 11:59:28 +0200

Dear all,

Comments are welcome.

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

---

From: Stefan Winter <[email-masked]>
Date: Wed, 27 Jun 2012 16:33:55 +0200

Hi,

>> It *could* be used the other way around though: when a user has logged
>> in somewhere, and the "somewhere" includes the Operator-Name attribute
>> (DNS-style), the home server could lookup the Operator-Name content in
>> DNS (NAPTR entry TBD) to find out where to send CoA packets for his user to.
>>
>> That would need lots of new text in the dyndisc draft - but I'm at it
>> anyway, so if there's some support for the idea on the list, this could
>> go in...
> 
>   I'd prefer to publish the document now.  Get it done, published, and
> deployed.

I'm currently preparing a new rev of the document. While looking through
it, I found that it's really easy to get DynAuth in - the only things
that change are the source of the input to the algorithm - instead of
User-Name, it's Operator-Name of namespace "1" without the "1"; and the
NAPTR tag to use.

Since it was so easy, I added corresponding text.

>   We can then have a separate document which addresses CoA proxying.  It
> can leverage 5580, and the dynamic discovery document.
> 
>   For anyone with spare time, see the git "master" branch on:
> 
> https://github.com/alandekok/freeradius-server/
> 
>   It has preliminary support for CoA proxying via Operator-Name.  This
> should be sufficient for multi-hop CoA proxying.

Sweet!

>   The remaining issue is how to get from the "local" RADIUS proxy to the
> NAS.  Using Operator-Name won't work, as the "local" proxy is
> authoritative for that realm.  Something else is needed, like a NAS
> identifier.
> 
>   We could use NAS-IP-Address.  But that could have been changed or
> deleted by anyone.  Maybe NAS-Identifier is a better choice.

Well, that could also have been changed, mangled, or deleted by a proxy.

Not really sure how to solve that "last mile". Maybe a hint in form of
an attribute might be needed, with semantics that forbids messing around
with it.

Like a new "CoA-Destination-NAS" or something like that; which gets sent
along with Operator-Name, and must be sent in the CoA packet when CoA is
executed.

Greetings,

Stefan Winter

>   Alan DeKok.

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Wed, 27 Jun 2012 16:33:55 +0200

Hi,

Sweet!

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473