Subject: Re: 6man issues 62/63/64 - Adrian

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 2 Apr 2019 15:27:59 +0000

Hi Adrian, see inline [ddukes]

> On Mar 27, 2019, at 8:37 PM, Darren Dukes (ddukes) <[email-masked]> wrote:
> 
> I’ll review in the morning, plus one correction... it’s 62/63/64 you’re referring to in this response.
>  
> Darren
>  
> On 2019-03-27, 2:14 PM, "Adrian Farrel" <[email-masked]> wrote:
>  
> Hi Darren,
>  
> Thanks, that’s a lot of changes so must have been a lot of work. Well done.
>  
> I squeezed out some time to look through the latest revision of the draft (benefits of a pedestrian plenary!)
>  
> On the negative side, I had to do a lot of reading to check all the changes.
> One the positive side, this caused me to look at the whole text and find new nits.
>  
> Thanks,
> Adrian
>  
> ===
>  
> Issues #62 and #63 are very nearly done, but a few follow-ups…
>  
> I think you have arrived at “This document considers an SR Domain to be the set of routers through which a packet may transit (including source and destination) while encapsulated for SR.” If that is what you intended, then I think we have achieved convergence on this issue (although maybe making this explicit).

[ddukes] -Yes, nothing more to do here

>  
> --
>  
> I had “You would be well advised to create a registry and assignment rules for the Flags field.” Which you have done, but the Section 2 description of the Flags field should point at 8.1.

[ddukes] - ack
<OLD>
Flags: 8 bits of flags.  Following flags are defined:
</OLD>
<NEW>
Flags: 8 bits of flags.  Section 8.1 creates an IANA registry for new flags to be defined.  The following flags are defined:
</NEW>

>  
> --
>  
> We still have a problem with this one point I raised…
>  
> >> I don't buy paragraphs 2 and 3 of 6.3.3. Inspecting the SRH of a single
> >> packet is quite a different thing from causing a traceroute to enter and
> >> traverse the SR domain. So while you correctly describe how to mitigate
> >> against traceroute, you have not described how to stop SRH inspection.
> >> 
> >> There are three points of note:
> >> 
> >> Packets originating outside the domain and carrying an SRH (if this is
> >> allowed after working on the definitions of "domain") can be inspected
> >> more easily.
> >> 
> >> There is nothing much that can be done to hide the SRH
> >> 
> >> Knowledge of the segments and TLVs (when they are not just routing
> >> instructions) may give away information about the purpose of the
> >> packet and so expose the user's usage patterns.
> >> 
> >> Number 3 may be a real issue and any form of packet snooping can get
> >> at this. It would appear that privacy is the cost of putting end-point
> >> information in a routing header.
> > 
> > Infra ACLs fully defined in deployment section.
>  
> Yes, the ACLs. That covers the first point. Indeed, you used to (possibly) allow the SRH to be present on a packet coming from outside the network. You don’t any more.
> It partly covers the third point, but not fully. It does not cover the second point at all.
>  
> But I’m pretty sure that an ACL does not protect you from snooping on packets. I don’t think much does. That’s OK.
> However, what we need to do is make it clear so that operators understand what they need to worry about.
>  
> It’s just a paragraph like…
>  
> Note that the SRH is transmitted in the clear and cannot be encrypted or otherwise hidden. This means that there are certain vulnerabilities to a network and a service if packets can be snooped because the SRH may expose some elements of the topology of the network. Furthermore, an SRH may reveal more about the traffic flows, usage patterns, and functional purposes of traffic in the networks. 

[ddukes] - how about we add the following to section 7.3 where we talk about Topology disclosure...
<NEW>
Even so, it is worth noting that the SRH is transmitted unencrypted within the SR Domain.  If packets can be snooped within the SR Domain the SRH may reveal more about traffic flows, usage, and functional purpose of traffic within the SR Domain.
</NEW>

