Hi, > Thank you for quick feedback. > I agree with your analysis. I think that we should provide more info on the > possible use of S-NAPTR for realm-based redirection. > Taking into account your proposal, what do you think of the following > proposed changes:
The new text reads pretty well. One thing worth considering is maybe: this draft already updates RFC6733. It may be worth making explicit that the RFC6733 SHOULD regarding same-domain targets is being made obsolete in by this draft. One more sentence in the section 2 text below should do the trick: > NEW: > > Using the S-NAPTR DDDS application [RFC3958], the DNS-based dynamic peer > discovery mechanism defined in the Diameter base protocol [RFC6733] > provides a simple mechanism for realm-based redirection. When S-NAPTR is > used for peer discovery, redirection of Diameter request from the original > realm to a new realm may be performed by updating the existing NAPTR > resource > records for the original realm as follow: the NAPTR RR for the desired > application(s) and supported application protocol(s) provided by the > new realm will have an empty FLAG field and the REPLACEMENT field will > contain the new realm to use for the next DNS lookup. ADD: The new realm can be arbitrary; the restriction in RFC6733 that the NAPTR replacement field SHOULD match the domain of the original query does not apply for realm-based redirect purposes. All the rest of the text is fine. Greetings, Stefan Winter > > However, the use of DNS-based dynamic peer discovery is optional for > Diameter > implementations. 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. In this way, support > of the > considered Diameter application (discovered during capabilities exchange > procedures as defined in Diameter base protocol [RFC6733]) indicates > implicit support of the realm-based redirection mechanism. Designers of > new applications can incorporate the mechanism specified here into their > application by normative reference to this document. > > The result of making realm-based redirection an application-specific > behaviour is that it cannot be performed by a redirect agent as > defined in [RFC6733], but MUST be performed instead by an > application-aware Diameter node (Diameter server or proxy) (hereafter > called a "Realm-based Redirect Server"). > > An application can specify that realm-based redirection operates only > on complete sessions beginning with the initial message, or on every > message within the application, even if earlier messages of the same > session were not redirected. This distinction matters only when > realm-based redirection is first initiated. In the former case, > existing sessions will not be disrupted by the deployment of realm- > based redirection. In the latter case, existing sessions will be > disrupted if they are stateful. > > Regards, > > Lionel > > -----Message d'origine----- > De : Stefan Winter [mailto:stefan.win...@restena.lu] > Envoyé : mardi 20 août 2013 08:37 > À : MORAND Lionel OLNC/OLN > Cc : 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 > > 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 > > > _________________________________________________________________________________________________________________________ > > 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
