draft-ietf-dnssd-srp-08.txt   draft-ietf-dnssd-srp-09.txt 
Internet Engineering Task Force T. Lemon Internet Engineering Task Force T. Lemon
Internet-Draft S. Cheshire Internet-Draft S. Cheshire
Intended status: Standards Track Apple Inc. Intended status: Standards Track Apple Inc.
Expires: 11 July 2021 7 January 2021 Expires: 15 July 2021 11 January 2021
Service Registration Protocol for DNS-Based Service Discovery Service Registration Protocol for DNS-Based Service Discovery
draft-ietf-dnssd-srp-08 draft-ietf-dnssd-srp-09
Abstract Abstract
The Service Registration Protocol for DNS-Based Service Discovery The Service Registration Protocol for DNS-Based Service Discovery
uses the standard DNS Update mechanism to enable DNS-Based Service uses the standard DNS Update mechanism to enable DNS-Based Service
Discovery using only unicast packets. This makes it possible to Discovery using only unicast packets. This makes it possible to
deploy DNS Service Discovery without multicast, which greatly deploy DNS Service Discovery without multicast, which greatly
improves scalability and improves performance on networks where improves scalability and improves performance on networks where
multicast service is not an optimal choice, particularly 802.11 multicast service is not an optimal choice, particularly 802.11
(Wi-Fi) and 802.15.4 (IoT) networks. DNS-SD Service registration (Wi-Fi) and 802.15.4 (IoT) networks. DNS-SD Service registration
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on 11 July 2021. This Internet-Draft will expire on 15 July 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 26 skipping to change at page 2, line 26
2.2. Protocol Details . . . . . . . . . . . . . . . . . . . . 6 2.2. Protocol Details . . . . . . . . . . . . . . . . . . . . 6
2.2.1. What to publish . . . . . . . . . . . . . . . . . . . 7 2.2.1. What to publish . . . . . . . . . . . . . . . . . . . 7
2.2.2. Where to publish it . . . . . . . . . . . . . . . . . 7 2.2.2. Where to publish it . . . . . . . . . . . . . . . . . 7
2.2.3. How to publish it . . . . . . . . . . . . . . . . . . 8 2.2.3. How to publish it . . . . . . . . . . . . . . . . . . 8
2.2.4. How to secure it . . . . . . . . . . . . . . . . . . 9 2.2.4. How to secure it . . . . . . . . . . . . . . . . . . 9
2.2.5. Service Behavior . . . . . . . . . . . . . . . . . . 9 2.2.5. Service Behavior . . . . . . . . . . . . . . . . . . 9
2.3. SRP Server Behavior . . . . . . . . . . . . . . . . . . . 12 2.3. SRP Server Behavior . . . . . . . . . . . . . . . . . . . 12
2.3.1. Validation of Adds and Deletes . . . . . . . . . . . 12 2.3.1. Validation of Adds and Deletes . . . . . . . . . . . 12
2.3.2. Valid SRP Update Requirements . . . . . . . . . . . . 14 2.3.2. Valid SRP Update Requirements . . . . . . . . . . . . 14
2.3.3. FCFS Name And Signature Validation . . . . . . . . . 15 2.3.3. FCFS Name And Signature Validation . . . . . . . . . 15
2.3.4. SRP Update response . . . . . . . . . . . . . . . . . 15 2.3.4. SRP Update response . . . . . . . . . . . . . . . . . 16
2.3.5. Optional Behavior . . . . . . . . . . . . . . . . . . 16 2.3.5. Optional Behavior . . . . . . . . . . . . . . . . . . 16
3. TTL Consistency . . . . . . . . . . . . . . . . . . . . . . . 16 3. TTL Consistency . . . . . . . . . . . . . . . . . . . . . . . 17
4. Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . 17 4. Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1. Cleaning up stale data . . . . . . . . . . . . . . . . . 17 4.1. Cleaning up stale data . . . . . . . . . . . . . . . . . 17
5. Sleep Proxy . . . . . . . . . . . . . . . . . . . . . . . . . 19 5. Sleep Proxy . . . . . . . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
6.1. Source Validation . . . . . . . . . . . . . . . . . . . . 20 6.1. Source Validation . . . . . . . . . . . . . . . . . . . . 20
6.2. SRP Server Authentication . . . . . . . . . . . . . . . . 21 6.2. SRP Server Authentication . . . . . . . . . . . . . . . . 21
6.3. Required Signature Algorithm . . . . . . . . . . . . . . 21 6.3. Required Signature Algorithm . . . . . . . . . . . . . . 21
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21
8. Delegation of 'service.arpa.' . . . . . . . . . . . . . . . . 21 8. Delegation of 'service.arpa.' . . . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
9.1. Registration and Delegation of 'service.arpa' as a 9.1. Registration and Delegation of 'service.arpa' as a
Special-Use Domain Name . . . . . . . . . . . . . . . . . 22 Special-Use Domain Name . . . . . . . . . . . . . . . . . 22
9.2. 'dnssd-srp' Service Name . . . . . . . . . . . . . . . . 22 9.2. 'dnssd-srp' Service Name . . . . . . . . . . . . . . . . 22
9.3. 'dnssd-srp-tls' Service Name . . . . . . . . . . . . . . 22 9.3. 'dnssd-srp-tls' Service Name . . . . . . . . . . . . . . 22
9.4. Anycast Address . . . . . . . . . . . . . . . . . . . . . 23 9.4. Anycast Address . . . . . . . . . . . . . . . . . . . . . 23
10. Implementation Status . . . . . . . . . . . . . . . . . . . . 23 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 23
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
12. Normative References . . . . . . . . . . . . . . . . . . . . 24 12. Normative References . . . . . . . . . . . . . . . . . . . . 24
13. Informative References . . . . . . . . . . . . . . . . . . . 26 13. Informative References . . . . . . . . . . . . . . . . . . . 26
Appendix A. Testing using standard RFC2136-compliant servers . . 27 Appendix A. Testing using standard RFC2136-compliant servers . . 27
skipping to change at page 14, line 36 skipping to change at page 14, line 36
* exactly one "Add to an RRset" RR that adds a KEY RR that contains * exactly one "Add to an RRset" RR that adds a KEY RR that contains
the public key corresponding to the private key that was used to the public key corresponding to the private key that was used to
sign the message, sign the message,
* there is a Service Instance Name Instruction in the SRP update for * there is a Service Instance Name Instruction in the SRP update for
which the SRV RR that is added points to the hostname being which the SRV RR that is added points to the hostname being
updated by this update. updated by this update.
* Host Description updates do not modify any other records. * Host Description updates do not modify any other records.
2.3.2. Valid SRP Update Requirements 2.3.2. Valid SRP Update Requirements
An SRP Update MUST include at zero or more Service Discovery An SRP Update MUST include zero or more Service Discovery
Instructions, the same number of Service Description Instructions, instructions. For each Service Discovery instruction, there MUST be
and exactly one Host Description Instruction. A DNS Update that does at least one Service Description instruction. For each Service
not is not an SRP update. A DNS Update that contains any other adds, Description instruction there MUST be at least one Service Discovery
any other deletes, or any prerequisites, is not an SRP update. Such instruction with its service instance name as the target of its PTR
messages should either be processed as regular RFC2136 updates, record. There MUST be exactly one Host Description Instruction.
including access control checks and constraint checks, if supported, Every Service Description instruction must have that Host Description
or else rejected with RCODE=REFUSED. instruction as the target of its SRV record. A DNS Update that does
not meet these constraints is not an SRP update.
A DNS Update that contains any additional adds or deletes that cannot
be identified as Service Discovery, Service Description or Host
Description instructions is not an SRP update. A DNS update that
contains any prerequisites is not an SRP update. Such messages
should either be processed as regular RFC2136 updates, including
access control checks and constraint checks, if supported, or else
rejected with RCODE=REFUSED.
In addition, in order for an update to be a valid SRP update, the In addition, in order for an update to be a valid SRP update, the
target of every Service Discovery Instruction MUST be a Service target of every Service Discovery Instruction MUST be a Service
Description Instruction that is present in the SRP Update. There Description Instruction that is present in the SRP Update. There
MUST NOT be any Service Description Instruction to which no Service MUST NOT be any Service Description Instruction to which no Service
Discovery Instruction points. The target of the SRV record in every Discovery Instruction points. The target of the SRV record in every
Service Description instruction MUST be the single Host Description Service Description instruction MUST be the single Host Description
Instruction. Instruction.
If the definitions of each of these instructions are followed If the definitions of each of these instructions are followed
 End of changes. 7 change blocks. 
14 lines changed or deleted 23 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/