Re: [Dime] Last Call: <draft-ietf-dime-realm-based-redirect-11.txt> (Realm-Based Redirection In Diameter) to Proposed Standard

[<[e-mail]>]

Works for me.

Regards,

Lionel

-----Message d'origine-----
De : Stefan Winter [mailto:[e-mail]] 
Envoyé : mardi 20 août 2013 13:37
À : MORAND Lionel OLNC/OLN
Cc : [e-mail]; '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,

> 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:[e-mail]] Envoyé : mardi 20 
> août 2013 08:37 À : MORAND Lionel OLNC/OLN Cc : [e-mail]; '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 : [e-mail] [mailto:[e-mail]] De la part 
>> de Stefan Winter Envoyé : lundi 19 août 2013 10:16 À : [e-mail]; 
>> '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 [e-mail] mailing lists by 2013-08-27. 
>>> Exceptionally, comments may be sent to [e-mail] 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
>>> [e-mail]
>>> 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: [phone]
>> Fax: [phone]
>>
>>
>> _____________________________________________________________________
>> _ ___________________________________________________
>>
>> 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: [phone]
> Fax: [phone]
> 
> 
> ______________________________________________________________________
> ___________________________________________________
> 
> 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: [phone]
Fax: [phone]


_________________________________________________________________________________________________________________________

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.