Subject: [Dime] review of draft-korhonen-dime-nai-routing-00

From: Stefan Winter <[email-masked]>
Date: Wed, 13 Aug 2008 13:15:02 +0200

Hello,

2. Terminology
---------------------
The definition of NAI could use a reference to RFC4282.

The definition of NAP is quite ambiguous ("entity which owns the 
network" - this even applies to the physical person Stefan Winter, since 
I own a network at home and I am an entity) . Later in the text I 
figured that it is the first-hop Diameter server (right?), taking access 
requests from NASes, and either handling them itself or 
routing/forwarding them according to realms.

3. Prob Overview
------------------------

First bullet: "

The update would be done by intermediating Diameter agents that participate to
      realm based request routing.  Specifically, this would concern
      Diameter proxies."

It would concern ONLY proxies, right? Relays, Redirectors and translation agents should not mess with the User-Name AVP in this context. So, I'd suggest to remove the general mention of agents in the first sentence and make clear that it only concerns proxy agents.

4.1 Enhanced Request Routing solution
-------------------------------------

RFC4282 makes clear that the presence of a ! in the user name part does not necessarily mean that the username is decorated (since a ! can also be "just" part of a username, with no special decoration meaning). Which I find very uneasy in RFC4282, as it opens room for speculation on how a node should determine if the username it got should be treated as decorated or not.
This room for speculation makes this draft harder to handle. Section 4.1 is silent in how exactly to determine whether a User-Name AVP is decorated. That being said, once the fact is determined, the three bullets make a reasonable alogrithm IMHO. So maybe the algorithm should be preceded with a lookup (see below). The last bullet should read though:"... using the normal request routing _or request forwarding_ rules as defined ..." since the last hop before the home realm will by definition do realm forwarding, not routing, since that peer will be directly connected.

4.1 Figure 2
------------

When 2) is reached, the conversion of the next hop cannot happen completely automatically because the possible meaninglessness of ! needs to be taken into account. Furthermore, RFC4282 states that "the interpretation of the username is up to an agreement between the identified user and the realm given after the @" The decision path for Realm-Z when receiving the request needs to be:

- incoming User-Name = realm-X!realm-H!username@realm-Z
- decide: is there an agreement between username and me that I should treat ! in the local part as special character?
  * Yes: continue as in the depicted flow
  * No: treat as local request where the user's name spans the entire "realm-X!realm-H!username"

Needless to say that it is rather difficult for the server for realm-Z to have an agreement with a roaming user from realm-H (since the two have no direct relation to each other, other than that a Diameter routing path between Z and H exists). As a sidenote, the possible meaninglessness of ! in RFC4282 makes life more complicated than I'd like to.

4.2 Backwards Compatibility
---------------------------
The decision to not recommend implementation in existing Apps takes out a lot of value from this draft. One of its primary uses would be NASREQ, for example. The mechanisms in this document have such a wide-reaching use that I would much rather recommend to put it into 3588bis and require it also for existing Apps.
Also the two statements "RECOMMENDED... only applied for new applications" and "MAY also in existing applications" (paraphrased) is contradicting. It is either not recommended to retrofit it into existing apps, or it is completely optional.

Greetings,

Stefan Winter

P.S.: I foolishly agreed to make another review, one of the QoS documents. I don't quite remember which of the three, and the minutes aren't out yet. Can someone remind me of my duties?

-- 
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

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

---

From: <[email-masked]>
Date: Wed, 13 Aug 2008 15:19:37 +0200

Hi Stefan,

Thanks for the review! See some comments inline.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Stefan Winter
> Sent: 13. elokuuta 2008 14:15
> To: [email-masked]
> Subject: [Dime] review of draft-korhonen-dime-nai-routing-00
> 
> 
> Hello,
> 
> 2. Terminology
> ---------------------

Ups. OK.

> I own a network at home and I am an entity) . Later in the text I 

It could be you.. assuming you manage and have access to
AAA roaming infra from you NAS etc.

> routing/forwarding them according to realms.

It could be like this. A NAP may though also own & manage
only access points and NASes .

> It would concern ONLY proxies, right? Relays, Redirectors and 
> translation agents should not mess with the User-Name AVP in 
> this context. So, I'd suggest to remove the general mention 
> of agents in the first sentence and make clear that it only 
> concerns proxy agents.

