Subject: draft-ietf-6man-segment-routing-header-15

From: Ron Bonica <[email-masked]>
Date: Thu, 1 Nov 2018 18:43:37 +0000

Folks,

This version looks much better. Thanks for posting it. 

The following are a few comments that I am sure can be fixed easily:

Major Issues:

-  In Section 2.1.2.1, did you really mean to say that the HMAC is calculate over the Segments Left field? Given that Segments Left is mutable, what value should be used?

- In Section 4.3.1.2, there may be a sentence missing. Under what conditions should the ICMP Parameter Problem message be sent?

- RFC 4302 says, "As a new extension header or IPv4 option is created, it will be defined in its own RFC and SHOULD include (in the Security Considerations section) directions for how it should be handled when calculating the AH ICV."

I think that this requirement can be satisfied with a very short section that contains three bullets lists. The bullet lists would say which SRH fields are mutable, predictably mutable, and immutable. (These words are associated with processing rule in RFC 4203.)

Minor Issues:

- The draft doesn't tell the reader what to do when the receive a non-zero tag field. In fact, the document says, "The allocation and use of tag is outside the scope of this document."

I think that we need to either define the tag field or take it out of this document.

- Same argument for the Flags field.

                                                                              Ron

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Mon, 5 Nov 2018 22:06:56 +0000

Inline

On Nov 1, 2018, at 2:43 PM, Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:

Folks,

Major Issues:

-  In Section 2.1.2.1, did you really mean to say that the HMAC is calculate over the Segments Left field? Given that Segments Left is mutable, what value should be used?
No, John Leddy also caught this right after we submitted it.  It’s fixed in revision 16 as suggested in August on the list - check segments list [segments left] == destination address as part of HMAC processing

Like: "When processing the Upper-layer header of a FIB entry locally instantiated as an SRv6 SID.”?  Did you have something else in mind?

- RFC 4302 says, "As a new extension header or IPv4 option is created, it will be defined in its own RFC and SHOULD include (in the Security Considerations section) directions for how it should be handled when calculating the AH ICV.”
OK, I prefer to update this with the TLV text in the draft. But the following should be a good start to get comments from WG members on the list.

For the purpose of AH ICV calculation the SRH fields are as defined
Mutable: Optional TLV objects as defined per TLV

Mutable but predictable: segments left,

Immutable: next header, hdr ext len, routing type, flags, tag, segment list

Minor Issues:

Yes, there is an open item for this and it’s tracked for definition.

                                                                             Ron

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

---

From: Ron Bonica <[email-masked]>
Date: Tue, 13 Nov 2018 16:06:16 +0000

Hi Darren,

I’m not sure what you meant to say in Section 4.3.1.2.

Section 4.3.1 tells us how to process a packet when the FIB entry is a locally instantiated END SID
Section 4.3.1.1 tells us how to process the SRH inside of the packet
Section 4.3.1.1.1 tells us how to process the TLVs inside of the SRH

So far, so good. We have processed the entire IPv6 extension header chain.

Now, Section 4.3.1.2 tells us how to process “The Upper-layer Header or No Next Header”. Surprisingly, it tells us to send an ICMP Parameter Problem message to the source in all cases. It is silent regarding whether the packet should be forwarded or dropped.

Did you mean to say that the packet should be dropped if there is no next header?

Also, if Segments Left is “mutable but predictable”, what value should be used. If we assume the normal variant, it is the number of segments minus one. If it is the reduced variant, it is the number of segments.

                                                                  Ron

From: Darren Dukes (ddukes) <[email-masked]>
Sent: Monday, November 5, 2018 5:07 PM
To: Ron Bonica <[email-masked]>
Cc: IPv6 List <[email-masked]>
Subject: Re: draft-ietf-6man-segment-routing-header-15

Inline

Folks,

Major Issues:

Minor Issues:

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 14 Nov 2018 16:35:28 +0000

Hi Ron

Hopefully this clarifies things..

When an SRH is processed (4.3.1.1) we either perform a lookup and forward the packet or walk on to process the next header
When we reach an upper-layer header or find there is no next header (4.3.1.2) it tells us we discard the packet and send an ICMP error.  This is fully defined (i.e. it’s not silent on discarding or not)

