Subject: RE: 6man issues

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 27 Mar 2019 18:14:07 -0000

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

--

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.

--

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. 

--

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

--

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

==

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.

--

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.

--

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)”

--

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.

--

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?”

--

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

   -----------------------------------------------------

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

--

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/

--

2.1.1.2 and 82.

Why is PadN immutable? Couldn’t it change if another TLV changes?

--

I found “TLV's” where you mean “TLVs”

Maybe a global search for apostrophe.

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