Subject: SRv6 revision: edge behavior minor description issue

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 22 Oct 2018 18:59:25 -0400

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.

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.

Yours,
Joel

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Mon, 22 Oct 2018 23:45:50 +0000

Thanks Joel, please see inline.

> On Oct 22, 2018, at 6:59 PM, Joel M. Halpern <[email-masked]> 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-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 22 Oct 2018 19:52:43 -0400

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

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

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 23 Oct 2018 00:28:48 +0000

On Oct 22, 2018, at 7:52 PM, Joel M. Halpern <[email-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>> wrote:

Yours,
Joel

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 22 Oct 2018 20:39:01 -0400

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:
>> 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,
> 
>   “...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.
> 
>> 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
>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> [email-masked] <mailto:[email-masked]>

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Fri, 26 Oct 2018 17:45:48 +0000

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
   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
   segment lists.
</quote>

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-masked]<mailto:[email-masked]>> wrote:

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-masked]<mailto:[email-masked]> <mailto:[email-masked]>> wrote:

 “...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>*"

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-masked]<mailto:[email-masked]> <mailto:[email-masked]>> wrote:

Yours,
Joel

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

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Fri, 26 Oct 2018 18:22:45 +0000

+spring

<quote>

Darren

Yours,
Joel

Yours,
Joel

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 26 Oct 2018 14:31:12 -0400

While I would prefer an explicit enumeration of cases, I think your 
proposed text likely fixes the specific problem.

Yours,
Joel

On 10/26/18 2:22 PM, Darren Dukes (ddukes) wrote:
> 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
> 
> 
>> 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.
>>
>> 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.
>>
>>>> On Oct 22, 2018, at 7:52 PM, Joel M. Halpern <[email-masked] 
>>>> <mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>>>>
>>> *<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 
>>> 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.
>>>>
>>>> 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 Oct 22, 2018, at 6:59 PM, Joel M. Halpern <[email-masked] 
>>>>>> <mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>>>>>>
>>>>>> 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.
>>>>>> 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?
>>>>>> reference the HMAC.  I can see leaving that as a SHOULD, although 
>>>>>> I would prefer to see it as a MUST.
>>>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>