[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: rfc2486bis
This raises some very good questions:
In the roaming world, while the 'private' peering of RADIUS servers
would allow for a non-FQDN to be used for the purposes of routing, i.e.
user@foo or even user@XZY, the common practice is to use a FQDN i.e.
user@foo.com or foo.bar.com or foo.org,etc. However, there is no
reasonable expectation that the FQDN be actually registered or owned by
the home network and placed in DNS. Since the peering is ambiguous and
often private, I could just as well claim coke.com for my users or use
some semblance of a FQDN, registered or not. Obviously using a private
IP would be bad, but using non DNS methods like blair@216.239.97.170 is
valid, right? So why not a non-FQDN blair@myhome if the private RADIUS
peering recognizes it. Any thoughts on guidelines for this?
Another question in regards to the current conversation...
In a roaming application where there is a mediating network whose RADIUS
exchange must be selected and transited in order to resolve private
peering, is there any qualification which requires a FQDN? We all know
that the use of a prefix to select and exchange i.e. IPASS/user@foo.com
and or chained suffix to do so, i.e. user@foo.com@IPASS or
user@foo.com@ipass.com is common practice... Can the '%' or '!' be used
in combination with a non-FQDN as an alternative method for this NAI
construction without applying an invalid syntax? i.e.
IPASS%user@foo.com or ipass!user@foo.com rather than using a
non-reserved delimiter such as '/' or 'chaining' the suffix which is
described as illegal in the previous articles? Again, use of non-FQDNs
for the purposes of navigating private RADIUS exchanges is absolutely
necessary, but the current (and past) NAI examples don't reflect these
emerged models very well.
And a question in regards to the latest NAI proposals...
What is the basis for the 'position' swapping in the latest draft?
Changing ...
user@foo.com to
"foo.com!user@intermediary.com"
...breaks today's practice and would significantly impact the way in
which networks peer today. Is there a compelling reason for this or is
it merely a proposal to once and for all formalize the inter-network NAI
construction. There are some significant issues with this approach,
particularly in reflecting today's business models and practices of NAI
construction.
Thank you for your consideration.
Best Regards,
Blair
-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Friday, March 19, 2004 3:28 AM
To: stefaan.de_cnodder@alcatel.be; jari.arkko@piuha.net
Cc: radiusext@ops.ietf.org
Subject: RE: rfc2486bis
> I see that in the new draft the example "fred@foo" becomes now a valid
> NAI because the definition of the realm changed compard to the
> original RFC, but in naibis it is still in the invalid list - but that
> has to be changed I guess?
>
> Could there also be the following problem: "eng!nancy@bigu.edu" was
> valid in the original RFC2486. Now how do I know whether the username
> is "eng!nancy", which is a valid username, or is the username "nancy"
> and homerealm "eng"? I believe it is better to use another symbol than
> "!" such as ":"?
>
I hope/assume that everyone knows/understands that we do not accept such
examples in RFCs. We want them to be of the form:
someone@example.com
foo@bar.example.com
or some such.
See ID-NITs at http://www.ietf.org/ID-nits.html
Which says:
o Addresses used in examples should prefer use of fully qualified
domain names to literal IP addresses, and prefer use of example
fqdn's such as foo.example.com to real-world fqdn's
See RFC 2606 for example domain names that can be used.
There is also a range of IP addresses set aside for this purpose.
These are 192.0.2.0/24 (see RFC 3330). Private addressess that
would be used in the real world should be avoided in examples.
Bert
> regards,
>
> Stefaan
>
>
>
> Jari Arkko wrote:
> >
> > Bernard Aboba wrote:
> > >>1) examples in section 2.8: why is @howard.edu an invalid NAI? And
> > >>why has eng%nancy@bigu.edu been removed from the list of
> valid NAIs
> > >>compared to RFC2486? I believe it is still valid, or should it be
> > >>put in the list of invalid NAIs?
> > >
> > >
> > > Good catch. RFC 2486bis should not be introducing
> non-backward compatible
> > > changes.
> >
> > Yes. Thanks Stefaan for your comments!
> >
> > @howard.edu was actually listed as an illegal example
> > in RFC 2486; the introduction of the privacy feature
> > makes this now legal.
> >
> > eng%nancy@bigu.edu is still legal. I removed it
> > as a part of providing a new set of examples, but
> > since there are questions about it, maybe I should
> > put it back in just to avoid people wondering whether
> > it has been made illegal.
> >
> > > 2) Would it not be better to define the nai in 2.1 as follows:
> > >
> > > nai = [realm "!"] ( <....> )
> > >
> > > with <....> the current nai defintion. This to make the
> explanation
> > > in section 2.7 more formal.
> >
> > Ok.
> >
> > > 3) typo: a quotation mark too much at the end in the nai
> definition
> > > in 2.1.
> >
> > Yes. Kalle Tammela also noticed this issue.
> >
> > I have corrected the above issues in
> >
> > http://www.arkko.com/publications/nai/naibis.txt
> >
> > --Jari
>
> --
> to unsubscribe send a message to radiusext-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>