[spring] Chair Review of draft-bdmgct-spring-srv6-security-02 (Adoption)

[Alvaro Retana <[e-mail]>]

Dear authors:

Thank you for taking on this work!

I am providing this review with my Chair Hat on in parallel with the
adoption call.  Please consider it in addition to the other comments
you receive.


In general, the current draft is a very good start!  I know it is a
work in progress, and I expect changes along the way.  Having said
that, I want to highlight some high-level points to consider as you
continue the work.

(1) Scope

    §2 and the document generally focus on the data plane, but the control
    plane plays a significant part in an SRv6 network.  The control plane
    should also be considered.

    Many possible control plane threats (overclaiming, filtering, etc.) are not
    specific to SRv6 but may expose themselves differently in an SRv6 network.
    §6.4 is a start, but I believe more is needed.

(2) Threat Model

    Even though the threat model mentions external attackers, §6 focuses on
    internal attacks, indicating that "it is assumed that SRv6 is deployed
    within a limited domain [RFC8799] with filtering at the domain boundaries,
    forming a trusted domain with respect to SRv6." However, the first set of
    mitigation methods (§7) concerns the domain boundary.

    The formulation of the threat model and the assumptions need to be aligned
    to the mitigations offered.

(3) Relationship to Existing Work

    It is not clear from the current text what the relationship between
    existing work (specifically the existing Security Considerations) and this
    document is.  I hope that this document will not have to include
    "everything" (among other reasons because it would require a great deal of
    duplication) but that it can refer to, complement, or augment (as needed)
    any existing guidance.

    IOW, I expect to see more text of the form: "as rfcxxx recommends, use
    ABC", "rfczzzz already covers this topic", or "in addition to what is
    recommended in rfcggg....".  Even some text like "the recommendation in
    this document replaces what was recommended in rfchhh".


I also included comments in-line (see below).

Thanks!

Alvaro.


[Line numbers from idnits.]

...
123	1.  Introduction
...
137	   *  SRv6 makes use of the SRH which is a new type of Routing Extension
138	      Header.  Some of the security considerations of the SRH are
139	      discussed in [RFC5095] and [RFC8754].

[] The SRH is specified in RFC8754.  To be strict, RFC5095 doesn't
talk about the SRH.  RFC8754 already refers to RFC5095 in its Security
Considerations.


141	   *  SRv6 consists of using the SRH on the IPv6 dataplane, and
142	      therefore known security considerations of IPv6 [RFC9099] are
143	      applicable to SRv6 as well.

[] Please also point to the Security Considerations in rfc8200.


145	   *  While SRv6 uses what appear to be typical IPv6 addresses, the
146	      address space is processed differently by segment endpoints.  A
147	      typical IPv6 unicast address is comprised of a network prefix,
148	      host identifier, and a subnet mask.  A typical SRv6 segment
149	      identifier (SID) is broken into a locator, a function identifier,
150	      and optionally, function arguments.  The locator must be routable,
151	      which enables both SRv6 capable and incapable devices to
152	      participate in forwarding, either as normal IPv6 unicast or SRv6.
153	      The capability to operate in environments that may have gaps in
154	      SRv6 support allows the bridging of islands of SRv6 devices with
155	      standard IPv6 unicast routing.

[] Adding references to rfc8986 and draft-ietf-6man-sids (which should
soon be an RFC) would be useful.



...
160	2.  Scope of this Document
...
181	   We note that SRv6 is under active development and, as such, the above
182	   documents might not cover all protocols employed in an SRv6
183	   deployment.

[] For future versions: draft-ietf-6man-sids is in the RFC Editor's
queue and draft-ietf-spring-srv6-srh-compression is with the IESG.
Both should be RFCs by the time we're done processing this document.



...
205	4.  Threat Model
...
223	   On-path vs. Off-path:  On-path attackers are located in a position
224	      that allows interception, modification or dropping of in-flight
225	      packets, as well as insertion (generation) of packets.  Off-path
226	      attackers can only attack by insertion of packets.

[] Could an off-path attacker be able to interact with the control
plane?  The definition seems to be incomplete.  Or maybe I'm
interpreting "packets" as data plane...


228	   The following figure depicts the attacker types according to the
229	   taxonomy above.  As illustrated in the figure, on-path attackers are
230	   located along the path of the traffic that is under attack, and
231	   therefore can listen, insert, delete, modify or replay packets in
232	   transit.  Off-path attackers can insert packets, and in some cases
233	   can passively listen to some of the traffic, such as multicast
234	   transmissions.

[] This taxonomy is focused on the data plane -- I believe the control
plane should also be considered.


