Relayed Echo Reply mechanism for LSP Ping
draft-ietf-mpls-lsp-ping-relay-reply-06

Internet Engineering Task Force                                 S. Huque
Internet-Draft                                                   P. Aras
Intended status: Informational                                Salesforce
Expires: October 21, 2020                                   J. Dickinson
                                                                 Sinodun
                                                               J. Vcelak
                                                                     NS1
                                                               D. Blacka
                                                                Verisign
                                                          April 19, 2020

                       Multi Signer DNSSEC models
               draft-ietf-dnsop-multi-provider-dnssec-05

Abstract

   Many enterprises today employ the service of multiple DNS providers
   to distribute their authoritative DNS service.  Deploying DNSSEC in
   such an environment may present some challenges depending on the
   configuration and feature set in use.  In particular, when each DNS
   provider independently signs zone data with their own keys,
   additional key management mechanisms are necessary.  This document
   presents deployment models that accommodate this scenario and
   describe these key management requirements.  These models do not
   require any changes to the behavior of validating resolvers, nor do
   they impose the new key management requirements on authoritative
   servers not involved in multi signer configurations.

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 October 21, 2020.

Huque, et al.           Expires October 21, 2020                [Page 1]
Internet-Draft         Multi Signer DNSSEC models             April 2020

Copyright Notice

   Copyright (c) 2020 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 and Motivation . . . . . . . . . . . . . . . . .   2
   2.  Deployment Models . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Multiple Signer models  . . . . . . . . . . . . . . . . .   3
       2.1.1.  Model 1: Common KSK set, Unique ZSK set per provider    4
       2.1.2.  Model 2: Unique KSK set and ZSK set per provider  . .   5
   3.  Validating Resolver Behavior  . . . . . . . . . . . . . . . .   5
   4.  Signing Algorithm Considerations  . . . . . . . . . . . . . .   6
   5.  Authenticated Denial Considerations . . . . . . . . . . . . .   6
     5.1.  Single Method . . . . . . . . . . . . . . . . . . . . . .   7
     5.2.  Mixing Methods  . . . . . . . . . . . . . . . . . . . . .   7
   6.  Key Rollover Considerations . . . . . . . . . . . . . . . . .   8
     6.1.  Model 1: Common KSK, Unique ZSK per provider  . . . . . .   8
     6.2.  Model 2: Unique KSK and ZSK per provider  . . . . . . . .   9
   7.  Using Combined Signing Keys . . . . . . . . . . . . . . . . .  10
   8.  Use of CDS and CDNSKEY  . . . . . . . . . . . . . . . . . . .  10
   9.  Key Management Mechanism Requirements . . . . . . . . . . . .  10
   10. DNS Response Size Considerations  . . . . . . . . . . . . . .  11
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  11
   13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  12
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     14.1.  Normative References . . . . . . . . . . . . . . . . . .  12
     14.2.  Informative References . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction and Motivation

   RFC EDITOR: PLEASE REMOVE THIS PARAGRAPH BEFORE PUBLISHING: The
   source for this draft is maintained in GitHub at:
   https://github.com/shuque/multi-provider-dnssec

Huque, et al.           Expires October 21, 2020                [Page 2]
Internet-Draft         Multi Signer DNSSEC models             April 2020

   Many enterprises today employ the service of multiple Domain Name
   System (DNS) [RFC1034] [RFC1035] providers to distribute their
   authoritative DNS service.  This is primarily done for redundancy and
   availability, and allows the DNS service to survive a complete,
   catastrophic failure of any single provider.  Additionally,
   enterprises or providers occasionally have requirements that preclude
   standard zone transfer techniques [RFC1995] [RFC5936] : either non-
   standardized DNS features are in use that are incompatible with zone
   transfer, or operationally a provider must be able to (re)sign DNS
   records using their own keys.  This document outlines some possible
   models of DNSSEC [RFC4033] [RFC4034] [RFC4035] deployment in such an
   environment.

   This document assumes a reasonable level of familiarity with DNS
   operations and protocol terms.  Much of the terminology is explained
   in further detail in DNS Terminology [RFC8499].

2.  Deployment Models

   If a zone owner can use standard zone transfer techniques, then the
   presence of multiple providers does not require modifications to the
   normal deployment models.  In these deployments, there is a single
   signing entity (which may be the zone owner, one of the providers, or
   a separate entity), while the providers act as secondary
   authoritative servers for the zone.

   Occasionally, however, standard zone transfer techniques cannot be
   used.  This could be due to the use of non-standard DNS features, or
   due to operational requirements of a given provider (e.g., a provider
   that only supports "online signing".)  In these scenarios, the
   multiple providers each act like primary servers, independently
   signing data received from the zone owner and serving it to DNS
   queriers.  This configuration presents some novel challenges and
   requirements.

