Subject: [radext] Meeting laundry list

From: Peter Deacon <[email-masked]>
Date: Wed, 13 Mar 2013 11:07:52 -0700 (Pacific Daylight Time)

Some thoughts from meeting.

-----
RADIUS/DTLS

I still think my scheme using 4 byte header from issue #64 in the 
tracker could be useful to improve DTLS draft for following reasons.

- Remove dependencies on TLS content type and RADIUS packet code

- Prevent sync problems with UDP NAT state association

- Allow single DTLS session to be used to support more than 255 
unacknowledged requests.  This would simplify client implementations from 
having to pool and maintain multiple sessions to the same server.

- Resolves "pothole" problem where a source port is selected from which 
RADIUS server already has an open session and therefore ignores anything 
not associated to the session.

-----
Stefan - loop detection

We have had a trivial proxy loop detection system in production in our 
implementations for several years.  It works on the assumption any request 
the same proxy system sees again completes a cycle.

In our implementation a systems identifier is embedded in the proxy state 
attribute.  When a request for proxy is received we check for matching 
system identifier in the current stack of proxy states and drop the 
request if one is found.

-----
ieee802ext

Had a chance to read thru this draft a bit before and after the 
meeting - looks good here.

-----
Datatypes

I like the general idea of a type registry that can be referenced but I'm 
not sure how much utility there is at this point.

It could see it being more expressive to have a new complex type in the 
registry to map things we don't want to add a separate entry for like 
Tunnel-Password rather than collapsing to string.

Thanks to chairs and all for a great meeting :)

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Wed, 13 Mar 2013 21:39:12 -0400

Peter Deacon wrote:
> Datatypes
> 
> I like the general idea of a type registry that can be referenced but
> I'm not sure how much utility there is at this point.
> 

  This seems reasonable.

  There are 26 "string" attributes defined in the RFCs.  Of these, only
a few appear to be carrying raw data.  Many carry pre-defined complex
data types.

  Alan DeKok.

---

From: Stefan Winter <[email-masked]>
Date: Tue, 19 Mar 2013 09:42:08 +0100

Hi,

> implementations for several years.  It works on the assumption any
> request the same proxy system sees again completes a cycle.
> 
> In our implementation a systems identifier is embedded in the proxy
> state attribute.  When a request for proxy is received we check for
> matching system identifier in the current stack of proxy states and drop
> the request if one is found.

Many of those who implement loop checking in eduroam do similarly: they
use their own VSA space to

* in incoming packets, check for presence of their VSA like
"Processed-By: my.ip.ad.dr" (or other halfways unique ID)
* If found, discard and log loop
* if not found, add "Processed-By: my.ip.ad.dr" (or other halfways
unique ID) and process packet

That's simple and straightforward indeed. The problem I have is that
such a behaviour is not specified anywhere, and doesn't have its own
attribute.

You overload Proxy-State; which is fine if you don't need it for
anything else.

I don't really care if that use of Proxy-State gets standardised, or if
a new attribute is chosen. But having one deterministic way of doing
things, along with a document which explains the how and why, instead of
everyone doing his own variant on its own, is a GoodThing(tm) IMHO.

That is after all what Standardisation Organisations are made for :-)

Greetings,

Stefan Winter

> 
> -----
> ieee802ext
> 
> Had a chance to read thru this draft a bit before and after the meeting
> - looks good here.
> 
> -----
> Datatypes
> 
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext

-- 
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: Peter Deacon <[email-masked]>
Date: Tue, 19 Mar 2013 08:13:57 -0700 (Pacific Daylight Time)

> You overload Proxy-State; which is fine if you don't need it for

I don't know that "overload" is applicable in this context or why it 
couldn't be used for multiple purposes concurrently.

Proxy-State is defined as an opaque field.  Its purpose is left 
intentionally out of scope RFC2865 5.33

"      Usage of the Proxy-State Attribute is implementation dependent.  A
       description of its function is outside the scope of this
       specification.
"

> everyone doing his own variant on its own, is a GoodThing(tm) IMHO.

We don't really know generally what constitutes a "loop" or granularity of 
the system box (Parts of one server or entire groups of servers). 
Messages may be able to loop back for another round of processing after 
being sent outside the admin domain.

Seems easy enough to create one-off solutions yet very difficult to solve 
generally.

Perhaps some general guidance or blunt tools like TTLs on stack of 
proxy-states.

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Tue, 19 Mar 2013 11:21:04 -0400

> couldn't be used for multiple purposes concurrently.

  Yeah.  Fill it with whatever makes you happy.

> We don't really know generally what constitutes a "loop" or granularity
> of the system box (Parts of one server or entire groups of servers).

  I agree.  I think using an opaque token is a good idea.  Using an IP
address is more fragile, and prone to disclosing private information.

> Perhaps some general guidance or blunt tools like TTLs on stack of

  FreeRADIUS just has a config option which says "too many".  It's good
for blunt checks.

  Having some guidance for detecting proxy loops would be good.

  Alan DeKok.

---

From: Stefan Winter <[email-masked]>
Date: Wed, 20 Mar 2013 10:12:07 +0100

Hi,

> address is more fragile, and prone to disclosing private information.

Sure; my use of "(or other halfways unique ID)" is basically about cases
where one needs to control granularity.

E.g. I have two redundant servers in failover: tld1.eduroam.lu and
tld2.eduroam.lu - the ID could then be "tld.eduroam.lu" to indicate that
the packet went through either of the two already and shouldn't come
back later.

Of course even loops that ping-pong between multiple hops would
eventually be detected, as soon as the packet comes back to one of the
servers which used his own mark. So in effect any random value is good
enough, doesn't have to be an IP address. It has to be random enough
though, so that no two hops accidently use the same ID.

>   Having some guidance for detecting proxy loops would be good.

Yes! It's good to hear that Peter's implementation does some magic with
Proxy-State - but it would be even better to write down something like
that for every implementation's benefit. E.g. in FreeRADIUS Proxy-State
is not under config control and it doesn't do such clever comparisons
yet. With a good spec, this could become a config switch
"do_loop_checks" which would do all that Proxy-State magic
automatically, without any fiddling with VSAs and such.

I wonder if Peter feels like putting this into an I-D...?

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473