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

[Andrew Alston - IETF <[e-mail]>]

Hi Adrian (and Joel since I will respond to both in one email)

Thanks for the comments and detailed review – its hugely appreciated.  The authors are looking at these comments and will hopefully be pushing out a -01 draft in the next 24 hours, this will aim to address many of the nits and Joel’s comments in one update.

On your first comment regarding a protocol number.  Keep in mind that should a node be designed as using TD-SRv6, effectively what will happen is that on decapsulation of the tunnel, srv6 processing would not actually occur, since on a node enabled for td-srv6 srv6 processing will only happen on packets that contain the new ethertype.

This does however need some thought as to how to enable srv6 processing of traffic inbound on a particular tunnel mechanism, and that may be best handled in subsequent drafts relating to the specific tunnel types, such that traffic coming in across a particular tunnel will be processed as srv6 traffic on a td-srv6 enabled node.  I would suggest that we detail this case in the draft with an explicit note that srv6 tunneled traffic need to be handled by mechanisms out of scope of this draft.  An example of this would be in GRE – which may need a separate draft with an additional code point to tag inbound traffic for SRv6 processing.

With regards to traffic being sent using another ethertype – I think the draft needs to be more explicit that traffic with a DA of a SID will not be treated as SRv6 absent the specified ethertype – it will be treated and handled as standard IPv6.  As such the security issue we are aiming to address will be not triggered by this particular case.  We will add some text to this effect.

I also agree with Joel’s two comments and we will address that in the -01 as well

Thanks

Andrew


From: Adrian Farrel <[e-mail]>
Date: Tuesday, 28 March 2023 at 11:24
To: Andrew Alston - IETF <[e-mail]>, [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: RE: [Int-area] FW: New Version Notification for draft-raviolli-intarea-trusted-domain-srv6-00.txt
[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-00.txt<https://www.ietf.org/archive/id/draft-raviolli-intarea-trusted-domain-srv6-00.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<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


Internal All Employees