[prev in list] [next in list] [prev in thread] [next in thread]
List: ipng
Subject: Last-call comments on OAM in SRv6 draft
From: Greg Mirsky <gregimirsky () gmail ! com>
Date: 2021-03-20 21:03:25
Message-ID: CA+RyBmWQHOKoMryWwhWUjd12bs+V=YrctKchFyOZKU4uwQEiOQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Dear Authors, 6man and SPRING community,
I have read this draft and have several comments I want to share with you.
The draft is well-written and I appreciate the work authors put into it.
OAM is the essential element of any networking technology and I believe it
is important that this document will be published soon after the
publication of RFC 8754. Below, please find my comments and questions, some
are just an editorial while some may have more technical impact on the
document. I appreciate your kind consideration.
- As I understand the document, it consists of two parts - informational
and standardization. The informational part explains how existing
mechanisms like ICMPv6 can be applied in the SRv6 environment. Also, the
applicability of RFC 8403 is explained. In the standardization part, the
O-flag is defined and its processing described. I am concerned that that
part of the draft is significantly underdeveloped as the threats that are
created by the introduction of the O-flag are not identified and protection
mechanisms are not sufficiently discussed, specified. As it appears, the
O-flag use in SRv6 is very much similar to what already and for a long time
has been achieved by using ACLs - sampling data flows. Though managing ACL
may be operationally intensive, that is a well-secured process. Using
O-flag that can be exploited by an attacker without sufficient protection,
as currently defined in the draft, is risky and raises the question of
benefit vs. risk. It might be that the benefit of the O-flag is marginal
comparing to the risk and complexity its introductions brings in SRv6.
- in the Introduction section, you've noted that the document
"... includes illustrations of pinging an SRv6 SID for the SID connectivity
checks and to validate the availability of a SID ..."
We know of two modes of path verification - continuity check (CC) and
connectivity verification (CV). The former demonstrates whether there is a
path between two network systems. The latter - is to verify that only
packets transmitted on that particular connection reach the system. If
these commonly accepted definitions of CC and CV also applicable in this
document, what is verified by "SID connectivity check"?
Also, can you point to the definition of availability metric that,
according to the statement, is being validated by pinging a SID?
- if "classic IPv6 loopback address", as the document suggests is
"2001:DB8:A:k::/128", perhaps you can point out a document that established
that tradition.
- The O-flag has been introduced as
The O-flag in SRH is used as a marking-bit in the user packets to
trigger the telemetry data collection and export at the segment
endpoints.
I think that the definition leaves an open question of whether the O-flag
can be set in a test packet originated in the SRv6 domain. For example, can
the O-flag be set on BFD control packets periodically transmitted by the
SRv6 node?
- Pseudocode S01.1 suggests that an implementation that supports the
O-flag makes a copy of the marked packet and punts that copy to the control
plane. Such processing seems to create a new DoS attack vector even though
the Security Considerations section does not acknowledge that. It appears
that that part of processing should be discussed in the Security
Considerations section and mechanisms to mitigate the threat explained.
- In the explanation of traceroute through the reference model some
entity is referenced as hop2. What is it?
- Perhaps s/SRv6 capable/SRv6-capable/
- Section 3.2.2 describes SID tracing using UDP transport for a test
packet. I couldn't find information on the selection of the destination UDP
port number for tracing SID. What is it?
- Should note that the method to sample a data flow, described in
Section 3.3, is similar to what can be achieved using IOAM's Direct
Export trace type
<https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/>.
Also, the Hybrid Two-Step method of collecting the telemetry information
<https://datatracker.ietf.org/doc/draft-mirsky-ippm-hybrid-two-step/>
may result in fewer additional packets and simplify the correlation of the
collected data.
Regards,
Greg
[Attachment #5 (text/html)]
<div dir="ltr">Dear Authors, 6man and SPRING community,<div>I have read this draft \
and have several comments I want to share with you.</div><div>The draft is \
well-written and I appreciate the work authors put into it. OAM is the essential \
element of any networking technology and I believe it is important that this document \
will be published soon after the publication of RFC 8754. Below, please find my \
comments and questions, some are just an editorial while some may have more \
technical impact on the document. I appreciate your kind \
consideration.</div><div><ul><li>As I understand the document, it consists of two \
parts - informational and standardization. The informational part explains how \
existing mechanisms like ICMPv6 can be applied in the SRv6 environment. Also, the \
applicability of RFC 8403 is explained. In the standardization part, the O-flag is \
defined and its processing described. I am concerned that that part of the draft is \
significantly underdeveloped as the threats that are created by the introduction of \
the O-flag are not identified and protection mechanisms are not sufficiently \
discussed, specified. As it appears, the O-flag use in SRv6 is very much similar to \
what already and for a long time has been achieved by using ACLs - sampling data \
flows. Though managing ACL may be operationally intensive, that is a well-secured \
process. Using O-flag that can be exploited by an attacker without sufficient \
protection, as currently defined in the draft, is risky and raises the question of \
benefit vs. risk. It might be that the benefit of the O-flag is marginal comparing to \
the risk and complexity its introductions brings in SRv6.</li><li>in the Introduction \
section, you've noted that the document</li></ul></div><blockquote \
style="margin:0 0 0 40px;border:none;padding:0px"><div>"... includes \
illustrations of pinging an SRv6 SID for the SID connectivity checks and to validate \
the availability of a SID ..."</div></blockquote><blockquote style="margin:0 0 0 \
40px;border:none;padding:0px"><div>We know of two modes of path verification - \
continuity check (CC) and connectivity verification (CV). The former demonstrates \
whether there is a path between two network systems. The latter - is to verify that \
only packets transmitted on that particular connection reach the system. If these \
commonly accepted definitions of CC and CV also applicable in this document, what is \
verified by "SID connectivity check"?</div></blockquote><blockquote \
style="margin:0 0 0 40px;border:none;padding:0px"><div>Also, can you point to the \
definition of availability metric that, according to the statement, is being \
validated by pinging a SID?</div></blockquote><ul><li>if "classic IPv6 loopback \
address", as the document suggests is "2001:DB8:A:k::/128", perhaps \
you can point out a document that established that tradition.</li><li>The O-flag has \
been introduced as</li></ul><blockquote style="margin:0 0 0 \
40px;border:none;padding:0px"> The O-flag in SRH is used as a marking-bit in the \
user packets to<br> trigger the telemetry data collection and export at the \
segment<br> endpoints.<br>I think that the definition leaves an open question of \
whether the O-flag can be set in a test packet originated in the SRv6 domain. For \
example, can the O-flag be set on BFD control packets periodically transmitted by the \
SRv6 node?<br></blockquote><ul><li>Pseudocode S01.1 suggests that an implementation \
that supports the O-flag makes a copy of the marked packet and punts that copy to the \
control plane. Such processing seems to create a new DoS attack vector even though \
the Security Considerations section does not acknowledge that. It appears that that \
part of processing should be discussed in the Security Considerations section and \
mechanisms to mitigate the threat explained.</li><li>In the explanation of \
traceroute through the reference model some entity is referenced as hop2. What is \
it?</li><li>Perhaps s/SRv6 capable/SRv6-capable/</li><li>Section 3.2.2 describes SID \
tracing using UDP transport for a test packet. I couldn't find information on the \
selection of the destination UDP port number for tracing SID. What is \
it?</li><li>Should note that the method to sample a data flow, described in Section \
3.3, is similar to what can be achieved using <a \
href="https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/">IOAM's \
Direct Export trace type</a>. Also, the <a \
href="https://datatracker.ietf.org/doc/draft-mirsky-ippm-hybrid-two-step/">Hybrid \
Two-Step method of collecting the telemetry information</a> may result in fewer \
additional packets and simplify the correlation of the collected data. \
</li></ul><div>Regards,</div><div>Greg</div></div>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic