Re: [spring] Benjamin Kaduk's Discuss on draft-ietf-spring-srv6-network-programming-26: (with DISCUSS and COMMENT)

["Pablo Camarillo (pcamaril)" <[e-mail]>]

Ben,

Many thanks for your time to review the document and confirming the DISCUSS point is resolved now.
We'll post a rev28 adding the proposed text for your comment point below.

Thanks,
Pablo.

-----Original Message-----
From: Benjamin Kaduk <[e-mail]> 
Sent: martes, 29 de diciembre de 2020 0:29
To: Pablo Camarillo (pcamaril) <[e-mail]>
Cc: The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; Bruno Decraene <[e-mail]>; Joel Halpern <[e-mail]>
Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-spring-srv6-network-programming-26: (with DISCUSS and COMMENT)

Hi Pablo,

On Thu, Dec 10, 2020 at 06:01:58PM +0000, Pablo Camarillo (pcamaril) wrote:
> Hi Ben,
> 
> Many thanks for your time on this document.
> We’ve published rev27 of the document with the changes.  Details inline with [PC].
> https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming
> -27

Thanks for the updates; I've cleared my discuss in the datatracker.

I'll trim the resolved stuff and just reply on a couple remaining points inline...

> 
> -----Original Message-----
> From: Benjamin Kaduk via Datatracker <[e-mail]>
> Sent: miércoles, 9 de diciembre de 2020 18:05
> To: The IESG <[e-mail]>
> Cc: [e-mail]; 
> [e-mail]; [e-mail]; Bruno Decraene 
> <[e-mail]>; Joel Halpern <[e-mail]>; 
> [e-mail]
> Subject: Benjamin Kaduk's Discuss on 
> draft-ietf-spring-srv6-network-programming-26: (with DISCUSS and 
> COMMENT)
> 
> Section 4.16.1.2
> 
>    As a reminder, [RFC8754] defines in section 5 the SR Deployment Model
>    within the SR Domain [RFC8402].  Within this framework, the
>    Authentication Header (AH) is not used to secure the SRH as described
>    in Section 7.5 of [RFC8754].
> 
> (repeating from the previous thread as a placeholder) I think we need another sentence or clause here to clarify why this statement is relevant, e.g., "Thus, while the AH can detect changes to the IPv6 header chain, it will not be used in combination with the SRH, so use of PSP will not cause delivery failure due to AH validation checks."
> 
> [PC] What about this?
> <OLD>
> Within this framework, the Authentication Header (AH) is not used to secure the SRH as described in Section 7.5 of [RFC8754].
> </OLD>
> <PROPOSAL>
> Within this framework, the Authentication Header (AH) is not used to secure the SRH as described in Section 7.5 of [RFC8754]. Hence, the discussion of applicability of PSP along with AH usage is beyond the scope of this document.
> </PROPOSAL>

That seems okay, thanks.

> Section 9
> 
> There seem to be some security considerations relating to the use of PSP, in that the egress node loses visibility into which policy was used for a given packet, so all packets from all policies that egress via that SID are in the same anonymity (and policy!) set.  In particular, even if an HMAC TLV was present in the SRH, it is not available and cannot be validated.  I recognize that the headend (or whatever entity is assigning SR policy) should know when such validation would be intended to occur and not assign a policy incompatible with it, but there are still new considerations in the sense that the headend needs to be aware of these considerations.
> 
> [PC] As part of the comments from Alvaro we added this text which I believe covers that point:
> “The headend policy definition should be consistent with the specific
>    behavior used and any local configuration”
> 
> (repeating as a placeholder from the previous thread) I think we should also say that in the absence of the HMAC TLV, valid FUNC and ARG values on any given node may be guessable and spoofable, along with the standard disclaimer that risks are minimal since all nodes in the SR domain are assumed to be trusted.  This is distinct from the already-extant ability to spoof a SID in that the underlying structure in the SID may allow the attacker to induce behavior that was never intended to be a SID, for example if the implementation logically separates FUNC and ARG processing and the attacker makes a combination that was never advertised.
> 
> [PC] I believe you are making an implementation assumption on how SIDs are matched at a node. As a reminder RFC8754 states that “When an SRv6-capable node receives an IPv6 packet, it performs a longest-prefix-match lookup on the packet's destination address.”. Thus, the ability to spoof a particular FUNCT is the same as the ability to spoof any other IP address on the node. In the context of SRv6, this is mitigated by using the SR Domain as described in RFC8754 and -in particular Section 7.2-.

I'm definitely making implementation assumptions, yes.  It is possible to implement it in a way that does not suffer the potential issue, though there is a perhaps-tempting way to implement it that does suffer from the issue.

In particular, I'm less concerned about spoofing FUNCT (as you note, it's similar to spoofing other things, including other SIDs) than about spoofing ARG.  The ability to encode semantic information (even when the semantics are only known to the one node) in a part of the IP address in this manner seems like a fairly novel construction, and I was hoping to emphasize that care should be taken when implementing the parser.

Thanks,

Ben