2.1.  Multiple Signer models

   In this category of models, multiple providers each independently
   sign and serve the same zone.  The zone owner typically uses
   provider-specific APIs to update zone content identically at each of
   the providers, and relies on the provider to perform signing of the
   data.  A key requirement here is to manage the contents of the DNSKEY
   and Delegation Signer (DS) RRsets in such a way that validating
   resolvers always have a viable path to authenticate the DNSSEC
   signature chain, no matter which provider is queried.  This
   requirement is achieved by having each provider import the public
   Zone Signing Keys (ZSKs) of all other providers into their DNSKEY
   RRsets.

Huque, et al.           Expires October 21, 2020                [Page 3]
Internet-Draft         Multi Signer DNSSEC models             April 2020

   
Internet-Draft      MPLS LSP Ping Relayed Echo Reply       December 2014

       if (Relay Node Address Stack TLV exists) {
           Print the last address in the stack;
       } else {
           Print the source IP address of Echo Reply message;
       }

5.  LSP Ping Relayed Echo Reply Example

   Considering the inter-AS scenario in Figure 4 below.

   +-------+   +-------+   +------+   +------+   +------+   +------+
   |       |   |       |   |      |   |      |   |      |   |      |
   |  PE1  +---+   P1  +---+ ASBR1+---+ ASBR2+---+  P2  +---+  PE2 |
   |       |   |       |   |      |   |      |   |      |   |      |
   +-------+   +-------+   +------+   +------+   +------+   +------+
   <---------------AS1-------------><---------------AS2------------>
   <--------------------------- LSP ------------------------------->

                      Figure 4: Example Inter-AS LSP

   In the example, an LSP has been created between PE1 to PE2.  When
   performing LSP traceroute on the LSP, the first Echo Request sent by
   PE1 with outer-most label TTL=1, contains the Relay Node Address
   Stack TLV with PE1's address.

   After processed by P1, P1's address will be added in the Relay Node
   Address Stack TLV address list following PE1's address in the Echo
   Reply.

   PE1 copies the Relay Node Address Stack TLV into the next Echo
   Request when receiving the Echo Reply.

   Upon receiving the Echo Request, ASBR1 checks the address list in the
   Relay Node Address Stack TLV in sequence, and finds out that PE1's
   address is routable.  Then deletes P1's address, and adds its own
   address following PE1 address.  As a result, there would be PE1's
   address followed by ASBR1's address in the Relay Node Address Stack
   TLV of the Echo Reply sent by ASBR1.

   PE1 then sends an Echo Request with outer-most label TTL=3,
   containing the Relay Node Address Stack TLV copied from the received
   Echo Reply message.  Upon receiving the Echo Request message, ASBR2
   checks the address list in the Relay Node Address Stack TLV in
   sequence, and finds out that PE1's address is IP route unreachable,
   and ASBR1's address is the first routable one in the Relay Node

Luo, et al.               Expires June 8, 2015                 [Page 11]
Internet-Draft      MPLS LSP Ping Relayed Echo Reply       December 2014

   Address Stack TLV.  So ASBR1 is the next relay node.  ASBR2 adds its
   address as the last address item following ASBR1's address in Relay
   Node Address Stack TLV, sets ASBR1's address as the destination
   address of the Relayed Echo Reply, and sends the Relayed Echo Reply
   to ASBR1.

   Upon receiving the Relayed Echo Reply from ASBR2, ASBR1 checks the
   address list in the Relay Node Address Stack TLV in sequence, and
   finds out that PE1's address is first routable one in the address
   list.  So PE1 is the next relay node.  Then ASBR1 sends an Echo Reply
   to PE1 with the payload of the received Relayed Echo Reply unchanged
   other than the Message Type field.

   For the Echo Request with outer-most label TTL=4, P2 checks the
   address list in the Relay Node Address Stack TLV in sequence, and
   finds out that both PE1's and ASBR1's addresses are not IP routable,
   and ASBR2's address is the first routable address.  Then P2 sends an
   Relayed Echo Reply to ASBR2 with the Relay Node Address Stack TLV
   containing four addresses, PE1's, ASBR1's, ASBR2's and P2's address
   in sequence.

   Then according to the process described in section 4.4, ASBR2 sends
   the Relayed Echo Reply to ASBR1.  Upon receiving the Relayed Echo
   Reply, ASBR1 sends an Echo Reply to PE1 which is IP routable.  And as
   relayed by ASBR2 and ASBR1, the Echo Reply would finally be sent to
   the initiator PE1.

   For the Echo Request with outer-most label TTL=5, the Echo Reply
   would relayed to PE1 by ASBR2 and ASBR1, similar to the case of
   TTL=4.

   The Echo Reply from the replying node which has no IP reachable route
   to the initiator is finally transmitted to the initiator by multiple
   relay nodes.

   In the case that the interface address of ASBR1 to P1 is IP1 which
   maybe an IPv4 private address and not IP routable for AS2, and the
   loopback address on ASRB1 is IP2 which is routable for AS2.  Then
   when ASBR1 sends a Relayed Echo Reply, it will firstly add IP1
   without K bit set in the Relay Node Address Stack TLV, and then add
   IP2 with K bit set in the stack TLV.  Then ASBR2/P2 could relay the
   Relayed Echo Reply back first to IP2 which is routable for ASBR2/P2,
   then ASBR1 will send Echo Reply to PE1.  Thanks for the K bit, the
   ASBR1 will not be skipped for message relay.