Currently, the text applies only to proxies. The unpublished first
version of the I-D also covered relays. We still play with the
idea of relays as some of us feel that the I-D should also
cover them.

If we end up with proxies only, the text should be more
precise then as you noted.

> RFC4282 makes clear that the presence of a ! in the user name 
> part does not necessarily mean that the username is decorated 
> (since a ! can also be "just" part of a username, with no 
> special decoration meaning). Which I find very uneasy in 
> RFC4282, as it opens room for speculation on how a node 
> should determine if the username it got should be treated as 
> decorated or not.

One more reason for this I-D.. and the fact that we propose
using NAI decoration only when new applications are defined.

> This room for speculation makes this draft harder to handle. 
> Section 4.1 is silent in how exactly to determine whether a 
> User-Name AVP is decorated. That being said, once the fact is 

Section 4.2 recommends that NAI decoration is only applied
to new applications. This way the application definition can
explicitly state that within the application NAI decoration
must be supported. I don't think we have a better way to
determine whether NAI is decorated or not.

> determined, the three bullets make a reasonable alogrithm 
> IMHO. So maybe the algorithm should be preceded with a lookup 
> (see below). The last bullet should read though:"... using 
> the normal request routing _or request forwarding_ rules as 
> defined ..." since the last hop before the home realm will by 
> definition do realm forwarding, not routing, since that peer 
> will be directly connected.

Ok.

> 
> 4.1 Figure 2
> ------------
> 
> When 2) is reached, the conversion of the next hop cannot 
> happen completely automatically because the possible 
> meaninglessness of ! needs to be taken into account. 

See above on this.

> Furthermore, RFC4282 states that "the interpretation of the 
> username is up to an agreement between the identified user 
> and the realm given after the @" The decision path for 
> Realm-Z when receiving the request needs to be:
> 
> - decide: is there an agreement between username and me that 
> I should treat ! in the local part as special character?

Well.. The NAS is supposed to know this by configuration. E.g.
if the NAS were to use EAP application, there is no quarantee
of the interpretation of '!'. On the other hand, if the NAS
were to use EAP-With-Steroids application, which knows about
decoration, the interpretation of '!' is quaranteed.

I will clarify this.

> Needless to say that it is rather difficult for the server 
> for realm-Z to have an agreement with a roaming user from 
> realm-H (since the two have no direct relation to each other, 
> other than that a Diameter routing path between Z and H 

Why not? Such roaming arrangements are already valid.

> exists). As a sidenote, the possible meaninglessness of ! in 
> RFC4282 makes life more complicated than I'd like to.

In a commercial world.. when someone joins to a certain roaming
consortium they need to accept and adhere to certain rules and
guidelines. If the roaming consortium mandates support for NAI
decoration, there is no room for misinterpretations.

> The decision to not recommend implementation in existing Apps 
> takes out a lot of value from this draft. One of its primary 
> uses would be NASREQ, for example. The mechanisms in this 
> document have such a wide-reaching use that I would much 
> rather recommend to put it into 3588bis and require it also 
> for existing Apps.

You don't just gain backwards compatibility with existing
implementations.. if those application won't change their
existing code.

A simple way to migrate from NASREQ is for example to
define a NASREQv2 application, which is identical to
RFC4005 except that it refers to this I-D on User-Name
part etc.

> Also the two statements "RECOMMENDED... only applied for new 
> applications" and "MAY also in existing applications" 
> (paraphrased) is contradicting. It is either not recommended 
> to retrofit it into existing apps, or it is completely optional.

Hmm.. agree. I would appreciate better way to express the following:

For new applications it is recommended to implement this I-D
to quarantee support for NAI decoration. IMHO, we cannot mandate it
for every new application. Also there are existing specifications
that simply mandate support for NAI decoration for existing EAP and
NASREQ applications but are applicable _only_ for a certain well
defined system within certain releases of that same system.. ;)

Cheers,
	Jouni

> 
> Greetings,
> 
> Stefan Winter
> 
> P.S.: I foolishly agreed to make another review, one of the 
> QoS documents. I don't quite remember which of the three, and 
> the minutes aren't out yet. Can someone remind me of my duties?
> 
> 
> -- 
> Stefan WINTER
> Ingenieur de Recherche

