+spring Hi Joel, Ack on forward reference in 6.2, I’ll use the text I suggested.
However Prefix-H is an example for the following <quote> SR Domain ingress routers permit traffic destined to select SIDs with segment lists. </quote> local policy requiring HMAC TLV processing for those select SIDs, i.e. those SIDs provide a gateway to the SR Domain for a set of Prefix-H is is a useful illustration, but it is only one way an administrator may choose to permit packets destined to SIDs requiring HMAC TLV processing to enter their domain. Depending on the deployment she may decide to permit specific source address to use specific SIDs requiring HMAC processing on specific interfaces only. In this case the fact that all those SIDs are allocated within a Prefix-H is not relevant, nor would she permit packets destined to prefix-H at all ingress nodes. Darren On Oct 22, 2018, at 8:39 PM, Joel M. Halpern <[email protected]<mailto:[email protected]>> wrote: I am not sure I am putting the intended pieces together right. A packet arrives at a domain edge that supports SRv6. There seem now to be several cases (I had ignored prefix-H as fragile, but that is a different debate. 1) The packet is not addressed to any SID in the domain. Then the packet can be processed, possibly encapsulated with an SRH, and sent inwards. 2) The packet is addressed to a SID that is not in prefix-H (i.e. not a SID known to be configured to check HMACs.) Drop the packet. This was the step I had not understood in by previous reading of 6.2.1, as it seems structurally to be part of an example, not a required piece of configuration behavior. 3) The packet is address to a SID in prefix-H. If that SID is this node, check the HMAC and act based on it. If it is some other SID within prefix-H, then send it on its way. If that is the intended behavior, then I would suggest extra text in 6.2. The text can forward reference prefix-H for SIDs known to check HMAC. And should include the case where teh SID is this edge node (which is frankly the most likely and robust way to do the checking.) If you do not intend the configuration and use of prefix-H to be normative, then you need to explain that magic knowledge of such checking is necessary, or that the ingress edge node must check the H-MAC even if it is not the current destination, when it does not have such configuration. Yours, Joel On 10/22/18 8:28 PM, Darren Dukes (ddukes) wrote: On Oct 22, 2018, at 7:52 PM, Joel M. Halpern <[email protected]<mailto:[email protected]> <mailto:[email protected]>> wrote: The text in section 6.2.1 is fine, and clear. It merely contradicts the text in section 6.2. What I am asking is not for a behavioral change, but simply that the text in 6.2 acknoweldge the acception of 6.2.1 explicitly, Are you suggesting text like the following in section 6.2 para 1? “...SHOULD discard packets destined to SIDs within the SR Domain *<new> which do not require HMAC verification </new>* (of the presence of an SRH) to avoid attacks on the SR Domain as described and referenced in [RFC5095]. *<new> SIDs requiring HMAC verification are discussed in Section 6.2.1..</new>*" and as a side effect not state that the discard happens "regardless of the presence of an SRH", since in the presence of an SRH, the edge node has to (I would hope MUST) check the SRH for an HMAC, and attempt to verify the HMAC. There is no need for an edge to check for an SRH when the destination is within Prefix-H (as defined in 6.2.1). I suppose that if the edge node knew that there were no valid HMACs, then it could skip checking the SRH since it can't be valid. If you want that included, do so. It would take a few extra sentence for 6.2 tyo properly set the ground for 6.2.1. I really dislike when the text says "X SHOULD do Y" and then in a later section, without even saying "this is an exception to the above" the text says "X SHOULD do Z under condition Q". It confuses readers. Yours, Joel On 10/22/18 7:45 PM, Darren Dukes (ddukes) wrote: Thanks Joel, please see inline. On Oct 22, 2018, at 6:59 PM, Joel M. Halpern <[email protected]<mailto:[email protected]> <mailto:[email protected]>> wrote: I think this is a minor issue. Sections 6.2 and 6.2.1 talk about processing of packets from outside the SR Domain. Section 6.2, says that edge nodes "SHOULD discard packets destined to SIDs within the SR domain." Sounds good. It even includes the parenthetical "(regardless of the presence of an SRH)" Which sounds even better. But is contradicted by section 6.2.1. Section 6.2.1 says that an trusted external node can provide an SRH. The trusted node protects that SRH with an HMAC TLV. At the domain edge, I presume we know it is a trusted node by the HMAC TLV. (Not by the IP Source address, since that may be false.) Which means that in fact, the discard in section 6.2 is not "regardless of the presence of an SRH" it is rather unless there is an SRH with a valid HMAC. Please re-read page 20 (the rest of 6.2.1) and let me know if you still think this is not fully defined. This is clear with Prefix-H and the definition of the SIDs assigned from that prefix. If that is the intention for 6.2, could we please have the text say that. And then upgrade the SHOULD for the edge to a MUST? For the Internal nodes in section 6.2, the SHOULD ought to also reference the HMAC. I can see leaving that as a SHOULD, although I would prefer to see it as a MUST. If after re-reading you still have a concern in this area let me know and we can talk more. Darren Yours, Joel -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected]<mailto:[email protected]> <mailto:[email protected]> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected]<mailto:[email protected]> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