However I do see that there is a bug in that section 4.3.1.2, it does not tell us to perform decapsulation when the upper-layer header is IP (as required in 5.3.2)
To solve that we’ll be adding text to that section in the next update to do the following when next header is IP and local policy permits:
1 - Perform decapsulation
2 - Resubmit the inner packet for destination lookup and forwarding.

For Segments Left, remember “predictable” means as received at the node verifying the AH.  If the node verifying the AH header is the last segment in the segment list then Segments Left would be predicted to be 0 during pseudo header creation and ICV calculation at source.

Darren

On Nov 13, 2018, at 11:06 AM, Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:

Hi Darren,

                                                                  Ron

From: Darren Dukes (ddukes) <[email-masked]<mailto:[email-masked]>>
Sent: Monday, November 5, 2018 5:07 PM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: IPv6 List <[email-masked]<mailto:[email-masked]>>
Subject: Re: draft-ietf-6man-segment-routing-header-15

Inline

Folks,

Major Issues:

Minor Issues:

---

From: Ron Bonica <[email-masked]>
Date: Wed, 14 Nov 2018 20:25:49 +0000

Hi Darren,

Inline…..

Sent: Wednesday, November 14, 2018 11:35 AM

Hi Ron

Now I see what you are saying. But I think that the fix is much simpler than you think.

In Section 4.3.1.1, you have a clause that tells you what to do if Segments Left equals 0. That clause could be strengthened with a pointer to Section 4.3.1.2.

Section 4.3.1.2 should be renamed to “Next Header Processing”. In this section, the IP layer always processes the next header exactly as it would if the packet didn’t include an SRH. For example,

-         If there is no next header, discard the packet and send an ICMP message to the source

-         If the next header is a Destination Options header, process the Destination Options

-         If the next header is a TCP header, submit the packet to TCP

-         If the next header is an IP header, pop the outer header and submit the remaining header to the IP layer for routing

Yes, I realize that this formulation only works when the final member of the Segment List is an IP address. But that is the only problem we are solving today.

You are correct. RFC 4302 is talking about “predictable upon arrival”, not “predictable at the time of transmission”. So the predictable value is zero. This is exactly the same value that would be used if you said that the field was mutable.

Darren

Hi Darren,

                                                                  Ron

Inline

Folks,

Major Issues:

Minor Issues:

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
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=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=hfZoBnFS3uf7FZoOfUGbm1Ad60Lb17JVUSQcAXE7uQA&s=oRo_65_mzmxzV9mR5UFe0oEh6hMEyJ6f4WMJlrRCiNw&e=>
--------------------------------------------------------------------

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 14 Nov 2018 15:35:24 -0500

As I read the text, specific nodes under specific circumstances are 
required to verify the HMAC.

In the typical construction from a trusted external node to a first 
verifying node, the verifying node knows what the "segments-left" should 
be at the verifying node.  So far, all good.

I did not see anything prohibiting other nodes from attempting to verify 
the HMAC, and discard the packet if it fails.  This can easily happen, 
for example if we have two nodes which serve as first-HMAC-verifier for 
external sources are both in the sequence of SIDs for TE reasons.
In that situation, the second verifier will not see the correct 
segments-left value, and will drop the packet.

Yours,
Joel