---

From: Stefan Winter <[email-masked]>
Date: Thu, 14 Aug 2008 14:53:03 +0200

Hi,

> AAA roaming infra from you NAS etc.

Hm. The NAPs in this document need to perform AVP re-writing and talk 
on-the-wire to Diameter servers. I usually don't do this personally, but 
have computing devices to do that for me. Maybe narrowing down "entity" 
to "a computing device which is authoritative for AAA message exchanges 
in the network" might do?

> only access points and NASes .

But still it would need to *do* something with the Diameter messages 
which are originated from these access points and other NASes. That 
makes the thing a Diameter agent (not necessarily a full-blown server, 
admitted).

> determine whether NAI is decorated or not.

A new Diameter application doesn't fully solve this problem, because it 
is an adminitrative one. You can require NASREQv2 to support NAI 
decorations, but you could still encounter a roaming partner who chooses 
to have exclamation marks in his usernames and who *doesn't want to* 
have these treated as decorated. I admit that in certain locked-down 
roaming consortia, this is probably not an issue :-)

> decoration, the interpretation of '!' is quaranteed.

In the general case, no, see above. You can require support, but you can 
not assume that "the world at large" opts in to restrict itself to only 
use exclamation marks for decoration purposes. Unless a imaginary 
NASREQv2 spec would *forbid the use of exclamation marks* unless used 
for NAI decoration. Is that a road you want to go down? Then, yes, we 
are safe, but existing deployments which use ! might be disgruntled.

> Why not? Such roaming arrangements are already valid.

Any single one of the NAPs must know of all realms that are potentially 
reachable (the entire federation) and whether or not each of those uses 
! as decoration or as part of the username. Again, I admit that in, say, 
the 3GPP world, this is trivially a No-Op because ! don't show up as 
normal parts of the user name. But there may be others.

> decoration, there is no room for misinterpretations.

Yes. That makes deployment easy in that particular roaming consortium.

> RFC4005 except that it refers to this I-D on User-Name

Are you willing to update all Diameter App RFCs to get this one thing in?

> defined system within certain releases of that same system.. ;)

Understood. Well, this one could be resolved rather simple: Just leave 
the MAY sentence out. The text says RECOMMENDED only for new apps - 
which is equivalent to saying NOT RECOMMENDED for existing apps. Looking 
up "NOT RECOMMENDED" in RFC2119:

" ...mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label."

Which is pretty much exactly you expressed above. :-)

Greetings,

Stefan

Tel: +352 424409 1
Fax: +352 422473

---

From: <[email-masked]>
Date: Thu, 14 Aug 2008 15:19:46 +0200

Hi Stefan,

See some comments inline.

> From: Stefan Winter [mailto:[email-masked]] 
> Sent: 14. elokuuta 2008 15:53
> To: Korhonen, Jouni /TeliaSonera Finland Oyj
> Cc: [email-masked]
> Subject: Re: [Dime] review of draft-korhonen-dime-nai-routing-00
> 
> 
> Hi,
> 
> on-the-wire to Diameter servers. I usually don't do this 

Hmm.. can you give an example?

> personally, but 

Otherwise OK but don'y like the "computing device".

> roaming consortia, this is probably not an issue :-)

These things don't get deployed in wild. And if the imaginary NASREQv2
would mandate something, deviating from it would be a violation of the
application specification. It would be spottet latest during the
interop.. of some (roaming) consortia.

> are safe, but existing deployments which use ! might be disgruntled.

If the nai-routing I-D mandates a certain behavior and interpretation of
NAIs, then new applications that claim compliance with nai-routing I-D must
simply have an uniform interpretation of what is inside the NAI. 

> reachable (the entire federation) and whether or not each of 

This is a separate issue, which is out of scope of this I-D.

> those uses 

Why would I need to update existing applications specifications.
The imaginary NASREQv2 would be a new standalone application and
require a new RFC. The implementation would just be 99% identical
with RFC4005. No need to touch legacy.

> Which is pretty much exactly you expressed above. :-)

Thanks!

Cheers,
	Jouni

---

From: Stefan Winter <[email-masked]>
Date: Thu, 14 Aug 2008 15:48:53 +0200

Hi,

> Hmm.. can you give an example?

