Hi, > When relying on S-NAPTR (RFC3958), redirection is only possible inside > sub-domains of the original domain name.
I don't think that's true. RFC3958 has exactly this use case in it's first example section (2.2): a domain example.com redirects service "EM:protA" to another domain, namely someisp.example - with the non-terminal flag, as I described in my original mail. This is absolutely a different domain name. > This is a restriction compared to the use of normal NAPTR and REGEXP. While making my own experiences with NAPTR, I learned that there is no "normal" use of NAPTR. NAPTR records are not allowed to be used "in the wild" without a valid DDDS specification defining its exact semantics. That is precisely the reason why RFC3588 had to be revised in that regard. RFC3958 provides that semantics, so it was a natural choice to re-base Diameter's usage in an S-NAPTR. > The following recommendations can be also found in the RFC6733: "The domain > suffixes in the NAPTR replacement field SHOULD match the domain of the > original query." Actually, I don't even understand the "SHOULD" here without > any clarification on what to do if not... but it is another debate. I now see that RFC6733 has put this IMHO arbitrary restriction in place. It really serves no particular purpose; if there was some thinking behind it, then that really should have been explained in the document. I would tend to ignore that SHOULD if I were implementing Diameter (I'm not :-) ). Different domain names are perfectly in scope for S-NAPTRs, and you would have to consciously lobotomise libraries or code snippets to *not* permit redirections to other domains. We are also regularly using s-flag S-NAPTRs in eduroam and RADIUS Dynamic Discovery to point to a delegate RADIUS server residing in a different domain. It's just normal operations. This limitation in RFC6733 is at best "funny" IMHO. > Therefore, my understanding is that the use of S-NAPTR is not suitable for > redirection when the target domain name is different from the original one. > And the current draft proposes to allow any kind of redirection without any > impact on existing DNS infra. I would rather take a very good look at the section in RFC6733 that discourages other domain names in the replacement. It's more like an erratum for me; and if that restriction were away you would have a working solution to your redirection problem with zero effort. And anyway, it's a SHOULD without considerations or consequences attached. Which makes it more of a DONTCARE anyway ;-) > But as I said, it is only based on my understanding and I'm not an expert on > DNS. I don't think DNS is the problem here. It's more that Diameter butchers its NAPTR usage unnecessarily. Greetings, Stefan Winter > > Regards, > > Lionel > > -----Message d'origine----- > De : dime-boun...@ietf.org [mailto:dime-boun...@ietf.org] De la part de > Stefan Winter > Envoyé : lundi 19 août 2013 10:16 > À : d...@ietf.org; 'IETF Discussion Mailing List' > Objet : Re: [Dime] Last Call: <draft-ietf-dime-realm-based-redirect-11.txt> > (Realm-Based Redirection In Diameter) to Proposed Standard > > Hello, > >> The IESG has received a request from the Diameter Maintenance and >> Extensions WG (dime) to consider the following document: >> - 'Realm-Based Redirection In Diameter' >> <draft-ietf-dime-realm-based-redirect-11.txt> as Proposed Standard > > Sorry for bringing this up so late, but as I was writing my own dynamic > discovery draft for RADIUS, it occured to me that the usage of S-NAPTR for > Diameter brings a built-in support to signal realm-based redirect > *if* S-NAPTR discovery is used. > > That only affects this document periphally; it describes realm-based redirect > for agent-based redirects, not for DNS-based; but still, the wording in > section 2 implies that using a realm-based-redirect-aware Diameter agent is > the only choice, and I think that should be rectified. > > The mechanism for S-NAPTR realm-based redirect is built into the S-NAPTR spec > by allowing for "non-terminal" lookups; this is signalled by having neither > an "s" flag (for SRV targets) nor an "a" flag (for A/AAAA targets); but > instead an "" (empty) flag. The replacement string in the NAPTR record is > then the label of /another/ NAPTR lookup; that lookup is then to be performed > with the same service/protocol tag. > > That makes the whole realm-based redirect problem very easy protocol-wise. > Consider a realm "foo.example" who wants to tell its Diameter peers that its > realm's application ID 123 is from now on served from "example.com". It puts > into DNS > > foo.example. 43200 IN NAPTR 100 10 "" "aaa+ap123:diameter.tls" "" > example.com > > A client who got this answer would then query for > > example.com NAPTR "aaa+ap123:diameter.tls" > > and would get example.com's servers via SRV or A/AAAA records as configured > by the admins of example.com. > > This is described in section 2.2.3 of RFC3958. > > Now for the wording in the draft: > > Sction 2: the first para needs a bit of a rewrite to factor in S-NAPTR's > capabilities. > > I suggest something along the lines of: > > "Realm-based redirection is implicitly a part of the Diameter base protocol, > but only where peer discovery using S-NAPTR is used (section > 5.2 of [RFC6733], by using the non-terminal S-NAPTR flag). This allows for > both application-specific realm-based redirects, and for application-agnostic > (unconditional) realm-based redirects, and does not require any Diameter > agents. > > For deployments which do not make use of S-NAPTR peer discovery, support of > realm-based redirection MUST be specified as part of functionality supported > by a Diameter application. (... continue with the rest of the section ...) > > Greetings, > > Stefan Winter > > > >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2013-08-27. Exceptionally, comments may >> be sent to i...@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >> >> Abstract >> >> >> Message redirection is a basic capability provided by the Diameter >> base protocol. In its conventional form, message redirection is >> performed by an application-independent "redirect agent", which >> returns one or more individual hosts to the message sender as >> possible destinations of the redirected message. >> >> However, in some circumstances an operator may wish to redirect >> messages to an alternate domain without specifying individual hosts. >> This document specifies an application-specific mechanism by which >> that can be achieved. New applications may incorporate this >> capability by reference to the present document. >> >> Because the redirection mechanism is application-specific, it must be >> performed by a Diameter server or proxy rather than a basic redirect >> agent as defined in the Diameter base protocol. A new term, "Realm- >> based Redirect Server", is introduced in this document to >> differentiate the application-specific nature of realm-based >> redirection from the conventional Diameter redirection performed by a >> basic redirect agent. >> >> This memo updates Sections 6.13 and 6.14 of RFC6733 with respect to >> the usage of the Redirect-Host-Usage and Redirect-Max-Cache-Time >> AVPs. >> >> >> >> >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-ietf-dime-realm-based-redirect/ >> >> IESG discussion can be tracked via >> http://datatracker.ietf.org/doc/draft-ietf-dime-realm-based-redirect/b >> allot/ >> >> >> The following IPR Declarations may be related to this I-D: >> >> http://datatracker.ietf.org/ipr/1254/ >> >> >> >> _______________________________________________ >> DiME mailing list >> d...@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > > > -- > 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 > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > -- 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
signature.asc
Description: OpenPGP digital signature
