Re: draft-ietf-6man-segment-routing-header-14

Hi Ron, the beneficial properties of SRH TLVs are:
1 - srh tlvs may be added/deleted at each segment.
2 - srh tlvs need not be parsed at each segment (dependent on local policy per active segment).

Darren

On Jul 11, 2018, at 12:54 PM, Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>> wrote:

Hi Tom,

Your email reflects the issue that I raised in https://trac.ietf.org/trac/6man/ticket/38. Since we both raised the issue, it probably deserves some discussion.

In SRv6, we have optional information (OI) that needs to be propagated downstream. IPv6 provides the following propagation mechanisms:

-          The HBH header propagates OI to every downstream node including the destination [1]
-          The DO header that precedes the RH propagates OI to every segment endpoint, including the ultimate destination
-          The DO header that follows the RH propagates OI to the  ultimate destination only

The SRH TLV is unlike any of these. It propagates OI to every segment endpoint, except for the ultimate destination.

So, before we begin the analysis, we can say that any OI that needs to be propagated to every segment endpoint except for the ultimate destination should be encoded in an SRH TLV. I am not sure that any such OI exists, but maybe Clarence and Darren can fill in the blanks.

The following analysis applies to other SRv6 OI:

The following are benefits of encoding in the Destination Option:
-          The OI may be generalizable. Or, said another way, the OI may be useful in packets that contain a different RH Type (e.g., the IP Mobility type or another RH type that might be specified in the future).
-          The Act and Chg bit semantics are already defined and can be leveraged.

The following are the benefits of encoding in SRH TLVs:
-          Conservation of space in the HBH and Destination Option type registry
-          Reduces effort required by those who have already deployed TLVs [2]

Clarence, Darren, can you think of any other benefits?

                                                         Ron

[1] The HBH is not really an option because so many network block it
[2] According to Section 8 of this document, there is only one pre-standard implementation of the TLV.

From: Tom Herbert <tom@herbertland.com<mailto:tom@herbertland.com>>
Sent: Tuesday, July 10, 2018 4:02 PM
To: Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>>
Cc: 6man <ipv6@ietf.org<mailto:ipv6@ietf.org>>
Subject: Re: draft-ietf-6man-segment-routing-header-14

On Mon, Jul 9, 2018, 3:21 PM Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>> wrote:
Clarence,

For the purposes of this draft, I suggest that we remove the HMAC TLV and restrict SRv6 deployment to  walled-gardens. This will allow us to progress the current draft quickly, without working through the security issues associated with routing headers on the global internet.

If this is the case, maybe TLVs can also be removed from the protocol (AFAIK HMAC is only one defined). This would be a big simplication. Subsequently, if HMAC TLV is needed maybe it could be in a destination option before routing header (so it can be processed by each hop in a routing header and such options could marked as modifiable in flight).

Tom

Soon, we will want to address the security issues associated with routing headers on the global Internet and we may want to re-introduce the HMAC TLV then. But it is unlikely that we can address this issues in the next few weeks. This issue, and the HMAC TLV, might better be left for another draft.

The following are security issues:

1) Section 6.2.2 (Performance Impact of HMAC) says, "when present, the HMAC field need only be checked and validated by the first router of the segment routing domain, this router is named 'validating SR router'.  This leads us to ask:

- How does the validating router know that it is the validating router?
- How does a non-validating router know that a packet has already been validated?

The draft is silent regarding these questions. One possibility is that every router on the edge of the segment routing domain:

- Is a validating router
- Maintains an ACL blocking all packets that attempt to circumvent validation by it

This raises the following security issues:

- An attacker can DoS a validating router by sending it a large stream of packets with an invalid MAC. The validating router will discard all of the packets that do not pass validation, but will consume inordinate resources validating the packets.
- Given the HMAC processing procedures specified in the draft, the above mentioned ACL may be computationally expensive and may be impossible to deploy on many existing ASICs
-The HMAC processing procedures specified in version 14 may be incomplete

I think that the above-mentioned ACL looks like this:

If (the packet arrives on an untrusted interface) {
        If (the DA is a SID advertised by any node in the SR domain) {
                If (the packet includes an SRH ) {
                        If (the DA is a SID advertised by the local node) {
                                If (the SRH contains an HMAC TLV) {
                                        ProcessNextACL
                                } else {
                                        Discard
                                }
                        } else {
                                Discard
                        }
                } else {
                        Discard
                }
        } else {
                ProcessNextACL
        }
} else {
        ProcessNextACL
}

Furthermore, before validating the MAC, the validating router MUST verify that Segment List[SL+1] is equal to the IP destination address. This means that the reduced notation described in Section 4.1.1 cannot be used in some cases when the packet originates outside of the SR domain.

You may want to moves some of the functionality from the ACL into HMAC processing. But if you do that, you should describe the HMAC processing completely in the document.

                                                                  Ron

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org<mailto:ipv6@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=7pfDdFr9x4UVZOuyO9BDLzCBts8K3jKCR0o_gOH7tuI&s=RPO1ugMdF986DV5TCBs5b3ZTQzljRJ5FV_HrFl94ku0&e=>
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org<mailto:ipv6@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------