Luo, et al.               Expires June 8, 2015                 [Page 12]
Internet-Draft      MPLS LSP Ping Relayed Echo Reply       December 2014

6.  Security Considerations

   The Relayed Echo Reply mechanism for LSP Ping creates an increased
   risk of DoS by putting the IP address of a target router in the Relay
   Node Address Stack.  These messages then could be used to attack the
   control plane of an LSR by overwhelming it with these packets.  A
   rate limiter SHOULD be applied to the well-known UDP port on the
   relay node as suggested in [RFC4379].  The node which acts as a relay
   node SHOULD validate the relay reply against a set of valid source
   addresses and discard packets from untrusted border router addresses.
   An implementation SHOULD provide such filtering capabilities.

   If an operator wants to obscure their nodes, it is RECOMMENDED that
   they may replace the replying node address that originated the Echo
   Reply with blank address in Relay Node Address Stack TLV.

   Other security considerations discussed in [RFC4379], are also
   applicable to this document.

7.  Backward Compatibility

   When one of the nodes along the LSP does not support the mechanism
   specified in this document, the node will ignore the Relay Node
   Address Stack TLV as described in section 4.2.  Then the initiator
   may not receive the Relay Node Address Stack TLV in Echo Reply
   message from that node.  In this case, an indication should be
   reported to the operator, and the Relay Node Address Stack TLV in the
   next Echo Request message should be copied from the previous Echo
   Request, and continue the ping process.  If the node described above
   is located between the initiator and the first relay node, the ping
   process could continue without interruption.

8.  IANA Considerations

   IANA is requested to assign one new Message Type, one new TLV and one
   new Return Code.

8.1.  New Message Type

   This document requires allocation of one new message type from
   "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs)
   Ping Parameters" registry, the "Message Type" registry:

        Value    Meaning
        -----    -------
        TBD      MPLS Relayed Echo Reply

Luo, et al.               Expires June 8, 2015                 [Page 13]
Internet-Draft      MPLS LSP Ping Relayed Echo Reply       December 2014

   The value should be assigned from the "Standards Action" range
   (0-191), and using the lowest free value within this range.

8.2.  New TLV

   This document requires allocation of one new TLV from "Multi-Protocol
   Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters"
   registry, the "TLVs" registry:

        Type    Meaning
        ----    --------
        TBD     Relay Node Address Stack TLV

   A suggested value should be assigned from "Standards Action" range
   (32768-49161) as suggested by [RFC4379] Section 3, using the first
   free value within this range.

8.3.  New Return Code

   This document requires allocation of one new return code from "Multi-
   Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping
   Parameters" registry, the "Return Codes" registry:

    Value    Meaning
    -----    -------
    TBD      Response Packet length was exceeded unexpected by the Relay
             Node Address Stack TLV unexpected

   The value should be assigned from the "Standards Action" range
   (0-191), and using the lowest free value within this range.

9.  Acknowledgement

   The authors would like to thank Carlos Pignataro, Xinwen Jiao, Manuel
   Paul, Loa Andersson, Wim Henderickx, Mach Chen, Thomas Morin, Gregory
   Mirsky, Nobo Akiya and Joel M.  Halpern for their valuable comments
   and suggestions.

10.  Contributors

   Ryan Zheng
   JSPTPD
   371, Zhongshan South Road
   Nanjing, 210006, China
   Email: ryan.zhi.zheng@gmail.com

Luo, et al.               Expires June 8, 2015                 [Page 14]
Internet-Draft      MPLS LSP Ping Relayed Echo Reply       December 2014

11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4379]  Kompella, K. and G. Swallow, "Detecting Multi-Protocol
              Label Switched (MPLS) Data Plane Failures", RFC 4379,
              February 2006.

11.2.  Informative References

   [I-D.ietf-mpls-seamless-mpls]
              Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz,
              M., and D. Steinberg, "Seamless MPLS Architecture", draft-
              ietf-mpls-seamless-mpls-07 (work in progress), June 2014.

Authors' Addresses

   Jian Luo (editor)
   ZTE
   50, Ruanjian Avenue
   Nanjing, 210012, China

   Email: luo.jian@zte.com.cn

   Lizhong Jin (editor)
   Shanghai, China

   Email: lizho.jin@gmail.com

   Thomas Nadeau (editor)
   Lucidvision

   Email: tnadeau@lucidvision.com

   George Swallow (editor)
   Cisco
   300 Beaver Brook Road
   Boxborough , MASSACHUSETTS 01719, USA

   Email: swallow@cisco.com

Luo, et al.               Expires June 8, 2015                 [Page 15]