DNSOP Working Group J. Woodworth Internet-Draft D. Ballew Updates: 2308, 4033, 4034, 4035 (if CenturyLink, Inc. approved) S. Bindinganaveli Raghavan Intended status: Standards Track Hughes Network Systems Expires: January 22, 2020 D. Lawrence Oracle July 21, 2019 Numeric Pattern Normalization (NPN) draft-woodworth-npn-00 Abstract The Numeric Pattern Normalization (NPN) resource record provides pre- processing information to reduce the number of possible variants which can be generated by pattern-based RR's into a single signable record. Ed note Text inside square brackets ([]) is additional background information, answers to frequently asked questions, general musings, etc. They will be removed before publication. This document is being collaborated on in GitHub at . The most recent version of the document, open issues, etc should all be available here. The authors gratefully accept pull requests. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 22, 2020. Woodworth, et al. Expires January 22, 2020 [Page 1] Internet-Draft NPN July 2019 Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Background and Terminology . . . . . . . . . . . . . . . 3 2. The NPN Resource Record . . . . . . . . . . . . . . . . . . . 3 2.1. NPN RDATA Wire Format . . . . . . . . . . . . . . . . . . 3 2.2. The NPN RR Presentation Format . . . . . . . . . . . . . 5 2.3. Use and Normalization Processing of NPN RRs . . . . . . . 5 2.3.1. Pseudocode for NPN Normalization Processing . . . . . 6 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 3.1. Normalized (NPN-Based) Signatures . . . . . . . . . . . . 7 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . 9 Appendix A. NPN Examples . . . . . . . . . . . . . . . . . . . . 9 A.1. EXAMPLE 1 . . . . . . . . . . . . . . . . . . . . . . . . 9 A.2. EXAMPLE 2 . . . . . . . . . . . . . . . . . . . . . . . . 10 A.3. EXAMPLE 3 . . . . . . . . . . . . . . . . . . . . . . . . 11 A.4. EXAMPLE 4 . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction The Numeric Pattern Normalization (NPN) resource record provides methods to generate DNSSEC signatures for pattern-based "synthesized" RR's, and validation of such signatures. It does this by introducing a pre-processing step of pattern substitution into both the signing and validating processes. Woodworth, et al. Expires January 22, 2020 [Page 2] Internet-Draft NPN July 2019 1.1. Background and Terminology The reader is assumed to be familiar with the basic DNS and DNSSEC concepts described in [RFC1034], [RFC1035], [RFC4033], [RFC4034], and [RFC4035]; subsequent RFCs that update them in [RFC2181] and [RFC2308]; and DNS terms in [RFC7719]. 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]. 2. The NPN Resource Record The Numeric Pattern Normalization (NPN) resource record provides pre- processing information to reduce the number of possible variants that can be generated by a pattern-based RR into one signable record. By identifying parts of the dynamic resource record which should be ignored or represented as a static value, one exemplar record and signature is used to validate all other records that match the pattern. For example, a pattern replacement like pool-A-${1}-${2}.example.com that generates PTR records for pool-A-0-0.example.com through pool- A-255-255.example.com would have an NPN record that signals a validating resolver to verify all pool-A-#-#.example.com names against a record for pool-A-9-9.example.com. Though it is conceivable that forged records could be validated as legitimate, such forged records must meet strict criteria and match patterns which define and are considered legitimate. The added measure is a notable improvement in security over being hosted in insecure zones. The Type value for the NPN RR type is TBD. The NPN RR is class independent and has no special TTL requirements. 2.1. NPN RDATA Wire Format The RDATA for an NPN RR consists of a 2 octet Match Type field, a 1 octet Flags field, a 1 octet Owner Ignore field, a 1 octet Left Ignore field and a 1 octet Right Ignore field. Woodworth, et al. Expires January 22, 2020 [Page 3] Internet-Draft NPN July 2019 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Match Type | Flags | Owner Ignore | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Left Ignore | Right Ignore | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Match Type indicates the type of the RRset with which this record is associated. Flags defines additional processing parameters for data normalization. This document defines only the Period-As-Number flag "." (position 5), the Hyphen-As-Number "-" (position 6) and the hexadecimal flag "X" (position 7). All other flags are reserved for future use. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |Reserved |.|-|X| +-+-+-+-+-+-+-+-+ Bits 0-4: Reserved for future Bit 5: Period As Number (.) Flag If 0, periods are treated as non-digits. If 1, periods will be processed as digits. Bit 6: Hyphen As Number (-) Flag If 0, hyphens are treated as non-digits. If 1, hyphens will be processed as digits. Bit 7: Hexadecimal (X) Flag If 0, numeric digits include only 0-9. If 1, numeric digits include a-f in addition to 0-9. Owner Ignore defines the number of octets in the owner name, as counted from the left, which MUST be ignored by the normalization process. This field offers additional security to pattern based signatures which may not be immediately apparent. By restricting the leftmost characters defined by this value, ultimately the length of the generated portion of the accompanying synthesized RR will be confined accordingly. Left Ignore defines the number of octets of the generated RDATA, as counted from the left, which MUST be ignored by the normalization process. Woodworth, et al. Expires January 22, 2020 [Page 4] Internet-Draft NPN July 2019 Right Ignore defines the number of octets of the generated RDATA, as counted from the right, which MUST be ignored by the normalization process. 2.2. The NPN RR Presentation Format Match Type is represented as an RR type mnemonic or with [RFC3597]'s generic TYPE mechanism. Flags is a string of characters indicating the status of each bit as per the following table. The characters can appear in any order. +------------------+-----------+-----------+ | Flag | Unset | Set | +------------------+-----------+-----------+ | Period As Number | | . | +------------------+-----------+-----------+ | Hyphen As Number | | - | +------------------+-----------+-----------+ | Hexadecimal | 9 | f | +------------------+-----------+-----------+ Owner Ignore, Left Ignore, and Right Ignore are displayed as unsigned decimal integers, ranging from 0 through 255. 2.3. Use and Normalization Processing of NPN RRs This document provides a minor yet significant modification to DNSSEC regarding how RRsets will be signed or verified. Specifically the Signature Field of [RFC4034], Section 3.1.8. Prior to processing into canonical form, signed zones may contain associated RRs where; owner, class and type of a non NPN RR directly corresponds with an NPN RR matching owner, class and Match Type. If this condition exists the NPN RR's RDATA defines details for processing the associated RDATA into a "Normalized" format. Normalized data is based on pre-canonical formatting and zero padded for "A" and "AAAA" RR types for acceptable precision during the process. This concept will become clearer in the NPN pseudocode and examples provided in the sections to follow. The rules for this transformation are simple: o For RR's Owner field, characters from the beginning to the index of the Owner Ignore value or the final string of characters belonging to the zone's ORIGIN MUST NOT be modified by this algorithm. This value is intended to provide additional limitations on the query portion further minimizing the risk of spoofed RR's matching NPN-based signatures. Woodworth, et al. Expires January 22, 2020 [Page 5] Internet-Draft NPN July 2019 o For RR's RDATA field, character from beginning to the index of Left Ignore value or characters with index of Right Ignore value to the end MUST NOT be modified by this algorithm. o In the remaining portion of both Owner and RDATA strings of numeric data, defined as character "0" through "f" or "0" through "9" depending on whether or not the Hexadecimal flag is set or not, MUST be consolidated to a single character and set to the highest value defined by the Hexadecimal flag. Examples may be found in the following section. If period-as-number or hyphen-as- number flags are set whichever are used ("." or "-") would be treated as part of the number and consolidated where appropriate. Once the normalization has been performed the signature will continue processing into canonical form using the normalized RRs in the place of original ones. If multiple NPN RR's resolve to the same owner and type, it MUST be assumed either multiple overlapping pattern-based generation RR's coexist for the same owner. In this scenario, the validation algorithm SHOULD be attempted against all NPN RR's until a successful validation is found or no NPN's for this owner and type remain. While multiple overlapping pattern-based generation SHOULD be discouraged, future pattern-based RR's may necessitate this condition so it must be accounted for. NPN RRs MAY be included in the "Additional" section to provide a hint of the NPN processing required for the verification path. It is important to note, properly sizing the Ignore fields is critical to minimizing the risk of spoofed signatures. Never intentionally set all Ignore values to zero in order to make validation easier as it places the validity of zone data at risk. Only accompany RRs which are pattern derived (such as BULK) with NPN records as doing so may unnecessarily reduce the confidence level of generated signatures. 2.3.1. Pseudocode for NPN Normalization Processing This section provides a simple demonstration of process flow for NPN rdata normalization and DNSSEC signatures. The pseudocode provided below assumes all associated RRs are valid members of a DNSSEC-compatible RRset, including pattern-generated ones. Woodworth, et al. Expires January 22, 2020 [Page 6] Internet-Draft NPN July 2019 for rr in rrset if (has_NPN) rr.rdata_normal = NPN_normalize add_to_sigrrset next else add_to_sigrrset next process_canonical_form dnssec_sign Similar logic MUST be used for determining DNSSEC validity of RRsets in validating nameservers for signatures generated based on NPN normalization. 3. Security Considerations The NPN RR is intended to be used only with the offline-signing of pattern-based RR's where there is an expected minimal security impact. Use of NPN RR's for other purposes is strongly discouraged and falls outside the scope of this document. 3.1. Normalized (NPN-Based) Signatures This solution provides a flexible solution as nameservers without on- the-fly signing capabilities can still support signatures for pattern-based records. The down side to this solution is it requires NPN resolver support for validation. It has been pointed out that due to this limitation, creation of DNSSEC-signed pattern-based RRs requiring NPN support SHOULD be formally discouraged until such time a respectable percentage (>80%) of validating resolvers in-the-wild possess NPN processing capabilities. Until that time, on-the-fly signing and unsigned records offer the intended capabilities for pattern-based RR's, while requiring zero new features to support their resolution. Given enough time, enough nameservers will be patched and upgraded for unrelated reasons and by means of simple attrition can supply a level of inertia and eventually widespread adoption can be assumed. 4. Privacy Considerations NPN records do not introduce any new privacy concerns to DNS data. Woodworth, et al. Expires January 22, 2020 [Page 7] Internet-Draft NPN July 2019 5. IANA Considerations IANA is requested to assign numbers for the NPN DNS resource record type identified in this document. 6. Acknowledgments This document was created as an extension to the DNS infrastructure. As such, many people over the years have contributed to its creation and the authors are appreciative to each of them even if not thanked or identified individually. A special thanks is extended for the kindness, wisdom and technical advice of Robert Whelton (CenturyLink, Inc.) and Gary O'Brien (Secure64). 7. References 7.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, . [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, . [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN- ADDR.ARPA delegation", BCP 20, RFC 2317, DOI 10.17487/RFC2317, March 1998, . Woodworth, et al. Expires January 22, 2020 [Page 8] Internet-Draft NPN July 2019 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 2003, . [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, . [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, . [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, . 7.2. Informative References [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", RFC 7719, DOI 10.17487/RFC7719, December 2015, . Appendix A. NPN Examples A.1. EXAMPLE 1 2.10.in-addr.arpa. 86400 IN BULK PTR ( [0-255].[0-10].2.10.in-addr.arpa. pool-A-${1}-${2}.example.com. ) 2.10.in-addr.arpa. 86400 IN NPN PTR 9 0 7 13 For the BULK RR used in this example, a query for the PTR of address 10.2.3.44 would match the for the query name 44.3.2.10.in-addr.arpa, resulting in the generation of a PTR to pool-A-3-44.example.com as the response. By protecting the "Ignore" characters from the generated RR's RDATA the focus for normalization becomes "3-44" as illustrated below. Woodworth, et al. Expires January 22, 2020 [Page 9] Internet-Draft NPN July 2019 0 1 2 3 4 5 6 7 v--------- p o o l - A - 3 - 4 4 . e x a m p l e . c o m . ---------^ 1 1 1 1 3 2 1 0 9 8 7 6 5 4 3 2 1 0 Everything to the left of "3-44" will remain intact, as will everything to its right. The remaining characters will be processed for digits between 0 and 9 as indicated by the NPN record's hexadecimal flag 9, and each run of digits replaced by the single character "9". The final Normalized RDATA for *.2.10.in-addr.arpa would therefore become pool-A-9-9.example.com., and its signature would be based on this value to cover all possible permutations of the pool-A-${1}-${2}.example.com replacement pattern. Since the validating nameserver would use the identical NPN record for processing and comparison, all RRs generated by the BULK record can now be verified with a single signature. A.2. EXAMPLE 2 This example contains a classless IPv4 delegation on the /22 CIDR boundary as defined by [RFC2317]. The network for this example is "10.2.0/22" delegated to a nameserver "ns1.sub.example.com.". RRs for this example are defined as: $ORIGIN 2.10.in-addr.arpa. 0-3 86400 IN NS ns1.sub.example.com. 86400 IN BULK CNAME [0-255].[0-3] ${*|.}.0-3 86400 IN NPN CNAME 9 0 0 23 For this example, a query of "10.2.2.65" would enter the nameserver as "65.2.2.10.in-addr.arpa." and a "CNAME" RR with the RDATA of "65.2.0-3.2.10.in-addr.arpa." would be generated. By protecting the "Ignore" characters from the generated RR's RDATA the focus for normalization becomes "65.2" as illustrated below. 0 v--------- 6 5 . 2 . 0 - 3 . 2 . 1 0 . i n - a d d r . a r p a . ---------^ 2 2 2 2 1 1 1 1 1 1 1 1 1 1 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 Everything to the left of "65.2" will remain intact as will everything to its right. The remaining characters will be processed Woodworth, et al. Expires January 22, 2020 [Page 10] Internet-Draft NPN July 2019 for digits from 0 through 9 as indicated by the NPN record's hexadecimal flag "9", with each run replaced by the single character "9". The final normalized RDATA would therefore become 9.9.0- 3.2.10.in-addr.arpa and its signature would be based on this normalized RDATA field. This new normalized string would be used as an RDATA for the wildcard label of 2.10.in-addr.arpa now encompassing all possible permutations of the ${*|.}.0-3.2.10.in-addr.arpa. pattern. As in example 1, the validatating resolver would use the same NPN record for comparison. A.3. EXAMPLE 3 This example provides reverse logic for example 1 by providing an IPv4 address record for a requested hostname. For this example the query is defined as an A record for pool-A-3-44.example.com, with an origin of example.com. RRs for this example are defined as: example.com. 86400 IN BULK A ( pool-A-[0-10]-[0-255] 10.2.${*} ) example.com. 86400 IN NPN A 9 0 8 0 By protecting the "Ignore" characters from the generated RR's RDATA the focus for normalization becomes "003.044" as illustrated below. 0 1 2 3 4 5 6 7 8 v-------------- 0 1 0 . 0 0 2 . 0 0 3 . 0 4 4 ---------------^ 0 This example illustrates a key point about NPN records; since they are pre-canonical they MUST operate on a strict subset of WIRE formatted data. For A and AAAA records this means the "Ignore" fields are based on zero padded data. In this example our generated record MUST be converted into "010.002.003.044" (shown above) prior to processing. After processing, wire format would become "0x0A02032C" (shown in hexadecimal). This format would be too imprecise for normalization so padded decimal is used. Everything to the left of "003.044" will remain intact as will everything to its right. The remaining characters will be processed for digits between 0 and 9 as indicated by the NPN record's hexadecimal flag "9" and each run replaced by the single character "9". The final Normalized RDATA would therefore become 10.2.9.9 and Woodworth, et al. Expires January 22, 2020 [Page 11] Internet-Draft NPN July 2019 its signature would be based on this normalized RDATA field. This new normalized A RR would be used as an RDATA for the wildcard label of "*.example.com." now encompassing all possible permutations of the 10.2.${*} pattern. A.4. EXAMPLE 4 This example provides similar logic for an IPv6 AAAA record. For this example the query is defined as an AAAA record for pool-A-ff- aa.example.com with an origin of example.com.. RRs for this example are defined as: example.com. 86400 IN BULK AAAA ( pool-A-[0-ffff]-[0-ffff] fc00::${1}:${2} ) example.com. 86400 IN NPN AAAA X 0 30 0 By protecting the "Ignore" characters from the generated RR's RDATA the focus for normalization becomes "00ff:00aa" as illustrated below. 1 1 1 1 1 1 1 1 1 1 2 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 f c 0 0 : 0 0 0 0 : 0 0 0 0 : 0 0 0 0 : -/-/ 4 3 3 3 3 3 3 3 3 3 3 2 2 2 2 2 2 2 2 2 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 /-/-/- . . . . . . . . . . . . . . . . . . . . . . . . -/-/-/ 2 2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 3 3 3 4 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 v------------------ /-/- 0 0 0 0 : 0 0 0 0 : 0 0 f f : 0 0 a a -------------------^ 2 1 1 1 1 1 1 1 1 1 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 This example reinforces the point on pre-canonical processing of NPN records; they MUST operate on a strict subset of WIRE formatted data. For A and AAAA records this means the "Ignore" fields are based on zero padded data. In this example our generated record MUST be converted into "fc00:0000:0000:0000:0000:0000:00ff:00aa" (shown above) prior to processing. After processing, wire format would become "0xFC000000000000000000000000FF00AA" (shown in hexadecimal). This format is slightly misleading as it is truly only 16 bytes of WIRE data and would be too imprecise for normalization so padded hexadecimal is used. Woodworth, et al. Expires January 22, 2020 [Page 12] Internet-Draft NPN July 2019 Everything to the left of "00ff:00aa" will remain intact as will everything to its right. The remaining characters will be processed for numbers between "0" and "f" as indicated by the NPN record's hexadecimal flag "X" and each run replaced by the single character "f". The final Normalized RDATA would therefore become "fc00::f:f" and its signature would be based on this "normalized" RDATA field. This new "normalized" "AAAA" RR would be used as an RDATA for the wildcard label of *.example.com now encompassing all possible permutations of the "fc00::${1}:${2}" pattern. Authors' Addresses John Woodworth CenturyLink, Inc. 4250 N Fairfax Dr Arlington VA 22203 USA Email: John.Woodworth@CenturyLink.com Dean Ballew CenturyLink, Inc. 2355 Dulles Corner Blvd, Ste 200 300 Herndon VA 20171 USA Email: Dean.Ballew@CenturyLink.com Shashwath Bindinganaveli Raghavan Hughes Network Systems 11717 Exploration Lane Germantown MD 20876 USA Email: shashwath.bindinganaveliraghavan@hughes.com David C Lawrence Oracle Email: tale@dd.org Woodworth, et al. Expires January 22, 2020 [Page 13]