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

Hi Tom,

https://tools.ietf.org/html/draft-ali-spring-srv6-pm-02#section-3.2
Defines a Delay Measurement SRH TLV that is only used by a specific SID Type.
https://tools.ietf.org/html/draft-li-spring-passive-pm-for-srv6-np-00#section-5.3
Similar to above, I expect there would be some merging in their future.

https://tools.ietf.org/html/draft-ali-spring-srv6-oam-01(section4.4)
https://tools.ietf.org/html/draft-brockners-inband-oam-transport-05#section-7.1
Defines a Proof of Transit TLV for SRH.

Darren

On Jul 11, 2018, at 8:50 AM, Tom Herbert <tom@herbertland.com<mailto:tom@herbertland.com>> wrote:

On Tue, Jul 10, 2018 at 4:32 PM, Darren Dukes (ddukes) <ddukes@cisco.com<mailto:ddukes@cisco.com>> wrote:
In this draft HMAC is the only one, but others are being defined for OAM,
SFC and other use cases.

Darren,

Please provide references to those. For OAM at least, I believe that
Hop-by-hop and Destination options are being defined to handle that.
What would be the need for defining options like this in a router
header also?

Thanks,
Tom

Darren

On Jul 10, 2018, at 4:01 PM, Tom Herbert <tom@herbertland.com<mailto:tom@herbertland.com>> wrote:

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
--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org<mailto:ipv6@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------