draft-ietf-dots-signal-call-home-02.txt   draft-ietf-dots-signal-call-home-03.txt 
DOTS T. Reddy DOTS T. Reddy
Internet-Draft McAfee Internet-Draft McAfee
Intended status: Standards Track M. Boucadair Intended status: Standards Track M. Boucadair
Expires: December 2, 2019 Orange Expires: January 9, 2020 Orange
J. Shallow J. Shallow
May 31, 2019 July 08, 2019
Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal
Channel Call Home Channel Call Home
draft-ietf-dots-signal-call-home-02 draft-ietf-dots-signal-call-home-03
Abstract Abstract
This document specifies the DOTS signal channel Call Home service, This document specifies the DOTS signal channel Call Home service,
which enables a DOTS server to initiate a secure connection to a DOTS which enables a DOTS server to initiate a secure connection to a DOTS
client, and to receive the attack traffic information from the DOTS client, and to receive the attack traffic information from the DOTS
client. The DOTS server in turn uses the attack traffic information client. The DOTS server in turn uses the attack traffic information
to identify the compromised devices launching the outgoing DDoS to identify the compromised devices launching the outgoing DDoS
attack and takes appropriate mitigation action(s). attack and takes appropriate mitigation action(s).
The DOTS Call Home service is not specific to the home networks; the The DOTS Call Home service is not specific to the home networks; the
solution targets any deployment which requires to block DDoS attack solution targets any deployment which requires to block DDoS attack
traffic closer to the source(s) of a DDoS attack. traffic closer to the source(s) of a DDoS attack.
Editorial Note (To be removed by RFC Editor)
Please update these statements within the document with the RFC
number to be assigned to this document:
o "This version of this YANG module is part of RFC XXXX;"
o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling
(DOTS) Signal Channel Call Home";
o "| [RFCXXXX] |"
o reference: RFC XXXX
Please update this statement with the RFC number to be assigned to
the following documents:
o "RFC YYYY: Distributed Denial-of-Service Open Threat Signaling
(DOTS) Signal Channel Specification (used to be I-D.ietf-dots-
signal-channel)
Please update TBD statements with the assignment made by IANA to DOTS
Signal Channel Call Home.
Also, please update the "revision" date of the YANG module.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 December 2, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. The Solution . . . . . . . . . . . . . . . . . . . . . . 4 1.2. The Solution . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Applicability Scope . . . . . . . . . . . . . . . . . . . 5 1.3. Applicability Scope . . . . . . . . . . . . . . . . . . . 6
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. DOTS Signal Channel Call Home . . . . . . . . . . . . . . . . 7 3. DOTS Signal Channel Call Home . . . . . . . . . . . . . . . . 8
3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 8 3.2. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 9
3.3. DOTS Signal Channel Extension . . . . . . . . . . . . . . 9 3.3. DOTS Signal Channel Extension . . . . . . . . . . . . . . 10
3.3.1. Mitigation Request . . . . . . . . . . . . . . . . . 9 3.3.1. Mitigation Request . . . . . . . . . . . . . . . . . 10
3.3.2. DOTS Signal Call Home YANG Module . . . . . . . . . . 14 3.3.2. Address Sharing Considerations . . . . . . . . . . . 12
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 3.3.3. DOTS Signal Call Home YANG Module . . . . . . . . . . 15
4.1. DOTS Signal Channel Call Home UDP and TCP Port Number . . 17
4.2. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 17 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
4.3. New DOTS Conflict Cause . . . . . . . . . . . . . . . . . 18 4.1. DOTS Signal Channel Call Home UDP and TCP Port Number . . 19
4.4. DOTS Signal Call Home YANG Module . . . . . . . . . . . . 18 4.2. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 19
5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 4.3. New DOTS Conflict Cause . . . . . . . . . . . . . . . . . 20
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 4.4. DOTS Signal Call Home YANG Module . . . . . . . . . . . . 21
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . 21 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 9.1. Normative References . . . . . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. Disambiguate Base DOTS Signal vs. Call Home . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
1.1. The Problem 1.1. The Problem
The DOTS signal channel protocol [I-D.ietf-dots-signal-channel] is The DOTS signal channel protocol [I-D.ietf-dots-signal-channel] is
used to carry information about a network resource or a network (or a used to carry information about a network resource or a network (or a
part thereof) that is under a Distributed Denial of Service (DDoS) part thereof) that is under a Distributed Denial of Service (DDoS)
attack. Such information is sent by a DOTS client to one or multiple attack. Such information is sent by a DOTS client to one or multiple
DOTS servers so that appropriate mitigation actions are undertaken on DOTS servers so that appropriate mitigation actions are undertaken on
traffic deemed suspicious. Various use cases are discussed in traffic deemed suspicious. Various use cases are discussed in
[I-D.ietf-dots-use-cases]. [I-D.ietf-dots-use-cases].
Internet of Things (IoT) devices are becoming more and more prevalent Internet of Things (IoT) devices are becoming more and more prevalent
in home networks, and with compute and memory becoming cheaper and in home networks, and with compute and memory becoming cheaper and
cheaper, various types of IoT devices become available in the cheaper, various types of IoT devices become available in the
consumer market at affordable price. But on the downside, the main consumer market at affordable prices. But on the downside, the main
threat being most of these IoT devices are bought off-the-shelf and threat being most of these IoT devices are bought off-the-shelf and
most manufacturers haven't considered security in the product design. most manufacturers haven't considered security in the product design.
IoT devices deployed in home networks can be easily compromised, they IoT devices deployed in home networks can be easily compromised, they
do not have an easy mechanism to upgrade, and IoT manufactures may do not have an easy mechanism to upgrade, and IoT manufactures may
cease manufacture and/or discontinue patching vulnerabilities on IoT cease manufacture and/or discontinue patching vulnerabilities on IoT
devices (Sections 5.4 and 5.5 of [RFC8576]). However, these devices (Sections 5.4 and 5.5 of [RFC8576]). However, these
vulnerable and compromised devices will continue to be used for a vulnerable and compromised devices will continue to be used for a
long period of time in the home, and the end-user does not know that long period of time in the home, and the end-user does not know that
IoT devices in his/her home are compromised. The compromised IoT IoT devices in his/her home are compromised. The compromised IoT
devices are typically used for launching DDoS attacks (Section 3 of devices are typically used for launching DDoS attacks (Section 3 of
skipping to change at page 4, line 14 skipping to change at page 4, line 41
on a per packet basis is complex. This complexity is due to that the on a per packet basis is complex. This complexity is due to that the
packet itself may look "legitimate" and no attack signature can be packet itself may look "legitimate" and no attack signature can be
identified. The anomaly can be identified only after detailed identified. The anomaly can be identified only after detailed
statistical analysis. statistical analysis.
The ISP on the other hand can detect some DDoS attacks originating The ISP on the other hand can detect some DDoS attacks originating
from a home network (e.g., Section 2.6 of [RFC8517]), but the ISP from a home network (e.g., Section 2.6 of [RFC8517]), but the ISP
does not have a mechanism to detect which device in the home network does not have a mechanism to detect which device in the home network
is generating the DDoS attack traffic. The primary reason being that is generating the DDoS attack traffic. The primary reason being that
devices in an IPv4 home network are typically behind a Network devices in an IPv4 home network are typically behind a Network
Address Translation (NAT) border. Even in case of a IPv6 home Address Translation (NAT) border. Even in case of an IPv6 home
network, although the ISP can identify the infected device in the network, although the ISP can identify the infected device in the
home network launching the DDoS traffic by tracking its unique IPv6 home network launching the DDoS traffic by tracking its unique IPv6
address, the infected device can easily change its IPv6 address to address, the infected device can easily change its IPv6 address to
evade remediation. evade remediation.
Existing approaches are still suffering from misused access network Existing approaches are still suffering from misused access network
resources by abusing devices; the support of means for blocking such resources by abusing devices; the support of means for blocking such
attacks close to the sources are missing. In particular, the DOTS attacks close to the sources are missing. In particular, the DOTS
signal protocol does not discuss cooperative DDoS mitigation between signal protocol does not discuss cooperative DDoS mitigation between
the network hosting an attack source and the ISP to the suppress the the network hosting an attack source and the ISP to the suppress the
skipping to change at page 7, line 13 skipping to change at page 8, line 13
list of such deployments. list of such deployments.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all 14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The reader should be familiar with the terms defined in The reader should be familiar with the terms defined in [RFC8612].
[I-D.ietf-dots-requirements].
The meaning of the symbols in YANG tree diagrams is defined in The meaning of the symbols in YANG tree diagrams is defined in
[RFC8340]. [RFC8340].
(D)TLS is used for statements that apply to both Transport Layer (D)TLS is used for statements that apply to both Transport Layer
Security (TLS) [RFC8446] and Datagram Transport Layer Security (DTLS) Security (TLS) [RFC8446] and Datagram Transport Layer Security (DTLS)
[RFC6347]. Specific terms are used for any statement that applies to [RFC6347]. Specific terms are used for any statement that applies to
either protocol alone. either protocol alone.
3. DOTS Signal Channel Call Home 3. DOTS Signal Channel Call Home
skipping to change at page 8, line 9 skipping to change at page 9, line 9
enables the DOTS server co-located with a network element (possibly enables the DOTS server co-located with a network element (possibly
behind NATs and firewalls) reachable by only the intended DOTS client behind NATs and firewalls) reachable by only the intended DOTS client
and hence the DOTS server cannot be subjected to DDoS attacks. and hence the DOTS server cannot be subjected to DDoS attacks.
Figure 2 illustrates a sample Call Home flow exchange: Figure 2 illustrates a sample Call Home flow exchange:
+--------+ +--------+ +--------+ +--------+
| DOTS | | DOTS | | DOTS | | DOTS |
| server | | client | | server | | client |
+---+----+ +----+---+ +---+----+ +----+---+
(D)TLS client (D)TLS server
| | | |
| 1. (D)TLS connection | | 1. (D)TLS connection |
|----------------------------------->| |----------------------------------->|
| 2. Mitigation request | | 2. Mitigation request |
|<-----------------------------------| |<-----------------------------------|
| ... | | ... |
Figure 2: DOTS Signal Channel Call Home Sequence Diagram Figure 2: DOTS Signal Channel Call Home Sequence Diagram
The DOTS signal channel Call Home procedure is as follows: The DOTS signal channel Call Home procedure is as follows:
1. If UDP transport is used, the DOTS server begins by initiating a 1. If UDP transport is used, the DOTS server begins by initiating a
DTLS connection to the DOTS client. The DOTS client MUST support DTLS connection to the DOTS client.
accepting DTLS connection on the IANA-assigned port number
defined in Section 4.1, but MAY be configured to listen to a
different port number.
If TCP is used, the DOTS server begins by initiating a TCP If TCP is used, the DOTS server begins by initiating a TCP
connection to the DOTS client. The DOTS client MUST support connection to the DOTS client. Using this TCP connection, the
accepting TCP connections on the IANA-assigned port number DOTS server initiates a TLS connection to the DOTS client.
defined in Section 4.1, but MAY be configured to listen to a
different port number. Using this TCP connection, the DOTS In some cases, a DOTS client and server may have mutual agreement
server initiates a TLS connection to the DOTS client. to use a specific port number, such as by explicit configuration
or dynamic discovery [I-D.ietf-dots-server-discovery]. Absent
such mutual agreement, the DOTS signal channel call home MUST run
over port number TBD (that is, DOTS clients must support
accepting DTLS (or TCP) connections on TBD) as defined in
Section 4.1, for both UDP and TCP. The interaction between the
base DOTS signal channel and the call home is discussed in
Appendix A.
The Happy Eyeballs mechanism explained in Section 4.3 of The Happy Eyeballs mechanism explained in Section 4.3 of
[I-D.ietf-dots-signal-channel] can be used for initiating (D)TLS [I-D.ietf-dots-signal-channel] can be used for initiating (D)TLS
connections. connections.
2. Using this (D)TLS connection, the DOTS client may request, 2. Using this (D)TLS connection, the DOTS client may request,
withdraw, or retrieve the status of mitigation requests. withdraw, or retrieve the status of mitigation requests.
3.2. Heartbeat Mechanism 3.2. Heartbeat Mechanism
skipping to change at page 9, line 17 skipping to change at page 10, line 24
It is the responsibility of DOTS servers to ensure that on-path It is the responsibility of DOTS servers to ensure that on-path
translators/firewalls are maintaining a binding so that the same translators/firewalls are maintaining a binding so that the same
external IP address and/or port number is retained for the DOTS external IP address and/or port number is retained for the DOTS
signal channel session. A DOTS client MAY trigger their heartbeat signal channel session. A DOTS client MAY trigger their heartbeat
requests immediately after receiving heartbeat probes from its peer requests immediately after receiving heartbeat probes from its peer
DOTS server. DOTS server.
When an outgoing attack that saturates the outgoing link from the When an outgoing attack that saturates the outgoing link from the
DOTS server is detected and reported by a DOTS client, the latter DOTS server is detected and reported by a DOTS client, the latter
MUST continue to use the signal channel even if no traffic is MUST continue to use the signal channel even if no traffic is
received from the DOTS server. It is most likely that the outgoing received from the DOTS server.
traffic is exceeding the DOTS server domain capacity. As a reminder,
the DOTS client cannot initiate a (D)TLS connection.
If the DOTS server receives traffic from the DOTS client, the DOTS If the DOTS server receives traffic from the DOTS client, the DOTS
server MUST continue to use the signal channel even if the missing server MUST continue to use the signal channel even if the missing
heartbeat allowed threshold is reached. heartbeat allowed threshold is reached.
If the DOTS server does not receive any traffic from the peer DOTS If the DOTS server does not receive any traffic from the peer DOTS
client, the DOTS server sends heartbeat requests to the DOTS client client, the DOTS server sends heartbeat requests to the DOTS client
and after maximum 'missing-hb-allowed' threshold is reached, the DOTS and after maximum 'missing-hb-allowed' threshold is reached, the DOTS
server concludes the session is disconnected. Then, the DOTS server server concludes the session is disconnected. Then, the DOTS server
MUST try to resume the (D)TLS session. MUST try to resume the (D)TLS session.
skipping to change at page 9, line 46 skipping to change at page 10, line 51
Section 4.4.1 of [I-D.ietf-dots-signal-channel] to convey the Section 4.4.1 of [I-D.ietf-dots-signal-channel] to convey the
attacker source prefixes and source port numbers. The DOTS client attacker source prefixes and source port numbers. The DOTS client
conveys the following new parameters in the CBOR body of the conveys the following new parameters in the CBOR body of the
mitigation request: mitigation request:
source-prefix: A list of attacker prefixes used to attack the source-prefix: A list of attacker prefixes used to attack the
target. Prefixes are represented using Classless Inter-Domain target. Prefixes are represented using Classless Inter-Domain
Routing (CIDR) notation [RFC4632]. Routing (CIDR) notation [RFC4632].
As a reminder, the prefix length MUST be less than or equal to 32 As a reminder, the prefix length MUST be less than or equal to 32
(resp. 128) for IPv4 (resp. IPv6). (or 128) for IPv4 (or IPv6).
The prefix list MUST NOT include broadcast, loopback, or multicast The prefix list MUST NOT include broadcast, loopback, or multicast
addresses. These addresses are considered as invalid values. In addresses. These addresses are considered as invalid values. In
addition, the DOTS client MUST validate that attacker prefixes are addition, the DOTS client MUST validate that attacker prefixes are
within the scope of the DOTS server domain. within the scope of the DOTS server domain.
This is an optional attribute. This is an optional attribute for the base DOTS signal channel
operations [I-D.ietf-dots-signal-channel].
source-port-range: A list of port numbers used by the attack traffic source-port-range: A list of port numbers used by the attack traffic
flows. flows.
A port range is defined by two bounds, a lower port number (lower- A port range is defined by two bounds, a lower port number (lower-
port) and an upper port number (upper-port). When only 'lower- port) and an upper port number (upper-port). When only 'lower-
port' is present, it represents a single port number. port' is present, it represents a single port number.
For TCP, UDP, Stream Control Transmission Protocol (SCTP) For TCP, UDP, Stream Control Transmission Protocol (SCTP)
[RFC4960], or Datagram Congestion Control Protocol (DCCP) [RFC4960], or Datagram Congestion Control Protocol (DCCP)
[RFC4340], a range of ports can be, for example, 0-1023, [RFC4340], a range of ports can be any subrange of 0-65535, for
1024-65535, or 1024-49151. example, 0-1023, 1024-65535, or 1024-49151.
This is an optional attribute. This is an optional attribute for the base DOTS signal channel
operations [I-D.ietf-dots-signal-channel].
source-icmp-type: A list of ICMP types used by the attack traffic source-icmp-type-range: A list of ICMP types used by the attack
flows. An ICMP type range is defined by two bounds, a lower ICMP traffic flows. An ICMP type range is defined by two bounds, a
type (lower-type) and an upper ICMP type (upper-type). When only lower ICMP type (lower-type) and an upper ICMP type (upper-type).
'lower-type' is present, it represents a single ICMP type. When only 'lower-type' is present, it represents a single ICMP
type.
This is an optional attribute. This is an optional attribute for the base DOTS signal channel
operations [I-D.ietf-dots-signal-channel].
The 'source-prefix' parameter is a mandatory attribute when the The 'source-prefix' parameter is a mandatory attribute when the
attack traffic information is signaled by a DOTS client in the Call attack traffic information is signaled by a DOTS client in the Call
Home scenario. The 'target-uri' or 'target-fqdn' parameters can be Home scenario (depicted in Figure 2). The 'target-uri' or 'target-
included in a mitigation request for diagnostic purposes to notify fqdn' parameters can be included in a mitigation request for
the DOTS server domain administrator, but SHOULD NOT be used to diagnostic purposes to notify the DOTS server domain administrator,
determine the target IP addresses. Note that 'target-prefix' becomes but SHOULD NOT be used to determine the target IP addresses. Note
a mandatory attribute in the mitigation request signaling the attack that 'target-prefix' becomes a mandatory attribute in the mitigation
information because 'target-uri' and 'target-fqdn' are optional request signaling the attack information because 'target-uri' and
attributes and 'alias-name' will not be conveyed in a mitigation 'target-fqdn' are optional attributes and 'alias-name' will not be
request. conveyed in a mitigation request.
In order to help attack source identification by a DOTS server, the In order to help attack source identification by a DOTS server, the
DOTS client SHOULD include in its mitigation request additional DOTS client SHOULD include in its mitigation request additional
information such as 'source-port-range' or 'source-icmp-type-range'. information such as 'source-port-range' or 'source-icmp-type-range'.
The DOTS client may not include such information if 'source-prefix' The DOTS client may not include such information if 'source-prefix'
conveys an IPv6 address/prefix. conveys an IPv6 address/prefix.
Only immediate mitigation requests (i.e., 'trigger-mitigation' set to Only immediate mitigation requests (i.e., 'trigger-mitigation' set to
'true') are allowed; DOTS clients MUST NOT send requests with 'true') are allowed; DOTS clients MUST NOT send requests with
'trigger-mitigation' set to 'false'. Such requests MUST be discarded 'trigger-mitigation' set to 'false'. Such requests MUST be discarded
by the DOTS server with a 4.00 (Bad Request). by the DOTS server with a 4.00 (Bad Request).
The DOTS server MUST check that the 'source-prefix' is within the
scope of the DOTS server domain in the Call Home scenario. Note that
in such scenario, the DOTS server considers, by default, that any
routeable IP prefix enclosed in 'target-prefix' is within the scope
of the DOTS client. Invalid mitigation requests are handled as per
Section 4.4.1 of [I-D.ietf-dots-signal-channel].
The DOTS server domain administrator consent MAY be required to block
the traffic from the compromised device to the attack target. An
implementation MAY have a configuration knob to block the traffic
from the compromised device to the attack target with or without DOTS
server domain administrator consent. If the attack traffic is
blocked, the DOTS server informs the DOTS client that the attack is
being mitigated.
If the attack traffic information is identified by the DOTS server or
the DOTS server domain administrator as legitimate traffic, the
mitigation request is rejected, and 4.09 (Conflict) is returned to
the DOTS client. The conflict-clause (defined in Section 4.4.1 of
[I-D.ietf-dots-signal-channel]) indicates the cause of the conflict.
The following new value is defined:
4: Mitigation request rejected. This code is returned by the DOTS
server to indicate the attack traffic has been classified as
legitimate traffic.
Once the request is validated by the DOTS server, appropriate actions
are enforced to block the attack traffic within the source network.
The DOTS client is informed about the progress of the attack
mitigation following the rules in [I-D.ietf-dots-signal-channel].
For example, if the DOTS server is embedded in a CPE, it can program
the packet processor to punt all the traffic from the compromised
device to the target to slow path. The CPE inspects the punted slow
path traffic to detect and block the outgoing DDoS attack traffic or
quarantine the device (e.g., using MAC level filtering) until it is
remediated, and notifies the CPE administrator about the compromised
device.
3.3.2. Address Sharing Considerations
If a Carrier Grade NAT (CGN, including NAT64) is located between the If a Carrier Grade NAT (CGN, including NAT64) is located between the
DOTS client domain and DOTS server domain, communicating an external DOTS client domain and DOTS server domain, communicating an external
IP address in a mitigation request is likely to be discarded by the IP address in a mitigation request is likely to be discarded by the
DOTS server because the external IP address is not visible locally to DOTS server because the external IP address is not visible locally to
the DOTS server (see Figure 3). The DOTS server is only aware of the the DOTS server (see Figure 3). The DOTS server is only aware of the
internal IP addresses/prefixes bound to its domain. Thus, the DOTS internal IP addresses/prefixes bound to its domain. Thus, the DOTS
client MUST NOT include the external IP address and/or port number client MUST NOT include the external IP address and/or port number
identifying the suspect attack source, but MUST include the internal identifying the suspect attack source, but MUST include the internal
IP address and/or port number. To that aim, the DOTS client SHOULD IP address and/or port number. To that aim, the DOTS client SHOULD
rely on mechanisms, such as [RFC8512] or [RFC8513], to retrieve the rely on mechanisms, such as [RFC8512] or [RFC8513], to retrieve the
skipping to change at page 12, line 5 skipping to change at page 14, line 5
Figure 3: Example of a CGN between DOTS Domains Figure 3: Example of a CGN between DOTS Domains
If a MAP Border Relay [RFC7597] or lwAFTR [RFC7596] is enabled in the If a MAP Border Relay [RFC7597] or lwAFTR [RFC7596] is enabled in the
provider's domain to service its customers, the identification of an provider's domain to service its customers, the identification of an
attack source bound to an IPv4 address/prefix MUST also rely on attack source bound to an IPv4 address/prefix MUST also rely on
source port numbers because the same IPv4 address is assigned to source port numbers because the same IPv4 address is assigned to
multiple customers. The port information is required to multiple customers. The port information is required to
unambiguously identify the source of an attack. unambiguously identify the source of an attack.
The DOTS server MUST check that the 'source-prefix' is within the
scope of the DOTS server domain in the Call Home scenario. Note that
in such scenario, the DOTS server considers, by default, that any
routeable IP prefix enclosed in 'target-prefix' is within the scope
of the DOTS client. Invalid mitigation requests are handled as per
Section 4.4.1 of [I-D.ietf-dots-signal-channel].
If a translator is enabled on the boundaries of the domain hosting If a translator is enabled on the boundaries of the domain hosting
the DOTS server (e.g., a CPE with NAT enabled as shown in Figures 4 the DOTS server (e.g., a CPE with NAT enabled as shown in Figures 4
and 5), the DOTS server uses the attack traffic information conveyed and 5), the DOTS server uses the attack traffic information conveyed
in a mitigation request to find the internal source IP address of the in a mitigation request to find the internal source IP address of the
compromised device and blocks the traffic from the compromised device compromised device and blocks the traffic from the compromised device
traffic to the attack target until the mitigation request is traffic to the attack target until the mitigation request is
withdrawn. Doing so allows to isolate the suspicious device while withdrawn. Doing so allows to isolate the suspicious device while
avoiding to disturb other services. avoiding to disturb other services.
.-------------------. .-------------------.
skipping to change at page 12, line 48 skipping to change at page 14, line 41
N | .' ' N | .' '
E | ( ) E | ( )
T | ( DOTS server -' T | ( DOTS server -'
W | '-( ) W | '-( )
O | '------+------------' O | '------+------------'
R | | R | |
K | +-----+-------+ K | +-----+-------+
| |Attack Source| | |Attack Source|
+-------------+ +-------------+
Figure 4: Example of a DOTS Server Domain with a NAT Embeded in a CPE Figure 4: Example of a DOTS Server Domain with a NAT Embedded in a
CPE
.-------------------. .-------------------.
( )-. ( )-.
.' Network Provider ' .' Network Provider '
( (DMS) ) ( (DMS) )
( DOTS client -' ( DOTS client -'
'-( ) '-( )
'---------+---------' '---------+---------'
| |
| |
--- +-----+-----+ --- +-----+-----+
skipping to change at page 13, line 31 skipping to change at page 15, line 32
N | .' ' N | .' '
E | ( Local Area Network ) E | ( Local Area Network )
T | ( -' T | ( -'
W | '-( ) W | '-( )
O | '------+------------' O | '------+------------'
R | | R | |
K | +-----+-------+ K | +-----+-------+
| |Attack Source| | |Attack Source|
+-------------+ +-------------+
Figure 5: Example of a DOTS Server and a NAT Embeded in a CPE Figure 5: Example of a DOTS Server and a NAT Embedded in a CPE
The DOTS server domain administrator consent MAY be required to block
the traffic from the compromised device to the attack target. An
implementation MAY have a configuration knob to block the traffic
from the compromised device to the attack target with or without DOTS
server domain administrator consent. If the attack traffic is
blocked, the DOTS server informs the DOTS client that the attack is
being mitigated.
If the attack traffic information is identified by the DOTS server or
the DOTS server domain administrator as legitimate traffic, the
mitigation request is rejected, and 4.09 (Conflict) is returned to
the DOTS client. The conflict-clause (defined in Section 4.4.1 of
[I-D.ietf-dots-signal-channel]) indicates the cause of the conflict.
The following new value is defined:
4: Mitigation request rejected. This code is returned by the DOTS
server to indicate the attack traffic has been classified as
legitimate traffic.
Once the request is validated by the DOTS server, appropriate actions
are enforced to block the attack traffic within the source network.
The DOTS client is informed about the progress of the attack
mitigation following the rules in [I-D.ietf-dots-signal-channel].
For example, if the DOTS server is embedded in a CPE, it can program
the packet processor to punt all the traffic from the compromised
device to the target to slow path. The CPE inspects the punted slow
path traffic to detect and block the outgoing DDoS attack traffic or
quarantine the device (e.g., using MAC level filtering) until it is
remediated, and notifies the CPE administrator about the compromised
device.
3.3.2. DOTS Signal Call Home YANG Module 3.3.3. DOTS Signal Call Home YANG Module
3.3.2.1. Tree Structure 3.3.3.1. Tree Structure
This document augments the "dots-signal-channel" DOTS signal YANG This document augments the "dots-signal-channel" DOTS signal YANG
module defined in [I-D.ietf-dots-signal-channel] for signaling the module defined in [I-D.ietf-dots-signal-channel] for signaling the
attack traffic information. This document defines the YANG module attack traffic information. This document defines the YANG module
"ietf-dots-call-home", which has the following tree structure: "ietf-dots-call-home", which has the following tree structure:
module: ietf-dots-call-home module: ietf-dots-call-home
augment /ietf-signal:dots-signal/ietf-signal:message-type augment /ietf-signal:dots-signal/ietf-signal:message-type
/ietf-signal:mitigation-scope/ietf-signal:scope: /ietf-signal:mitigation-scope/ietf-signal:scope:
+--rw source-prefix* inet:ip-prefix {source-signaling}? +--rw source-prefix* inet:ip-prefix {source-signaling}?
+--rw source-port-range* [lower-port] {source-signaling}? +--rw source-port-range* [lower-port] {source-signaling}?
| +--rw lower-port inet:port-number | +--rw lower-port inet:port-number
| +--rw upper-port? inet:port-number | +--rw upper-port? inet:port-number
+--rw source-icmp-type-range* +--rw source-icmp-type-range*
| [lower-type] {source-signaling}? | [lower-type] {source-signaling}?
+--rw lower-type uint8 +--rw lower-type uint8
+--rw upper-type? uint8 +--rw upper-type? uint8
3.3.2.2. YANG Module 3.3.3.2. YANG Module
This module uses the common YANG types defined in [RFC6991]. This module uses the common YANG types defined in [RFC6991].
<CODE BEGINS> file "ietf-dots-call-home@2019-04-25.yang" <CODE BEGINS> file "ietf-dots-call-home@2019-04-25.yang"
module ietf-dots-call-home { module ietf-dots-call-home {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-dots-call-home"; namespace "urn:ietf:params:xml:ns:yang:ietf-dots-call-home";
prefix call-home; prefix call-home;
skipping to change at page 17, line 32 skipping to change at page 19, line 15
4. IANA Considerations 4. IANA Considerations
4.1. DOTS Signal Channel Call Home UDP and TCP Port Number 4.1. DOTS Signal Channel Call Home UDP and TCP Port Number
IANA is requested to assign the port number TBD to the DOTS signal IANA is requested to assign the port number TBD to the DOTS signal
channel Call Home protocol for both UDP and TCP from the "Service channel Call Home protocol for both UDP and TCP from the "Service
Name and Transport Protocol Port Number Registry" available at: Name and Transport Protocol Port Number Registry" available at:
https://www.iana.org/assignments/service-names-port-numbers/service- https://www.iana.org/assignments/service-names-port-numbers/service-
names-port-numbers.xhtml. names-port-numbers.xhtml.
Service Name: dots-call-home
Port Number: TBD
Transport Protocol(s): TCP/UDP
Description: DOTS Signal Channel Call Home
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Reference: RFC XXXX
The assignment of port number 4647 is strongly suggested (DOTS signal The assignment of port number 4647 is strongly suggested (DOTS signal
channel uses port number 4646). channel uses port number 4646).
4.2. DOTS Signal Channel CBOR Mappings Registry 4.2. DOTS Signal Channel CBOR Mappings Registry
This specification registers the 'source-prefix' and 'source-port- This specification registers the 'source-prefix', 'source-port-
range' parameters in the IANA "DOTS Signal Channel CBOR Mappings" range', and 'source-icmp-type-range' parameters in the IANA "DOTS
registry established by [I-D.ietf-dots-signal-channel]. Signal Channel CBOR Key Values" registry established by
[I-D.ietf-dots-signal-channel] (Figure 6).
The 'source-prefix', 'source-port-range', and 'source-icmp-type- The 'source-prefix', 'source-port-range', and 'source-icmp-type-
range' are comprehension-optional parameters. range' are comprehension-optional parameters.
o Note to the RFC Editor: Please delete (TBD1)-(TBD5) once CBOR keys o Note to the RFC Editor: Please delete (TBD1)-(TBD5) once CBOR keys
are assigned from the 0x8000 - 0xBFFF range. are assigned from the 0x8000 - 0xBFFF range.
+-------------------+------------+--------+---------------+--------+ +-------------------+------------+--------+---------------+--------+
| Parameter Name | YANG | CBOR | CBOR Major | JSON | | Parameter Name | YANG | CBOR | CBOR Major | JSON |
| | Type | Key | Type & | Type | | | Type | Key | Type & | Type |
skipping to change at page 18, line 23 skipping to change at page 20, line 23
| source-port-range | list | 0x8001 | 4 array | Array | | source-port-range | list | 0x8001 | 4 array | Array |
| | | (TBD2) | | | | | | (TBD2) | | |
| source-icmp-type- | list | 0x8002 | 4 array | Array | | source-icmp-type- | list | 0x8002 | 4 array | Array |
| range | | (TBD3) | | | | range | | (TBD3) | | |
| lower-type | uint8 | 0x8003 | 0 unsigned | Number | | lower-type | uint8 | 0x8003 | 0 unsigned | Number |
| | | (TBD4) | | | | | | (TBD4) | | |
| upper-type | uint8 | 0x8004 | 0 unsigned | Number | | upper-type | uint8 | 0x8004 | 0 unsigned | Number |
| | | (TBD5) | | | | | | (TBD5) | | |
+-------------------+------------+--------+---------------+--------+ +-------------------+------------+--------+---------------+--------+
Figure 6: Assigned DOTS Signal Channel CBOR Key Values
4.3. New DOTS Conflict Cause 4.3. New DOTS Conflict Cause
This document requests IANA to assign a new code from the "DOTS This document requests IANA to assign a new code from the "DOTS
Conflict Cause Codes" registry: Signal Channel Conflict Cause Codes" registry:
+------+------------------+-----------------------------+-----------+ +-----+-----------------------------------+-------------+-----------+
| Code | Label | Description | Reference | | Cod | Label | Description | Reference |
+------+------------------+-----------------------------+-----------+ | e | | | |
| 4 | request-rejected | Mitigation request | [RFCXXXX] | +-----+-----------------------------------+-------------+-----------+
| | | rejected. This code is | | | 4 | request-rejected-legitimate- | Mitigation | [RFCXXXX] |
| | | returned by the DOTS server | | | | traffic | request | |
| | | to indicate the attack | | | | | rejected. | |
| | | traffic has been classified | | | | | This code | |
| | | as legitimate traffic. | | | | | is returned | |
+------+------------------+-----------------------------+-----------+ | | | by the DOTS | |
| | | server to | |
| | | indicate | |
| | | the attack | |
| | | traffic has | |
| | | been | |
| | | classified | |
| | | as | |
| | | legitimate | |
| | | traffic. | |
+-----+-----------------------------------+-------------+-----------+
4.4. DOTS Signal Call Home YANG Module 4.4. DOTS Signal Call Home YANG Module
This document requests IANA to register the following URI in the This document requests IANA to register the following URI in the "ns"
"IETF XML Registry" [RFC3688]: subregistry within the "IETF XML Registry" [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:ietf-dots-call-home URI: urn:ietf:params:xml:ns:yang:ietf-dots-call-home
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
This document requests IANA to register the following YANG module in This document requests IANA to register the following YANG module in
the "YANG Module Names" registry [RFC7950]. the "YANG Module Names" subregistry [RFC7950] within the "YANG
Parameters" registry:
Name: ietf-call-home name: ietf-call-home
Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-call-home namespace: urn:ietf:params:xml:ns:yang:ietf-dots-call-home
Maintained by IANA: N maintained by IANA: N
Prefix: call-home prefix: call-home
Reference: RFC XXXX reference: RFC XXXX
5. Security Considerations 5. Security Considerations
This document deviates from classic DOTS signal channel usage by This document deviates from classic DOTS signal channel usage by
having the DOTS server initiate the (D)TLS connection. DOTS signal having the DOTS server initiate the (D)TLS connection. DOTS signal
channel related security considerations discussed in Section 10 of channel related security considerations discussed in Section 10 of
[I-D.ietf-dots-signal-channel] MUST be considered. DOTS agents MUST [I-D.ietf-dots-signal-channel] MUST be considered. DOTS agents MUST
authenticate each other using (D)TLS before a DOTS signal channel authenticate each other using (D)TLS before a DOTS signal channel
session is considered valid. session is considered valid.
skipping to change at page 19, line 33 skipping to change at page 21, line 46
[RFC8446], the ServerHello message contains a Key Share value based [RFC8446], the ServerHello message contains a Key Share value based
on an expensive asymmetric key operation for key establishment. on an expensive asymmetric key operation for key establishment.
Common precautions mitigating DoS attacks are recommended, such as Common precautions mitigating DoS attacks are recommended, such as
temporarily blacklisting the source address after a set number of temporarily blacklisting the source address after a set number of
unsuccessful authentication attempts. unsuccessful authentication attempts.
DOTS servers may not blindly trust mitigation requests from DOTS DOTS servers may not blindly trust mitigation requests from DOTS
clients. For example, DOTS servers can use the attack flow clients. For example, DOTS servers can use the attack flow
information in a mitigation request to enable full-fledged packet information in a mitigation request to enable full-fledged packet
inspection function to inspect all the traffic from the compromised inspection function to inspect all the traffic from the compromised
to the target or to re-direct the traffic from the compromised device device to the target or to re-direct the traffic from the compromised
to the target to a DDoS mitigation system to scrub the suspicious device to the target to a DDoS mitigation system to scrub the
traffic. DOTS servers can also seek the consent of DOTS server suspicious traffic. DOTS servers can also seek the consent of DOTS
domain administrator to block the traffic from the compromised device server domain administrator to block the traffic from the compromised
to the target (see Section 3.3.1). device to the target (see Section 3.3.1).
6. Privacy Considerations 6. Privacy Considerations
The considerations discussed in [RFC6973] were taken into account to The considerations discussed in [RFC6973] were taken into account to
assess whether the DOTS Call Home extension introduces privacy assess whether the DOTS Call Home extension introduces privacy
threats. threats.
Concretely, the protocol does not leak any new information that can Concretely, the protocol does not leak any new information that can
be used to ease surveillance. In particular, the DOTS server is not be used to ease surveillance. In particular, the DOTS server is not
required to share information that is local to its network (e.g., required to share information that is local to its network (e.g.,
skipping to change at page 20, line 43 skipping to change at page 23, line 13
The following individuals have contributed to this document: The following individuals have contributed to this document:
Joshi Harsha Joshi Harsha
McAfee, Inc. McAfee, Inc.
Embassy Golf Link Business Park Embassy Golf Link Business Park
Bangalore, Karnataka 560071 Bangalore, Karnataka 560071
India India
Email: harsha_joshi@mcafee.com Email: harsha_joshi@mcafee.com
Wei Pan
Huawei Technologies
China
Email: william.panwei@huawei.com
8. Acknowledgements 8. Acknowledgements
Thanks to Wei Pei, Xia Liang, Roman Danyliw, Dan Wing, Toema Thanks to Wei Pei, Xia Liang, Roman Danyliw, Dan Wing, Toema
Gavrichenkov, Daniel Migault, and Valery Smyslov for the comments. Gavrichenkov, Daniel Migault, and Valery Smyslov for the comments.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-dots-signal-channel] [I-D.ietf-dots-signal-channel]
skipping to change at page 22, line 5 skipping to change at page 24, line 25
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
9.2. Informative References 9.2. Informative References
[I-D.ietf-dots-multihoming] [I-D.ietf-dots-multihoming]
Boucadair, M. and R. K, "Multi-homing Deployment Boucadair, M. and R. K, "Multi-homing Deployment
Considerations for Distributed-Denial-of-Service Open Considerations for Distributed-Denial-of-Service Open
Threat Signaling (DOTS)", draft-ietf-dots-multihoming-01 Threat Signaling (DOTS)", draft-ietf-dots-multihoming-01
(work in progress), January 2019. (work in progress), January 2019.
[I-D.ietf-dots-requirements]
Mortensen, A., K, R., and R. Moskowitz, "Distributed
Denial of Service (DDoS) Open Threat Signaling
Requirements", draft-ietf-dots-requirements-22 (work in
progress), March 2019.
[I-D.ietf-dots-server-discovery] [I-D.ietf-dots-server-discovery]
Boucadair, M. and R. K, "Distributed-Denial-of-Service Boucadair, M. and R. K, "Distributed-Denial-of-Service
Open Threat Signaling (DOTS) Server Discovery", draft- Open Threat Signaling (DOTS) Server Discovery", draft-
ietf-dots-server-discovery-03 (work in progress), May ietf-dots-server-discovery-04 (work in progress), June
2019. 2019.
[I-D.ietf-dots-use-cases] [I-D.ietf-dots-use-cases]
Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., Dobbins, R., Migault, D., Fouant, S., Moskowitz, R.,
Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS
Open Threat Signaling", draft-ietf-dots-use-cases-17 (work Open Threat Signaling", draft-ietf-dots-use-cases-17 (work
in progress), January 2019. in progress), January 2019.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, Congestion Control Protocol (DCCP)", RFC 4340,
skipping to change at page 23, line 46 skipping to change at page 26, line 16
Jacquenet, "An Inventory of Transport-Centric Functions Jacquenet, "An Inventory of Transport-Centric Functions
Provided by Middleboxes: An Operator Perspective", Provided by Middleboxes: An Operator Perspective",
RFC 8517, DOI 10.17487/RFC8517, February 2019, RFC 8517, DOI 10.17487/RFC8517, February 2019,
<https://www.rfc-editor.org/info/rfc8517>. <https://www.rfc-editor.org/info/rfc8517>.
[RFC8576] Garcia-Morchon, O., Kumar, S., and M. Sethi, "Internet of [RFC8576] Garcia-Morchon, O., Kumar, S., and M. Sethi, "Internet of
Things (IoT) Security: State of the Art and Challenges", Things (IoT) Security: State of the Art and Challenges",
RFC 8576, DOI 10.17487/RFC8576, April 2019, RFC 8576, DOI 10.17487/RFC8576, April 2019,
<https://www.rfc-editor.org/info/rfc8576>. <https://www.rfc-editor.org/info/rfc8576>.
[RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open
Threat Signaling (DOTS) Requirements", RFC 8612,
DOI 10.17487/RFC8612, May 2019,
<https://www.rfc-editor.org/info/rfc8612>.
Appendix A. Disambiguate Base DOTS Signal vs. Call Home
With the call home extension, there is a chance that two DOTS agents
can simultaneously establish two DOTS signal channels with different
directions (base DOTS signal channel and DOTS signal channel call
home). Here is one example drawn from the home network.
Nevertheless, the outcome of the discussion is not specific to these
networks, but applies to any DOTS call home scenario.
In the call home scenario, the DOTS server in the home network can
mitigate the DDoS attacks launched by the compromised device in its
domain by receiving the mitigation request sent by the DOTS client in
the ISP environment. In addition, the DOTS client in the home
network can initiate a mitigation request to the DOTS server in the
ISP environment to ask for help when the home network is under a DDoS
attack. Such DOTS server and DOTS client in the home network can co-
locate in the same home network element (e.g., the Customer Premises
Equipment). In this case, with the same peer at the same time the
home network element will have the basic DOTS signal channel defined
in [I-D.ietf-dots-signal-channel] and the call home DOTS signal
channel defined in this specification. Thus these two signal
channels need to be distinguished when they are both supported.
In the call home scenario, the DOTS server in, for example, the home
network can mitigate the DDoS attacks launched by the compromised
device in its domain by receiving the mitigation request sent by the
DOTS client in the ISP environment. In addition, the DOTS client in
the home network can initiate a mitigation request to the DOTS server
in the ISP environment to ask for help when the home network is under
a DDoS attack. Such DOTS server and DOTS client in the home network
can co-locate in the same home network element (e.g., the Customer
Premises Equipment). In this case, with the same peer at the same
time the home network element will have the basic DOTS signal channel
defined in [I-D.ietf-dots-signal-channel] and the call home DOTS
signal channel defined in this specification. Thus these two signal
channels need to be distinguished when they are both supported. Two
approaches have been considered for distinguishing the two DOTS
signal channels, but only the one that using the dedicated port
number has been chosen as the best choice.
By using a dedicated port number for each, these two signal channels
can be separated unambiguously and easily. For example, the CPE uses
the port number 4646 defined in [I-D.ietf-dots-signal-channel] to
initiate the basic signal channel to the ISP when it acts as the DOTS
client, and uses the port number TBD to initiate the call home signal
channel. Based on the different ports, the ISP can directly decide
which kind of procedures should follow immediately after it receives
the DOTS messages. This approach just requires two (D)TLS sessions
to be established respectively for the basic signal channel and call
home signal channel.
The other approach is signaling the role of each DOTS agent (e.g., by
using the DOTS data channel). For example, the DOTS agent in the
home network first initiates a DOTS data channel to the peer DOTS
agent in the ISP environment, at this time the DOTS agent in the home
network is the DOTS client and the peer DOTS agent in the ISP
environment is the DOTS server. After that, the DOTS agent in the
home network retrieves the DOTS call home capability of the peer DOTS
agent. If the peer supports the call home extension, the DOTS agent
needs to subscribe to the peer to use this extension. Then the
reversal of DOTS role can be recognized as done by both DOTS agents.
When the DOTS agent in the ISP environment, which now is the DOTS
client, wants to filter the attackers' traffic, it requests the DOTS
agent in the home network, which now is the DOTS server, for help.
Signaling the role will complicate the DOTS protocol, and this
complexity is not required in context where call home extension is
not required or only when call home extension is needed. Besides,
the DOTS data channel may not work during attack time. Even if
changing the above example from using the DOTS data channel to the
DOTS signal channel, the more procedures will still reduce the
efficiency. Using the dedicated port number is much easier and more
concise compared to the second approach, and its cost that
establishing two (D)TLS sessions is much less. So, using a dedicated
port number for the call home extension is chosen in this
specification.
Authors' Addresses Authors' Addresses
Tirumaleswar Reddy Tirumaleswar Reddy
McAfee, Inc. McAfee, Inc.
Embassy Golf Link Business Park Embassy Golf Link Business Park
Bangalore, Karnataka 560071 Bangalore, Karnataka 560071
India India
Email: kondtir@gmail.com Email: kondtir@gmail.com
Mohamed Boucadair Mohamed Boucadair
Orange Orange
 End of changes. 41 change blocks. 
139 lines changed or deleted 283 lines changed or added

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