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

From: jouni korhonen <[email-masked]>
Date: Mon, 12 Mar 2012 21:50:57 +0200

Ben,

Normal "Dime lag" added to the response ;) 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.

> 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:

   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.

- Jouni

> 
> Thanks!
> 
> Ben.
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: Ben Campbell <[email-masked]>
Date: Mon, 12 Mar 2012 15:20:08 -0500

> 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.

> 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…

That's what I hoped the answer was--but the text is confusing on that point.

>   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.