> --
>  
> I said…
>  
> >> While it is not mandatory, the inclusion of an RFC 5706 manageability considerations
> >> section in this document would be highly helpful.
>  
> You answered…
>  
> > Removed
>  
> …which is presumably a cut a paste error.
>  
> I think it is a shame that you have chosen to not include a 5706 section. Who knows what the OPS Dir review and IESG will say about it.
>  
> But I don’t think this causes a failure of the WGLC (especially as I am not suggesting text).
>  

[ddukes] - ack
> --
>  
> You said you had moved the 2119 boilerplate, but you appear to have missed doing so.
>  
> You just need to move it into a new section 1.1
>  
> ==

[ddukes] - ack

>  
> New issues
>  
> Section 5.2 first paragraph
>    All intra SR Domain packets are of the SR Domain.  The IP v6 header
>    is originated by a node of the SR Domain, and is destined to a node
>    of the SR Domain.
> 	• That first sentence is almost biblical in its use of language 😊  But (just like some passages in the Bible) I am not sure what it means.
> 	• s/IP v6/IPv6/
> 	• Is there an expectation/requirement about transit nodes in the intra SR Domain case?
>  
> Similar language in the third paragraph
>    As a consequence, any packet within the SR Domain is of the SR
>    Domain.
>  

[ddukes] 5.2 defines what "packets of the SR Domain" means.  

> --
>  
> I think the title of 6.3.3 may be confusing
> 6.3.3.  Inter SR Domain Packet - Internal to External
> This implies that the packet goes between SR Domains. 
> The “Internal to External” is good, the “inter” is the problem
> Maybe use…
> 6.3.3.  Packets that are Exchanged Between Internal and External nodes.
>  

[ddukes] - A packet traversing domains (inter SR Domain), moving from an internal SR Domain node to a node external to the SR domain.  This seems accurate.

> --
>  
> Section 7 has 
>    As describe in Section 5, it is necessary to filter packets ingress
>    to the SR Domain destined to segments within the SR Domain.
> s/describe/described/
> s/ingress/at the ingress/
> s/destined/that are destined/
>  
> This sentence may be hard to parse correctly for people doing the security filtering. The example in 6.3.3 shows a packet coming from outside the SR Domain destined to a node insider the SR Domain (viz. P8). The “subtlety” here is A8 != S8. That is “obvious to one skilled in the art” (as patent reviewers used to say) but might stand “(that is, bearing DA values that identifier segments rather than node or interface addresses)”
>  
[ddukes] fixed the last paragraph of 6.3.3 to indicate this correctly:
<OLD>
    At node 3 P8 is encapsulated for the portion of its journey within
    the SR domain.  Resulting in
    P9: (A3,S8)(A1,A8)
    At node 9 the outer IPv6 header is removed by S6 processing, then processed again when received by A8.
</OLD>
<NEW>
    At node 3 P8 is encapsulated for the portion of its journey within
    the SR domain, with the outer header destined to segment S8.  Resulting in
    P9: (A3,S8)(A1,A8)
    At node 8 the outer IPv6 header is removed by segment S8 processing, then processed again when received by A8.
</NEW>

> --
>  
> Does section 7 (possibly 7.1) need to discuss a “discovered SRH”?
> For example, a packet is sent A1 to A7, it carries another packet (IP-in-IP) that has an SRH.
> Note that the outer header is using A7 not S7.

[ddukes] - Such a node would be an edge of the SR Domain - it is connected to external nodes via the ip tunnel.  The same security rules, via the IACLs, would certainly apply to the ip in ip tunnel interface at node A7.

>  
> --
>  
> 2.1
>    Length: The length of the Variable length data.  It is RECOMMENDED
>    that the total length of new TLVs be multiple of 8 bytes to avoid the
>    use of Padding TLVs.
>  
> This is begging for interop problems. The Length is not the total length of the TLV, so the Length value is not recommended to be a multiple of 8 bytes. I know that what you have said is perfectly accurate, but it is open to misreading.
>  
> So how about…
>    Length: The length of the Variable length data.  It is RECOMMENDED
>    that the total length of new TLVs (i.e., including the Type and Length 
>    fields) be multiple of 8 bytes to avoid the need to use Padding TLVs.
>  
> However, there are two things…
> “RECOMMENDED” in a protocol spec would normally apply to implementers not writers of future specifications.
> If you made this mandatory rather than recommended, you could completely avoid needing the pad TLVs and would make implementation and specification much cleaner. That basically expands to the question (which should be answered in the document if you use SHOULD or RECOMMENDED) “Under what circumstances can this be varied?”
>  