On 11/14/18 3:25 PM, Ron Bonica wrote:
> Hi Darren,
> 
> Inline…..
> 
> *From:*Darren Dukes (ddukes) <[email-masked]>
> *Sent:* Wednesday, November 14, 2018 11:35 AM
> *To:* Ron Bonica <[email-masked]>
> *Cc:* IPv6 List <[email-masked]>
> *Subject:* Re: draft-ietf-6man-segment-routing-header-15
> 
> Hi Ron
> 
> When an SRH is processed (4.3.1.1) we either perform a lookup and 
> forward the packet or walk on to process the next header
> 
> When we reach an upper-layer header or find there is no next header 
> (4.3.1.2) it tells us we discard the packet and send an ICMP error. 
>   This is fully defined (i.e. it’s not silent on discarding or not)
> 
> However I do see that there is a bug in that section 4.3.1.2, it does 
> not tell us to perform decapsulation when the upper-layer header is IP 
> (as required in 5.3.2)
> 
> To solve that we’ll be adding text to that section in the next update to 
> do the following when next header is IP and local policy permits:
> 
> In Section 4.3.1.1, you have a clause that tells you what to do if 
> Segments Left equals 0. That clause could be strengthened with a pointer 
> to Section 4.3.1.2.
> 
> Section 4.3.1.2 should be renamed to “Next Header Processing”. In this 
> section, the IP layer always processes the next header exactly as it 
> would if the packet didn’t include an SRH. For example,
> 
> -If there is no next header, discard the packet and send an ICMP message 
> to the source
> 
> -If the next header is a Destination Options header, process the 
> Destination Options
> 
> -If the next header is a TCP header, submit the packet to TCP
> 
> -If the next header is an IP header, pop the outer header and submit the 
> remaining header to the IP layer for routing
> 
> Yes, I realize that this formulation only works when the final member of 
> the Segment List is an IP address. But that is the only problem we are 
> solving today.
> 
> For Segments Left, remember “predictable” means as received at the node 
> verifying the AH.  If the node verifying the AH header is the last 
> segment in the segment list then Segments Left would be predicted to be 
> 0 during pseudo header creation and ICV calculation at source.
> 
> You are correct. RFC 4302 is talking about “predictable upon arrival”, 
> not “predictable at the time of transmission”. So the predictable value 
> is zero. This is exactly the same value that would be used if you said 
> that the field was mutable.
> 
> Darren
> 
>     Now, Section 4.3.1.2 tells us how to process “The Upper-layer Header
>     or No Next Header”. Surprisingly, it tells us to send an ICMP
>     Parameter Problem message to the source in all cases. It is silent
>     regarding whether the packet should be forwarded or dropped.
> 
>     Also, if Segments Left is “mutable but predictable”, what value
>     should be used. If we assume the normal variant, it is the number of
>     segments minus one. If it is the reduced variant, it is the number
>     of segments.
> 
>                                                                        Ron
> 
>     *From:*Darren Dukes (ddukes) <[email-masked]
>     <mailto:[email-masked]>>
>     *Sent:*Monday, November 5, 2018 5:07 PM
>     *To:*Ron Bonica <[email-masked] <mailto:[email-masked]>>
>     *Cc:*IPv6 List <[email-masked] <mailto:[email-masked]>>
>     *Subject:*Re: draft-ietf-6man-segment-routing-header-15
> 
>     Inline
> 
> 
> 
> 
>         -  In Section 2.1.2.1, did you really mean to say that the HMAC
>         is calculate over the Segments Left field? Given that Segments
>         Left is mutable, what value should be used?
> 
>     No, John Leddy also caught this right after we submitted it.  It’s
>     fixed in revision 16 as suggested in August on the list - check
>     segments list [segments left] == destination address as part of HMAC
>     processing
> 
> 
> 
> 
> 
>         - In Section 4.3.1.2, there may be a sentence missing. Under
>         what conditions should the ICMP Parameter Problem message be sent?
> 
>     Like: "When processing the Upper-layer header of a FIB entry locally
>     instantiated as an SRv6 SID.”?  Did you have something else in mind?
> 
> 
> 
> 
> 
>         - RFC 4302 says, "As a new extension header or IPv4 option is
>         created, it will be defined in its own RFC and SHOULD include
>         (in the Security Considerations section) directions for how it
>         should be handled when calculating the AH ICV.”
> 
>     OK, I prefer to update this with the TLV text in the draft. But the
>     following should be a good start to get comments from WG members on
>     the list.
> 
>     *Mutable*: Optional TLV objects as defined per TLV
> 
>     *Mutable but predictable:*segments left,
> 
>     *Immutable:* next header, hdr ext len, routing type, flags, tag,
>     segment list
> 
> 
> 
> 
> 
>         I think that this requirement can be satisfied with a very short
>         section that contains three bullets lists. The bullet lists
>         would say which SRH fields are mutable, predictably mutable, and
>         immutable. (These words are associated with processing rule in
>         RFC 4203.)
> 
>         Minor Issues:
> 
>         - The draft doesn't tell the reader what to do when the receive
>         a non-zero tag field. In fact, the document says, "The
>         allocation and use of tag is outside the scope of this document."
> 
>         [email-masked] <mailto:[email-masked]>
>         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=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=hfZoBnFS3uf7FZoOfUGbm1Ad60Lb17JVUSQcAXE7uQA&s=oRo_65_mzmxzV9mR5UFe0oEh6hMEyJ6f4WMJlrRCiNw&e=>
> [email-masked]