Subject: Re: [Dime] 3588bis Peer Discovery Questions

From: jouni korhonen <[email-masked]>
Date: Sun, 1 Apr 2012 22:12:54 +0300

Folks,

As per the discussion during the Dime WG meeting in Paris, the RFC3588bis
text in Section 5.2

   on existing IETF standards.  The first option (manual configuration)
   MUST be supported by all Diameter nodes, while the latter option
   (DNS) MAY be supported.

will be clarified so that the DNS-based discovery is MUST to implement
and MAY be supported. A note about this will also be added to RFC3588bis
Section 1.1.3.  "Changes from RFC3588".

- Jouni & Lionel

On Mar 12, 2012, at 10:20 PM, Ben Campbell wrote:

> 
> On Mar 12, 2012, at 2:50 PM, jouni korhonen wrote:
> 
>> Ben,
>> 
>> Normal "Dime lag" added to the response ;) See inline.
> 
> Thanks, also see inline:
> 
>> 
>> On Feb 4, 2012, at 12:36 AM, Ben Campbell wrote:
>> 
>>> Hi All,
>>> 
>>> I'm digesting the Peer Discovery section of 3588bis-29 (Section 5.2), and have some questions. I apologize in advance if these have been covered in past discussion.
>>> 
>>> 1) paragraph 1 says that "… the later option (DNS) MAY be supported:
>>> 
>>> Does that mean supported "by the software implementation", or supported "by the network deployment"? That is, is the intent to say that DNS based peer discovery MAY be implemented, vs MAY be used?
>> 
>> This is currently under a debate.. as you probably have seen.
> 
> Yes, thanks.  Put me in the "prefer MUST implement" camp. I've seen too many situations where management is harder than it needs to be because people are pre-provisioning every possible peer, often by IP address. While you can't make them stop doing that if they _want_ to, it would be nice if vendors gave them the option to not.
> 
>> 
>>> 2) Paragraph 2 talks about peer discovery by a client to find a next hop agent, or an agent to find another (next hop) agent. Is peer discovery limited to finding Diameter Agents? That is, can a Diameter client discover a Diameter server? (Perhaps the word "node" was intended rather than "agent"?)
>> 
>> It entirely depends what the domain owner populates into its DNS. If he/she puts there RRs for a relay, then the DNS-based discovery discovers it. If he/she puts there RRs for a server, then server gets discovered. There is no strict rule about that.
> 
> That's what I hoped the answer was--but the text is confusing on that point.
> 
> 
>> 
>>> 3) The 4th paragraph from the end says that, when using a site certificate, _both_ the domain name in the initial query and the name in the replacement field must match the site certificate. Is that just the for initial query and the final result, or does it cover any intermediate steps? (e.g. if your query flow is NAPTR-->SRV-->AAAA, does the SRV step also need to match?) Is there an expectation that the client will actually validate against both the queried name and the resulting name, or is the point merely that the cert should include them because different clients may start their initial query at different places in the DDDS sequence?
>> 
>> As far as I understand it, all domain names used for the query: the one for querying NAPTR, possible A/AAAA replacement from NAPTR, or replacement to query a SRV and finally the A/AAAAs in the SRV; must be in the cert. The client can check any of those.. it does not need to check whole chain but it probably should. The reason is stated in the same paragraph:
>> 
>>  MUST both be valid based on the same site certificate.  Otherwise, an
>>  attacker could modify the DNS records to contain replacement values
>>  in a different domain, and the client could not validate that this
>>  was the desired behavior, or the result of an attack.
> 
> It's not clear to me what the attack is where a cert that contains the initial name but not the derived names but not where the cert also contains all the derived names. Unless I'm reading it wrong, the security considerations for DDDS (RFC3958) only require the server to supply a certificate that matches the _original_ name.
> 
>> 
>> - Jouni
>> 
>> 
>>> 
>>> Thanks!
>>> 
>>> Ben.
>>> _______________________________________________
>>> DiME mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/dime
>> 
>

---

From: Ben Campbell <[email-masked]>
Date: Sun, 1 Apr 2012 20:14:50 -0500

Hi Jouni,

I concur in principle, but have one comment inline:

> Section 1.1.3.  "Changes from RFC3588".

I think the term "supported" was part of the original confusion, as it's not clear whether that means "implemented" or "used". I think the takeaway from the discussion in Paris is that DNS-based discovery "MUST be implemented and MAY be _used_", or something to that effect.

Thanks!

Ben.

---

From: jouni korhonen <[email-masked]>
Date: Mon, 2 Apr 2012 09:34:46 +0300

Ben,

> I think the term "supported" was part of the original confusion, as it's not clear whether that means "implemented" or "used". I think the takeaway from the discussion in Paris is that DNS-based di…

Sorry for my badly placed words. "MAY be used" is exactly what I had in
mind. Sometimes the lines from the head muscle to fingers are long and
experience some corruption of information ;)

- Jouni

---

From: Glen Zorn <[email-masked]>
Date: Tue, 3 Apr 2012 10:10:33 +0700

On Apr 2, 2012 8:14 AM, "Ben Campbell" <[email-masked]> wrote:
> I think the term "supported" was part of the original confusion, as it's
not clear whether that means "implemented" or "used". I think the takeaway
from the discussion in Paris is that DNS-based discovery "MUST be
implemented and MAY be _used_", or something to that effect.