[ddukes] removed the recommendation and added text on alignment requirements (as per other threads with Tom).

> --
>  
> I think the registry in section 8.2 needs to be more clearly documented. As written, if someone just asks IANA for a TLV Type, they will allocated the first available unassigned value which will have the top bit clear. If however, you  split the registry into ranges, then IANA will know to ask “Which range do you want the codepoint from?”  
>  
> Additionally, you do not want IANA to maintain a column called “Suggested Value”!
>  
> So probably…
>  
> OLD
> 8.2.  Segment Routing Header TLVs Register
>  
>    This document requests the creation of a new IANA managed registry to
>    identify SRH TLVs.  The registration procedure is "Expert Review" as
>    defined in [RFC8126].  Suggested registry name is "Segment Routing
>    Header TLVs".  A TLV is identified through an unsigned 8 bit
>    codepoint value.  The following codepoints are defined in this
>    document:
>  
>    Suggested      Description               Reference
>      Value
>    -----------------------------------------------------
>       5           HMAC TLV                  This document
>       128         Pad0 TLV                  This document
>       129         PadN TLV                  This document
> NEW
> 8.2.  Segment Routing Header TLVs Registry
>  
>    This document requests the creation of a new IANA registry to
>    identify SRH TLVs called the “Segment Routing Header TLVs
>    Registry”.   The registration procedure is "Expert Review" as
>    defined in [RFC8126]. A TLV is identified through an unsigned 8
>    bit codepoint value so the valid range is 0 to 255. Two ranges
>    are identified according to the setting of the most significant 
>    bit:
>        Range       Use
>        0-127     Immutable TLVs
>        128-255   Mutable TLVs
>  
>    The following codepoints are defined in this Document. Values
>    shown are suggested for allocation.
>  
>      Value            Description               Reference
>    -----------------------------------------------------
> 	•       Reserved
>       1-4       Unassigned
>       5           HMAC TLV                  This document
>       6-127   Unassigned
>       128         Pad0 TLV                  This document
>       129         PadN TLV                  This document
>       130-255 Unassigned
> END

[ddukes] resolved with the following text and the removal of the chg bit.

<NEW>
   This document requests the creation of a new IANA managed registry to
   identify SRH TLVs.  The registration procedure is "Expert Review" as
   defined in [RFC8126].  Suggested registry name is "Segment Routing Header TLVs".  A TLV is identified through an unsigned 8 bit
   codepoint value, with assigned values 0-255.  The following codepoints are defined in this
   document:
 
   Assigned       Description               Reference
     Value
   -----------------------------------------------------
      0           Pad0 TLV                  This document
      1           PadN TLV                  This document
      5           HMAC TLV                  This document

 </NEW>
>  
> --
>  
> 2.1 has…
>  
>    The following TLVs are defined in this document:
>  
>       Padding TLV
>  
>       HMAC TLV
>  
>    Additional TLVs may be defined in the future.
>  
> 2.1.1.  Padding TLVs
>  
>    There are two types of padding TLVs, pad0 and padN
>  
>  
> That jars: maybe s/Padding TLV/Padding TLVs/

[ddukes] - fixed

>  
> --
>  
> 2.1.1.2 and 82.
> Why is PadN immutable? Couldn’t it change if another TLV changes?
>  

[ddukes] removed immutability description.

> --
>  
> I found “TLV's” where you mean “TLVs”
> Maybe a global search for apostrophe.

[ddukes] done.

