< draft-jones-dime-extended-naptr-00.txt   draft-jones-dime-extended-naptr-01.txt >
Individual Submission M. Jones Individual Submission M. Jones
Internet-Draft Bridgewater Systems Internet-Draft Bridgewater Systems
Updates: 3588 (if approved) J. Korhonen Updates: 3588 (if approved) J. Korhonen
Intended status: Standards Track Nokia Siemens Networks Intended status: Standards Track Nokia Siemens Networks
Expires: February 24, 2010 August 23, 2009 Expires: June 12, 2010 December 9, 2009
Diameter Extended NAPTR Diameter Extended NAPTR
draft-jones-dime-extended-naptr-00 draft-jones-dime-extended-naptr-01
Abstract
This document describes an extended format for the NAPTR service
fields used in dynamic Diameter agent discovery. The extended format
allows NAPTR queries to contain Diameter Application-Id information.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 24, 2010. This Internet-Draft will expire on June 12, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document describes an extended format for the NAPTR service described in the BSD License.
fields used in dynamic Diameter agent discovery. The extended format
allows NAPTR queries contain Diameter Application-Id information.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", This document may contain material from IETF Documents or IETF
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this Contributions published or made publicly available before November
document are to be interpreted as described in [RFC2119]. 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Extended NAPTR Service Field . . . . . . . . . . . . . . . . . 4 3. Extended NAPTR Service Field . . . . . . . . . . . . . . . . . 4
4. Extended NAPTR-based Diameter Peer Discovery . . . . . . . . . 5 4. Extended NAPTR-based Diameter Peer Discovery . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. Normative References . . . . . . . . . . . . . . . . . . . . . 6 7. Normative References . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
The Diameter base protocol [RFC3588] specifies three mechanisms for The Diameter base protocol [RFC3588] specifies three mechanisms for
the Diameter peer discovery. One of these involves the Diameter the Diameter peer discovery. One of these involves the Diameter
implementation performing a NAPTR query [RFC3403] for a server in a implementation performing a NAPTR query [RFC3403] for a server in a
particular realm. These NAPTR records provide a mapping from a particular realm. These NAPTR records provide a mapping from a
domain, to the SRV record [RFC2782] for contacting a server with the domain, to the SRV record [RFC2782] for contacting a server with the
specific transport protocol in the NAPTR services field. specific transport protocol in the NAPTR services field.
skipping to change at page 5, line 39 skipping to change at page 5, line 39
Diameter Session Initiation Protocol (SIP) Application ('6'), Diameter Session Initiation Protocol (SIP) Application ('6'),
NASREQ Application ('1'), EAP Application ('5') and SCTP as the NASREQ Application ('1'), EAP Application ('5') and SCTP as the
transport protocol. The Diameter node also provides Relay transport protocol. The Diameter node also provides Relay
functionality ('4294967295'). functionality ('4294967295').
The maximum length of the NAPTR service field is 256 octets including The maximum length of the NAPTR service field is 256 octets including
one octet length field (see Section 4.1 of RFC 3403 and Section 3.3 one octet length field (see Section 4.1 of RFC 3403 and Section 3.3
of [RFC1035]). The DNS administrator of some domain SHOULD also of [RFC1035]). The DNS administrator of some domain SHOULD also
provision base RFC 3588 style NAPTR records in order to guarantee provision base RFC 3588 style NAPTR records in order to guarantee
backwards compatibility with legacy RFC 3588 compliant Diameter backwards compatibility with legacy RFC 3588 compliant Diameter
peers. peers. If the DNS administrator provisions both extended NAPTR
records as defined in this specification and legacy RFC 3588 NAPTR
records, then the extended NAPTR records MUST have higher priority
(e.g. lower order and/or preference values) than legacy NAPTR
records.
4. Extended NAPTR-based Diameter Peer Discovery 4. Extended NAPTR-based Diameter Peer Discovery
The basic Diameter Peer Discover principles are described in Section The basic Diameter Peer Discover principles are described in Section
5.2 of RFC 3588. This specification extends the step 3. Diameter 5.2 of [RFC3588]. This specification extends the NAPTR query
peer discovery mechanism by allowing the querying node examine which procedure in the Diameter peer discovery mechanism by allowing the
applications are supported by resolved Diameter peers. The querying node to determine which applications are supported by
assumption for this mechanism to work is that the DNS administrator resolved Diameter peers.
of the queried domain has provisioned the DNS with extended NAPTRs in
the first place. The text below is slightly modified from RFC 3588.
1. ... The extended format NAPTR records provide a mapping from a domain, to
the SRV record for contacting a server supporting a specific
transport protocol and Diameter application. The resource record
will contain an empty regular expression and a replacement value,
which is the SRV record for that particular transport protocol. If
the server supports multiple transport protocols, there will be
multiple NAPTR records, each with a different Services Field value
and potentially different list of supported Diameter applications.
2. ... The assumption for this mechanism to work is that the DNS
administrator of the queried domain has first provisioned the DNS
with extended format NAPTR entries. The steps below replace the
NAPTR query procedure steps in Section 5.2 of [RFC3588].
3. The Diameter implementation performs a NAPTR query for a server in a. The Diameter implementation performs a NAPTR query for a server in
a particular realm. The Diameter implementation has to know in a particular realm. The Diameter implementation has to know in
advance which realm to look for a Diameter agent in and which advance which realm to look for a Diameter agent in and which
Application Identifier it is interested in. The realm could be Application Identifier it is interested in. The realm could be
deduced, for example, from the 'realm' in a NAI that a Diameter deduced, for example, from the 'realm' in a NAI that a Diameter
implementation needed to perform a Diameter operation on. implementation needed to perform a Diameter operation on.
3.1 The services relevant for the task of transport protocol b. If the returned NAPTR service fields contain entries formatted as
selection are those with NAPTR service fields with values "AAA+ "AAA+D2X+AP:Y" where "X" indicates the transport protocol and "Y"
D2x+AP:y", where 'x' is a letter that corresponds to a is a comma-separated list of Application Identifiers, the target
transport protocol supported by the domain and 'y' is one or realm supports the extended format for NAPTR-based Diameter peer
more Application Identifiers. discovery defined in this document.
...
3.2 A client MUST discard any service fields that identify a If "X" matches a transport protocol supported by the client and
resolution service whose value is not "D2X", for values of X "Y" contains the required Application Identifier, the client
that indicate transport protocols supported by the client. The resolves the "replacement" field entry to a target host using
client SHOULD also discard any service fields that do not the lookup method appropriate for the "flags" field.
identify support for the application the client is looking for
i.e. the desired Application Identifier is not listed in If "X" does not match a transport protocol supported by the
'AP:y'. client or "Y" does not contain the required Application
... Identifier, the peer discovery is abandoned.
c. If the returned NAPTR service fields contain entries formatted as
"AAA+D2X" where "X" indicates the transport protocol, the target
realm supports the NAPTR-based Diameter peer discovery defined in
[RFC3588].
If "X" matches a transport protocol supported by the client,
the client resolves the "replacement" field entry to a target
host using the lookup method appropriate for the "flags" field.
If "X" does not match a transport protocol supported by the
client, the peer discovery is abandoned.
d. If the target realm does not support NAPTR-based Diameter peer
discovery, the client proceeds with the next peer discovery
mechanism described in Section 5.2 of [RFC3588].
5. IANA Considerations 5. IANA Considerations
Editor's Note: Verify impacts to IANA registries. Section 11.6 of [RFC3588] defines a IANA registry for the NAPTR
Services Field entries. Although this document does not define a new
transport protocol, it is proposed to add the following entries to
the existing registry to reflect the extended format of the NAPTR
Services Field:
Services Field Protocol
AAA+D2T+AP:x TCP
AAA+D2S+AP:x SCTP
Editor's Note: IANA is currently missing the registry for the NAPTR
Service Fields defined in [RFC3588]. This oversight will need to be
resolved for this document to proceed.
6. Security Considerations 6. Security Considerations
This document specifies an enhancement to the NAPTR service field This document specifies an enhancement to the NAPTR service field
format defined in the Diameter base protocol and the same security format defined in the Diameter base protocol and the same security
considerations described in RFC 3588 are applicable to this document. considerations described in RFC 3588 are applicable to this document.
No further extensions are required beyond the security mechanisms No further extensions are required beyond the security mechanisms
offered by RFC 3588. offered by RFC 3588. However, a malicious host doing NAPTR queries
learns applications supported by Diameter agents in a certain realm
faster, which might help the malicious host to scan potential targets
for an attack more efficiently when some applications have known
vulnerabilities.
7. Normative References 7. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
 End of changes. 16 change blocks. 
59 lines changed or deleted 108 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/