I really don't think that it's any of our business _what_ people use, only
what is implemented, so I would just leave out anything about that.

> >>>> I'm digesting the Peer Discovery section of 3588bis-29 (Section
5.2), and have some questions. I apologize in advance if these have been
covered in past discussion.
> >>>> Does that mean supported "by the software implementation", or
supported "by the network deployment"? That is, is the intent to say that
DNS based peer discovery MAY be implemented, vs MAY be used?
> >> Yes, thanks.  Put me in the "prefer MUST implement" camp. I've seen
too many situations where management is harder than it needs to be because
people are pre-provisioning every possible peer, often by IP address. While
you can't make them stop doing that if they _want_ to, it would be nice if
vendors gave them the option to not.
> >>
> >>>
> >>>> 2) Paragraph 2 talks about peer discovery by a client to find a next
hop agent, or an agent to find another (next hop) agent. Is peer discovery
limited to finding Diameter Agents? That is, can a Diameter client discover
a Diameter server? (Perhaps the word "node" was intended rather than
"agent"?)
> >>>
> >>> It entirely depends what the domain owner populates into its DNS. If
he/she puts there RRs for a relay, then the DNS-based discovery discovers
it. If he/she puts there RRs for a server, then server gets discovered.
There is no strict rule about that.
> >>>> 3) The 4th paragraph from the end says that, when using a site
certificate, _both_ the domain name in the initial query and the name in
the replacement field must match the site certificate. Is that just the for
initial query and the final result, or does it cover any intermediate
steps? (e.g. if your query flow is NAPTR-->SRV-->AAAA, does the SRV step
also need to match?) Is there an expectation that the client will actually
validate against both the queried name and the resulting name, or is the
point merely that the cert should include them because different clients
may start their initial query at different places in the DDDS sequence?
> >>>
> >>> As far as I understand it, all domain names used for the query: the
one for querying NAPTR, possible A/AAAA replacement from NAPTR, or
replacement to query a SRV and finally the A/AAAAs in the SRV; must be in
the cert. The client can check any of those.. it does not need to check
whole chain but it probably should. The reason is stated in the same
paragraph:
> >> It's not clear to me what the attack is where a cert that contains the
initial name but not the derived names but not where the cert also contains
all the derived names. Unless I'm reading it wrong, the security
considerations for DDDS (RFC3958) only require the server to supply a
certificate that matches the _original_ name.

---

From: Adam Roach <[email-masked]>
Date: Mon, 2 Apr 2012 22:45:21 -0500

On Apr 2, 2012, at 22:10, Glen Zorn <[email-masked]> wrote:

> I really don't think that it's any of our business _what_ people use, only what is implemented, so I would just leave out anything about that.

Given that "MAY" is non-constraining, I don't see the harm in including a statement to the effect that the mechanism "MAY be used". In fact, I think it clarifies that the implementation would be well served by allowing the mechanism to be turned off. Without the phrase, you're likely to find implementors who interpret the statement to mean that the mechanism is mandatory all the time, and will provide no means to configure it to be off. 

/a

---

From: <[email-masked]>
Date: Tue, 3 Apr 2012 09:24:36 +0200

I think that this reflects the conclusion of our discussion during the dime session.
So, even if not deemed required, the statement "MUST_be_implemented, MAY_be_used" is correct and removes some ambiguity of the current text in RFC 3588.

Lionel

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Adam Roach
Envoyé : mardi 3 avril 2012 05:45
À : Glen Zorn
Cc : [email-masked]
Objet : Re: [Dime] 3588bis Peer Discovery Questions

/a

---

From: Glen Zorn <[email-masked]>
Date: Thu, 19 Apr 2012 21:54:54 +0700

> So, even if not deemed required, the statement "MUST_be_implemented, MAY_be_used" is correct and removes some ambiguity of the current text in RFC 3588.

Isn't that statement true for both mechanisms?  I think so, and suggest 
the following change:

OLD:
5.2.  Diameter Peer Discovery

    Allowing for dynamic Diameter agent discovery will make it possible
    for simpler and more robust deployment of Diameter services.  In
    order to promote interoperable implementations of Diameter peer
    discovery, the following mechanisms are described.  These are based
    on existing IETF standards.  The first option (manual configuration)
    MUST be supported by all Diameter nodes, while the latter option
    (DNS) MAY be supported.

NEW:
5.2.  Diameter Peer Discovery

    Allowing for dynamic Diameter agent discovery makes possible simpler
    and more robust deployment of Diameter services.  In order to promote
    interoperable implementations of Diameter peer discovery, the
    following mechanisms (manual configuration and DNS) are described.
    These are based on existing IETF standards.  Both mechanisms MUST be
    supported by all Diameter implementations; either MAY be used.

> On Apr 2, 2012, at 22:10, Glen Zorn<[email-masked]>  wrote:
>

---

From: Adam Roach <[email-masked]>
Date: Thu, 19 Apr 2012 10:33:11 -0500

>   supported by all Diameter implementations; either MAY be used.

That sounds good to me, and I think it reflects the consensus I've seen so far.

/a