>  
>  
>  
> From: Darren Dukes (ddukes) <[email-masked]> 
> Sent: 26 March 2019 23:31
> To: Adrian Farrel <[email-masked]>
> Subject: 6man issues
>  
> Hi Adrian, I have two issues from you on Issue tracker I believe they are both solved some time ago:
> Issue #62 MUST language – I believe the latest drafts resolved this for quite some time.
> Issue #64 Various – We walked over these in the summer, the doc we reviewed is attached.  all are closed in rev 17.
>  
> Can you ACK please?
>  
> BTW I’m still thinking about your IPv6 addressing question.
>  
> Thanks!
>   Darren

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 2 Apr 2019 16:48:38 +0100

Thanks Darren,

Trimmed.

[ddukes] - ack
<OLD>

OK. Good.

WFM
Thanks

[ddukes] - ack

Perfect

I am trying to not be difficult! 😊
But 5.2 has
   All intra SR Domain packets are of the SR Domain.  The IP v6 header
   is originated by a node of the SR Domain, and is destined to a node
   of the SR Domain.
   :
   :
   As a consequence, any packet within the SR Domain is of the SR
   Domain.

I believe the text says that:
- any packet bearing an SRH has been originated in the domain or
  encapsulated at the domain boundary
- any packet not carrying an SRH but seen inside the domain has
  been originated within and will terminate within the domain

This is important if you consider migration where SRH is only used when SR is actually needed.

(Otherwise you are saying "any packet seen in the domain is a packet seen in the domain".)

Sorry, but inter-domain means between domains.
You are describing crossing the domain boundary.

Well, I see you didn't like my suggestion although didn't say why not.
Anyway, your fix is important!

What you say is somewhat true, but it is not obvious that *every* node is thus an edge node (since IP-in-IP does not need to be configured as an interface even if wise people do that).

OK

<NEW>

 </NEW>

Oh. The chg bit went. I missed that!
What you have is OK.

Looking forward to -18

Thanks,
Adrian

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 2 Apr 2019 16:13:42 +0000

Trimmed what we agree on, See [ddukes2]

> On Apr 2, 2019, at 11:48 AM, Adrian Farrel <[email-masked]> wrote:
> 
> Thanks Darren,
> 
> Trimmed.
> 
> 
>> New issues
>> 

[ddukes2] well how do you cross a domain boundary unless you are moving from one domain to another? If I travel from domain Canada to domain USA I cross a boundary where an ACL (people with guns) make sure I only enter if permitted.  If I never cross that boundary I never move between domains.

> Anyway, your fix is important!

[ddukes2] Is this what you are proposing?
<OLD>
  As describe in Section 5, it is necessary to filter packets ingress
  to the SR Domain destined to segments within the SR Domain.
</OLD>
<NEW>
  As describe in Section 5, it is necessary to filter packets ingress
  to the SR Domain destined to segments within the SR Domain (i.e., bearing DA values that identify segments rather than node or interface addresses).
</NEW>

> What you say is somewhat true, but it is not obvious that *every* node is thus an edge node (since IP-in-IP does not need to be configured as an interface even if wise people do that).

[ddukes2] Whether or not the ip in ip tunnel endpoint is instantiated as an interface, the same iACL would apply to this edge of the domain.  Since no administrator permits unrestricted ip-in-ip tunnel termination on every node in their network, I think it is obvious to any network operator which nodes are edge nodes of their SR domain.

Darren

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 4 Apr 2019 22:00:13 +0100

Continued progress. Thanks!

> (Otherwise you are saying "any packet seen in the domain is a packet seen in the domain".)

No answer on this?

Oh! Semantics.
How do you distinguish "traffic from one SR domain to another SR domain" from "traffic from a non-SR source to an SR domain"?

The former is what I see as "inter". I.e. "between" domains.
The latter is "crossing the domain border".

Hence my suggested change.

That's it. Thanks.

So...
"It is assumed that SR nodes within the SR domain will apply IACLs to IP-in-IP and other tunnels so that packets containing an SRH cannot enter the domain."

Best,
Adrian