[] "Off-path attackers...can passively listen to some of the traffic,
such as multicast transmissions."

Even if listening to only "some of the traffic", wouldn't the node be on-path?



...
265	   In the context of the current document it is assumed that SRv6 is
266	   deployed within a limited domain [RFC8799] with filtering at the
267	   domain boundaries, forming a trusted domain with respect to SRv6.
268	   Thus, external attackers are outside of the trusted domain.
269	   Specifically, an attack on one domain that is invoked from within a
270	   different domain is considered an external attack in the context of
271	   the current document.

[] rfc8799 is not an IETF consensus document. IMO, this document would
be better served if a description of what is considered a "limited
domain" is included -- instead of doing it by reference.


273	   Following the spirit of [RFC8402], the current document mandates a
274	   filtering mechanism that eliminates the threats from external
275	   attackers.  This approach limits the scope of the attacks described
276	   in this document to within the domain (i.e., internal attackers).

[] "mandates a filtering mechanism"

I couldn't find the MUST/REQUIRED text.  The statement feels out of
place when describing the threat model -- if you keep it here, point
to the section where the requirement is specified.



...
292	5.  Impact

294	   One of the important aspects of a threat analysis is the potential
295	   impact of each threat.  SRv6 allows for the sending of IPv6 packets
296	   via arbitrary paths.  An attack on SRv6 may cause packets to traverse
297	   arbitrary paths within an SR domain.  This may allow an attacker to
298	   perform a number of attacks on the victim networks and hosts that
299	   would be mostly unfeasible for a non-SRv6 environment.

[] s/sending of IPv6 packets/forwarding of IPv6 packets


[] "SRv6 allows for the sending of IPv6 packets via arbitrary paths.
An attack on SRv6 may cause packets to traverse arbitrary paths within
an SR domain."

I guess this text means that the attack uses a *different* set of
"arbitrary paths" (when compared to the intended forwarding path).
Please clarify.


301	   The threat model in [ANSI-Sec] classifies threats according to their
302	   potential impact, defining six categories.  For each of these
303	   categories we briefly discuss its applicability to SRv6 attacks.

305	   *  Unauthorized Access: an attack that results in unauthorized access
306	      might be achieved by having an attacker leverage SRv6 to
307	      circumvent security controls as a result of security devices being
308	      unable to enforce security policies in the presence of IPv6
309	      Extension Headers (see [RFC9098]), or by directing packets through
310	      paths where packet-filtering policies are not enforced.

[] [ANSI-Sec] doesn't explicitly define what "Unauthorized Access" is.
As you're doing here, it explains it by example.  However, I believe
that doing it this way is non-exhaustive and can easily leave out
important examples/considerations.

For example, the examples above are about circumventing access
control.  But that is not comprehensive (or even a representative
example).  "Unauthorized system access to carry out attacks" is an
example given in [ANSI-Sec] that is also applicable to SRv6: an
internal attacker could gain unauthorized access to a node inside the
SR domain.  rfc3552 calls this impact "Unauthorized Usage" or
"Inappropriate Usage".

An example of "inappropriate usage" may be directing packets through a
path that is not intended for the traffic (because it is reserved for
other traffic, has low resources, or whatever else).

All this is to say: please use well-understood/defined concepts (like
the ones in §2/rfc3552).


[] Also, I searched the document for other mentions of "Unauthorized
Access", but didn't find any.  What is the purpose of defining the
impact if it won't be mentioned later (when discussing specific
attacks or possible mitigations)?

