Re: [spring] [Int-area] FW: New Version Notification for draft-raviolli-intarea-trusted-domain-srv6-00.txt

[Adrian Farrel <[e-mail]>]

[Spring cc'ed because, well, you know, SR. I wonder whether 6man and 6ops
should care as well.]

 

tl;dr

I think this is a good initiative and worth discussion. Thanks

for the draft.

 

I am particularly reminded of two MPLS-related discussions: 

- The first was the introduction of Ethertype 8848 for MPLS

  source-assigned labels. This is a good example of a protocol

  variant/extension using a different Ethertype in order to 

  facilitate easy distinction between data packets.

- The second was the discussion of using a different Ethertype

  for T-MPLS when the early proposals for what became MPLS-TP

  were sufficiently different to base MPLS that there were 

  concerns about interop and leakage problems. In the end, a 

  new Ethertype was now assigned because the protocol was 

  modified in a way that made it safe to coexist with MPLS.

 

In my comments below, I call out one point which is important

enough to feature up here. I think you also need a new IP protocol

number to handle "discovered SR". That is, if an SR packet is

encapsulated in an IP header, it is important that it is clear

that the payload is an SR packet (otherwise, I can tunnel SR into

the middle of your network representing it as native IP).

 

I would note that this Ethertype solution, and my proposed new

IP protocol number are not "secure" solutions. That is, for example,

an SR packet could still be sent using 86DD and the receiver will not

know the difference unless they dig for the SRH and then complain

about it. So while this document can require or recommend the use of

a new Ethertype, making this a security feature would still require

"edge" nodes to inspect packet contents of everything coming in as 

86DD. Of course, using a new Ethertype *will* help considerably with

misconfiguration and accidents.

 

Cheers,

Adrian

 

==Nitz and Discuzzion==

 

Please use the correct BCP 14 boilerplate

 

---

 

This document does not specify a "standard". Maybe move to "This

document specifies a solution..."

 

---

 

Why "Fail-Closed Protocol (FPC):" and not FCP?

 

---

 

Abstract and Introduction have "known security problems", but section 3

is "The SRv6 Security Problem" in the singular.

 

---

 

3.

 

   SRv6 relies in its architecture on the concept of limited domain

   which as a concept suffers from lack of security that is deployable

   in economical, scalable fashion easily.

 

I think it would be helpful to reference the definition of "Segment

Routing domain (SR domain)" in 8402 section 2.

 

---

 

3.

 

   The proper solution is to create a trusted domain that has a default

   fail-closed approach and a well-defined trusted/untrusted boundary.

 

I wonder whether "the proper solution" is a little strong and likely to 

cause undue debate. Perhaps "An established and proven solution..."

 

---

 

3.

 

I think that a valuable example to add to your list is "MPLS with 

upstream-assigned label" because this is exactly an example of an

extended use of an established protocol that significantly benefited 

from the use of a different Ethertype. 

 

Further, your list might be better if restricted to IETF protocols.

Perhaps add Trill (there are at least 3 Ethertypes) and PPP, but leave

out LLDP (IEEE) and CLNS (not got an Ethertype at all?)

 

---

 

"fail closed protocol domain"

 

Please be consistent with capitalisation and hyphenation.

Please decide "fail-closed domain" or "fail-closed protocol domain". 

 

Ditto "fail-closed protocol"

 

---

 

4. 

 

   Processing of the protocol packet on an interface requires explicit

   configuration with a default drop behavior.

 

Somewhere (6.1?) you need to state (with a reference) that the correct 

default behavior for an unknown/unsupported Ethertype is packet (frame)

drop. It would clearly be a bad solution if the processing required a

marching band and streamers.

 

---

 

4.

 

   Leaking according protocol packets beyond the boundary of fail-closed

   domain requires explicit config.

 

Cannot reliably parse.

 

---

 

4.

 

   Fail closed protocols are easily identifiable by their top level

   (e.g. link layer) encoding early in the packet formats and often by

   fields at fixed offset.

 

"Top level encoding" is perhaps not as clear as "outer encapsulation"

 

---

 

4.

 

   Classification of the protocol packets is completely deterministic.

 

This voice is passive. Who is doing the classification?

 

---

 

5.  SRv6 in the context of a trusted domain - an objective analysis

 

You saying other analysis work is not objective? ;-)

 

---

 

5.

 

   It is currently impossible to differentiate SRv6 and IPv6 at the

   link-layer or easily at network layer by e.g. a reserved protocol

   number as IPSec does.

 

"Currently" is not survivable language because, if this document becomes

an RFC it will no longer be true.

 

This is a somewhat confusing (to me) paragraph. Are you referring to the

ESP and AH assigned protocol numbers? I don't think there is a separate

Ethertype for IPsec (although I may be wrong). So it is possible you are

comparing and contrasting Ethertype with "next protocol" which is not

quite a fair comparison. Indeed, using a new protocol number for SR 

would not solve the problem because it is the outer IP encapsulation 

that is what matters. (Although, if you go ahead with this, you also

need to think about "SR-in-IP" encapsulations, so you *do* need to also

assign a new protocol number to handle "discovered SR".

 

---

 

I wish 7.2 had a few more words! And maybe somewhere else in the

document should observe that IEEE manages the Ethertype registry.

 

"TBD0" is not mentioned anywhere in the document. It should be.

 

From: Int-area <[e-mail]> On Behalf Of Andrew Alston - IETF
Sent: 27 March 2023 00:17
To: [e-mail]
Subject: [Int-area] FW: New Version Notification for
draft-raviolli-intarea-trusted-domain-srv6-00.txt

 

Hi All,

 

This is just a notification of publication of the -00 draft referred to in
the subject.

 

We, as the authors, welcome any discussions around this draft and look
forward to receiving feedback from the working group.

 

Thanks

 

Andrew.

 

 

 

Subject: New Version Notification for
draft-raviolli-intarea-trusted-domain-srv6-00.txt


A new version of I-D, draft-raviolli-intarea-trusted-domain-srv6-00.txt
has been successfully submitted by Andrew Alston and posted to the
IETF repository.

Name: draft-raviolli-intarea-trusted-domain-srv6
Revision: 00
Title: Trusted Domain SRv6
Document date: 2023-03-26
Group: Individual Submission
Pages: 6
URL:
https://www.ietf.org/archive/id/draft-raviolli-intarea-trusted-domain-srv6-0
0.txt
Status:
https://datatracker.ietf.org/doc/draft-raviolli-intarea-trusted-domain-srv6/
<https://datatracker.ietf.org/doc/draft-raviolli-intarea-trusted-domain-srv6
> 
Htmlized:
https://datatracker.ietf.org/doc/html/draft-raviolli-intarea-trusted-domain-
srv6


Abstract:
SRv6 as designed has evoked interest from various parties, though its
deployment is being limited by known security problems in its
architecture. This document specifies a standard to create a
solution that closes some of the major security concerns, while
retaining the basis of the SRv6 protocol.





The IETF Secretariat

 

Internal All Employees