Like, taking EAP-Identity out of a 802.1X exchange and re-packaging it 
into a Diameter request and sending it to a Diameter server.

> Otherwise OK but don'y like the "computing device".

I would settle for just "device" :-)

> interop.. of some (roaming) consortia.

Okay.

> simply have an uniform interpretation of what is inside the NAI. 

Does the NAI I-D currently mandate that all occurence of ! MUST be 
considered a NAI decoration? I haven't seen that yet... Adding that 
requirement would clear a lot of things up!

> This is a separate issue, which is out of scope of this I-D.

The MUST above would also make this here more clear, because then the 
ambiguity of the role of ! would be gone.

> with RFC4005. No need to touch legacy.

I meant update as in RFC[NASREQv2] formally updates (IETF-Style) 
RFC4005. Or even obsoletes. Or do you mean the two (NASREQ, NASREQv2) 
should co-exist besides each other? Something like a "fork" as you would 
call it in software engineering?

Greetings,

Stefan

Tel: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Mon, 18 Aug 2008 15:57:54 +0200

Hi,

>> Like, taking EAP-Identity out of a 802.1X exchange and re-packaging 
>> it into a Diameter request and sending it to a Diameter server.
>
> Ah ok. I though this is business as usual. Is there any specific issue
> with it?

No, other than that it performs operations that in the AAA world are 
usually performed by a NAS. Hence my suggestion below:

> Hmm.. I'll try to come up with a better description of NAP. I am not
> happy with the "device" either ;)

My suggestion is to forget about the word NAP and replace it by NAS. 
Rationale: the draft's core point is to describe how to re-write 
decorations until the home realm is reached. The entity NAP which is 
introduced in the draft is not essential to this process. In fact, it 
just ships Diameter messages to the realm server and that *server* is 
the one needing to do re-writing.
Looking at the Problem Description again, the word NAS is used nowhere, 
but is constantly replaced with NAPs. Now given that NAS is a more 
common term in RADIUS and Diameter, while NAP isn't, and that the entity 
described as NAP does essentially the same things as usually a NAS does, 
why not just say NAS. In fact, there are multiple occurences where you 
write NAP/NAS, giving a hint that the two are indeed interchangeable.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Jouni <[email-masked]>
Date: Tue, 19 Aug 2008 09:34:48 +0300

Hi Stefan,

> the one needing to do re-writing.

Right, I'll look into this.

> Looking at the Problem Description again, the word NAS is used 
> nowhere, but is constantly replaced with NAPs. Now given that NAS is a 
> more common term in RADIUS and Diameter, while NAP isn't, and that the 
> entity described as NAP does essentially the same things as usually a 
> NAS does, why not just say NAS. In fact, there are multiple occurences 
> where you write NAP/NAS, giving a hint that the two are indeed 
> interchangeable.
Right, you got a point there. However, in my domain of "roaming world" 
NAP is commonly used to describe the functional / commercial entity
that operates a NAS (or a plethora of NASes) and maybe has a complex 
internal proxy network, hence the preference of NAP over NAS.

How about:

"Network Access Provider (NAP):

  A business entity that provides network access infrastructure to one or
  realms. A NAP infrastructure constitutes one or more NASes.

 Network Access Server (NAS):

  The device that peers connect to in order to obtain access to the
  network and is authoritative for AAA message exchanges in the
  NAP infrastructure.
"

Keep this in the terminology and then use the NAP/NAS throughout the 
document...?

Cheers,
    Jouni

---

From: Stefan Winter <[email-masked]>
Date: Thu, 21 Aug 2008 08:58:22 +0200

> internal proxy network, hence the preference of NAP over NAS.
A "NAS aggregator" maybe? Interesting.

To me this reads like "Our NAPs are NASes which are more complicated and 
sophisticated than most other NASes." (and I would counter that with: 
but they are still some sort of NAS, so using the term NAS would cover 
them nicely)
>  A business entity that provides network access infrastructure to one 
> or [SW: ... more ...]

It's just a matter of personal taste I guess. The above looks already a 
lot cleaner than before. My preference though would be to stick with 
just NAS as it looks like the more general wording. Then again, I'm the 
new kid in town on this mailing list so my humbleness dictates that I'll 
yield and accept a rough consensus for any of these two choices :-)

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473