[Disclaimer: I didn't look in detail at the other impact terms in this section.]



...
357	6.1.  Attack Abstractions

359	   Packet manipulation and processing attacks can be implemented by
360	   performing a set of one or more basic operations.  These basic
361	   operations (abstractions) are as follows:

[] These abstractions focus on the data plane.  What about control
plane-related abstractions?

On one hand, similar basic operations can be listed for the control
plane.  On the other hand, the operations are not specific to SRv6.
For example, it's possible to listen passively to routing protocols,
independently of whether SRv6 is used or not.  Consider referencing
rfc4593.



...
419	6.2.3.  Impact
...
434	   Preferring a specific path:  The packet can be manipulated to avert
435	      packets to a specific path.  This attack can result in allowing
436	      various unauthorized services such as traffic acceleration.
437	      Alternatively, an attacker can avert traffic to be forwarded
438	      through a specific node that the attacker has access to, thus
439	      facilitating more complex on-path attacks such as passive
440	      listening, recon and various man-in-the-middle attacks.  It is
441	      noted that the SR modification attack is performed by an on-path
442	      attacker who has access to packets in transit, and thus can
443	      implement these attacks directly.  However, SR modification is
444	      relatively easy to implement and requires low processing resources
445	      by an attacker, while it facilitates more complex on-path attacks
446	      by averting the traffic to another node that the attacker has
447	      access to and has more processing resources.

[] "man-in-the-middle" is not inclusive.

The usual replacement term is "on-path".



...
472	6.2.4.  Overview

[] It feels like a new section header is needed before this
subsection: "Recon Attack" ??



...
554	6.4.3.  Impact

556	   A compromised control plane or management plane can impact the
557	   network in various possible ways.  SR policies can be manipulated by
558	   the attacker to avoid specific paths or to prefer specific paths, as
559	   described in Section 6.2.3.  Alternatively, the attacker can
560	   compromise the availability, either by defining SR policies that load
561	   the network resources, as described in Section 6.2.3, or by
562	   blackholing some or all of the SR policies.  A passive attacker can
563	   use the control plane or management plane messages as a means for
564	   recon, in a similar manner to Section 6.2.3.

[] It is true that some of the results from §6.2.3 can be seen, but
some of them may require multiple nodes to be compromised.  Consider
expanding on that.


[] "blackholing" is not inclusive.  Consider "dropping".



...
586	7.1.1.  SRH Filtering

588	   SRv6 packets rely on the routing header in order to steer traffic
589	   that adheres to a defined SRv6 traffic policy.  Thus, SRH filtering
590	   can be enforced at the ingress and egress nodes of the SR domain, so
591	   that packets with an SRH cannot be forwarded into the SR domain or
592	   out of the SR domain.  Specifically, such filtering is performed by
593	   detecting Next Header 43 (Routing Header) with Routing Type 4 (SRH).

[] Several places, including this text from §4, talk about the
assumptions...and then the text focuses on the threats and mitigations
inside the SRv6 domain:

   In the context of the current document it is assumed that SRv6 is
deployed within a limited domain [RFC8799] with filtering at the
domain boundaries, forming a trusted domain with respect to SRv6.

IOW, external attacks are not considered anywhere, except the first
few mitigation methods.  I'm pointing this out not to say that they
should be out of scope, but to say that they were not considered
before.


595	   Because of the methodologies used in SID compression
596	   [I-D.ietf-spring-srv6-srh-compression], SRH compression does not
597	   necessarily use an SRH.  In practice this means that when compressed
598	   segment lists are used without an SRH, filtering based on the Next
599	   Header is not relevant, and thus filtering can only be applied baed
600	   on the address range, as described below.

[] rfc8754 says that "the SRH MAY be omitted".  IOW, this case applies
to all cases, not just when using C-SIDs.



...
625	7.3.  Hashed Message Authentication Code (HMAC)
...
638	   *  The HMAC TLV is OPTIONAL.

[] "OPTIONAL" is an rfc2119 keyword...but it is not used Normatively
in this case (the Normative statement is in rfc8754).
s/OPTIONAL/optional



...
656	8.1.  Limitations in Filtering Capabilities

658	   [RFC9288] provides recommendations on the filtering of IPv6 packets
659	   containing IPv6 extension headers at transit routers.  SRv6 relies on
660	   the routing header (RH4).  Because the technology is reasonably new,
661	   many platforms, routing and otherwise, do not posses the capability
662	   to filter and in some cases even provide logging for IPv6 next-header
663	   43 Routing type 4.

[] This is true...but the text may not age well.  Considering
including something like "at the time of this writing..."


665	8.2.  Middlebox Filtering Issues
...
672	   The security devices on SRv6 networks need to take care of SRv6
673	   packets.  However, the SRv6 packets usually use loopback address of
674	   the PE device a as source address.  As a result, the address
675	   information of SR packets may be asymmetric, resulting in improper
676	   filter traffic problems, which affects the effectiveness of security
677	   devices.  For example, along the forwarding path in SRv6 network, the
678	   SR-aware firewall will check the association relationships of the
679	   bidirectional VPN traffic packets.  And it is able to retrieve the
680	   final destination of SRv6 packet from the last entry in the . When
681	   the <source, destination> tuple of the packet from PE1 to PE2 is
682	   <PE1-IP-ADDR, PE2-VPN-SID>, and the other direction is <PE2-IP-ADDR,
683	   PE1-VPN-SID>, the source address and destination address of the
684	   forward and backward VPN traffic are regarded as different flow.
685	   Eventually, the legal traffic may be blocked by the firewall.

[] s/in the ./in the SRH.


[] TBH, you lost me in the description above.  Wouldn't the same issue
be present in IPv6 networks that don't use SR?



...
788	14.  References

[] I didn't check the status of the references.

[EoR-02]