[Pals] Re: RtgDir Last Call review: draft-ietf-pals-ple
"Andrew G. Malis" <[email protected]> Sun, 16 Jun 2024 09:25:46 -0400
| Newsgroups | gmane.ietf.pwe3 |
|---|---|
| Message-ID | <CAA=duU2RRYTU4bZMjGKUq06a0RzAtxFzjWO=ZSUVsXWuQkpPoA@mail.gmail.com> |
--===============2974609163820782941==
Content-Type: multipart/alternative; boundary="000000000000464bdb061b01cac2"
--000000000000464bdb061b01cac2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Tal,
Thanks again for your review and also reviewing Christian's reply.
I'm concerned regarding your suggestion that
draft-filsfils-spring-net-pgm-extension-srv6-usid be made a normative
reference, as it is only an individual draft right now and there's no
guarantee that it'll even become a WG draft, never mind an RFC, and making
it a normative reference would hold up publishing this draft for quite a
while, unless we get special dispensation from the IESG. Do you see any way
we can get around making draft-filsfils normative?
I'm much less concerned regarding draft-ietf-spring-srv6-srh-compression,
as that is currently in WG last call.
Thanks again,
Andy
On Sun, Jun 16, 2024 at 1:12=E2=80=AFAM Tal Mizrahi <tal.mizrahi.phd@gmail.=
com>
wrote:
> Hi Christian and authors,
>
> Thanks for considering my comments.
> The changes you suggested make sense to me.
>
> Regarding the new endpoint behaviors, please note:
> - The IANA section will need to be updated accordingly.
> - You may need to move the references to normative: {{?RFC8986}},
> {{?I-D.draft-ietf-spring-srv6-srh-compression}},
> {{?I-D.draft-filsfils-spring-net-pgm-extension-srv6-usid}}.
> Specifically the last two, which may still be subject to changes.
>
> Cheers,
> Tal.
>
> On Sat, Jun 8, 2024 at 12:16=E2=80=AFPM Christian Schmutzer (cschmutz)
> <[email protected]> wrote:
> >
> > Hi Tal,
> >
> > Sorry for taking so long. Below our comments and proposal for addressin=
g
> your issues.
> >
> > Can you please let us know your thoughts. Upon your feedback we will
> work towards uploading a new version addressing the issues.
> >
> > regards
> > Christian
> >
> > On 15.05.2024, at 01:20, Tal Mizrahi <[email protected]> wrote:
> >
> > Hello,
> >
> > I have been selected as the Routing Directorate reviewer for this
> > draft. The Routing Directorate seeks to review all routing or
> > routing-related drafts as they pass through IETF last call and IESG
> > review, and sometimes on special request. The purpose of the review is
> > to provide assistance to the Routing ADs. For more information about
> > the Routing Directorate, please see
> > https://wiki.ietf.org/en/group/rtg/RtgDir
> >
> > Document: draft-ietf-pals-ple-04
> > Reviewer: Tal Mizrahi
> > Intended Status: Standards Track
> >
> > Summary:
> > I have some concerns about this document that I think should be
> > resolved before publication.
> >
> > The draft is well-written and clear from a grammatical and structural
> > perspective. However, there is a very long list of normative
> > references that are cited in almost every paragraph of the document,
> > making it very difficult to follow for a reader who is somewhat
> > familiar with the area but is not an expert in the area.
> >
> >
> > [cs]
> > PLE has a lot of similarities with RFC 4553 and other referenced
> specifications. We felt references are better as it avoids duplication of
> text across documents, but I see your point. We will work through the
> document and add a bit more text / context before calling out a RFC
> reference.
> >
> > Here an example from the introduction section. Will do something simila=
r
> for other sections.
> >
> > before:
> >
> > The mechanisms described in this document follow principals similar to
> [RFC4553] but expanding the applicability beyond the narrow set of PDH
> interfaces (T1, E1, T3 and E3) and allow the transport of signals from ma=
ny
> different technologies such as Ethernet, Fibre Channel, SONET/SDH
> [GR253]/[G.707] and OTN [G.709] at gigabit speeds by treating them as
> bit-stream payload defined in sections 3.3.3 and 3.3.4 of [RFC3985].
> >
> >
> > after:
> >
> > The mechanisms described in this document follow principles similar to
> Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)
> defined in [RFC4553]. The the applicability is expanded beyond the narrow
> set of PDH interfaces (T1, E1, T3 and E3) to allow the transport of signa=
ls
> from many different technologies such as Ethernet, Fibre Channel, SONET/S=
DH
> [GR253]/[G.707] and OTN [G.709] at gigabit speeds. The signals are treate=
d
> as bit-stream payload which was defined in the Pseudo Wire Emulation
> Edge-to-Edge (PWE3) architecture in [RFC3985] sections 3.3.3 and 3.3.4.
> >
> >
> > Where applicable we will remove the reference and just have appropriate
> text. Once example
> >
> > before:
> >
> > Similar to [RFC4553] and [RFC5086] the term Interworking Function (IWF)
> is used to describe the functional block that encapsulates bit streams in=
to
> PLE packets and in the reverse direction decapsulates PLE packets and
> reconstructs bit streams.
> >
> >
> > after:
> >
> > The term Interworking Function (IWF) is used to describe the functional
> block that encapsulates bit streams into PLE packets and in the reverse
> direction decapsulates PLE packets and reconstructs bit streams.
> >
> >
> >
> > Issues:
> > - The target audience of the document should be clarified, preferably
> > in the abstract. On a related note, throughout the document it is a
> > bit difficult to distinguish between requirements defined for
> > operators vs. requirements defined for implementers. Perhaps the
> > authors could give some thought as to whether this issue can be
> > mitigated.
> >
> >
> > [cs]
> > the target audience is implementers. We adjusted the abstract to reflec=
t
> that
> >
> > before:
> >
> > This document describes a method for encapsulating high-speed
> bit-streams as virtual private wire services (VPWS) over packet switched
> networks (PSN) providing complete signal transport transparency.
> >
> >
> > after:
> >
> > This document describes methods and requirements for implementing the
> encapsulation of high-speed bit-streams into virtual private wire service=
s
> (VPWS) over packet switched networks (PSN) providing complete signal
> transport transparency.
> >
> >
> > - The security considerations should be more detailed. The cited
> > references are a good start, but the following issues should also be
> > discussed:
> >
> > - The requirement for synchronization is potentially a
> > vulnerability. An on-path attacker may compromise the synchronization,
> > and thus compromise the service. You may want to take a look at RFC
> > 7384.
> >
> > - The requirements for low jitter, low loss and bandwidth
> > reservation (section 8) are also potentially an attack vector. You may
> > take a look at RFC 9055 for example.
> >
> >
> > [cs]
> > We have added a couple of sentences to provide more details, plus
> referred to respective RFCs for more information
> >
> > before:
> >
> > As PLE is leveraging VPWS as transport mechanism the security
> considerations described in [RFC7432] and [RFC3985] are applicable.
> >
> >
> >
> > after:
> >
> > As PLE is leveraging VPWS as transport mechanism the security
> considerations described in [RFC7432] and [RFC3985] are applicable.
> >
> > PLE does not enhance or detract from the security performance of the
> underlying PSN. It relies upon the PSN mechanisms for encryption,
> integrity, and authentication whenever required.
> >
> > A data plane attack may force PLE packets to be dropped, re-ordered or
> delayed beyond the limit of the CE-bound IWF's dejitter buffer leading to
> either degradation or service disruption. Considerations outlined in
> [RFC9055] are a good reference.
> >
> > Clock synchronization leveraging PTP is sensitive to Packet Delay
> Variation (PDV) and vulnerable to various threads and attacked vectors.
> Considerations outlined in [RFC7384] should be taken into account.
> >
> >
> >
> > - The following two endpoint behaviors are defined in the IANA
> > considerations section, but not defined anywhere in the document.
> > These endpoint behaviors should either be removed or specified in
> > detail:
> > End.DX1 with NEXT-CSID
> > End.DX1 with REPLACE-CSID
> >
> >
> > [cs]
> > Good point and I realised we have also forgotten to add the required
> encaps description. We have reworded this section as follows (in markdown
> syntax)
> >
> > When a SRv6 PSN layer is used, a SRv6 service SID does provide the
> demultiplexing mechanism and the mechanisms defined in {{?RFC8402}} and
> {{?RFC9252}} section 6 do apply. Both SRv6 service SIDs with the full IPv=
6
> address format defined in {{?RFC8986}} and compressed SIDs (C-SIDs) with
> format defined in {{?I-D.draft-ietf-spring-srv6-srh-compression}} can be
> used.
> >
> > Two new encapsulation behaviors H.Encaps.L1 and H.Encaps.L1.Red are
> defined in this document. The behavior procedures are applicable to both
> SIDs and C-SIDs.
> >
> > The H.Encaps.L1 behavior encapsulates a frame received from an IWF in a
> IPv6 packet with an SRH. The received frame becomes the payload of the ne=
w
> IPv6 packet.
> >
> > * The next header field of the SRH MUST be set to TBA1.
> >
> > * The push of the SRH MAY be omitted when the SRv6 policy only contains
> one segment.
> >
> > The H.Encaps.L1.Red behavior is an optimization of the H.Encaps.L1
> behavior.
> >
> > * H.Encaps.L1.Red reduces the length of the SRH by excluding the first
> SID in the SRH of the pushed IPv6 header. The first SID is only placed in
> the destination address field of the pushed IPv6 header.
> >
> > * The push of the SRH MAY be omitted when the SRv6 policy only contains
> one segment.
> >
> > Three new "Endpoint with decapsulation and bit-stream cross-connect"
> behaviors called End.DX1, End.DX1 with NEXT-CSID and End.DX1 with
> REPLACE-CSID are defined in this document.
> >
> > These new behaviors are variants of End.DX2 defined in {{?RFC8986}},
> End.DX2 with REPLACE-CSID defined in
> {{?I-D.draft-ietf-spring-srv6-srh-compression}} and End.DX2 with NEXT-CSI=
D
> defined in {{?I-D.draft-filsfils-spring-net-pgm-extension-srv6-usid}} and
> all have the following procedures in common
--000000000000464bdb061b01cac2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Tal,<div><br></div><div>Thanks again for your review and a=
lso reviewing Christian's reply.</div><div><br></div><div>I'm conce=
rned regarding your suggestion that draft-filsfils-spring-net-pgm-extension=
-srv6-usid be made a normative reference, as it is only an individual draft=
right now and there's no guarantee that it'll even become a WG dra=
ft, never mind an RFC, and making it a normative reference would hold up pu=
blishing this draft for quite a while, unless we get special dispensation f=
rom the IESG. Do you see any way we can get around making draft-filsfils=C2=
=A0normative?</div><div><br></div><div>I'm much less concerned regardin=
g draft-ietf-spring-srv6-srh-compression, as that is currently in WG last c=
all.</div><div><br></div><div>Thanks again,</div><div>Andy</div><div><br></=
div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_at=
tr">On Sun, Jun 16, 2024 at 1:12=E2=80=AFAM Tal Mizrahi <<a href=3D"mail=
to:[email protected]">[email protected]</a>> wrote:<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Christian and aut=
hors,<br>
<br>
Thanks for considering my comments.<br>
The changes you suggested make sense to me.<br>
<br>
Regarding the new endpoint behaviors, please note:<br>
- The IANA section will need to be updated accordingly.<br>
- You may need to move the references to normative: {{?RFC8986}},<br>
{{?I-D.draft-ietf-spring-srv6-srh-compression}},<br>
{{?I-D.draft-filsfils-spring-net-pgm-extension-srv6-usid}}.<br>
Specifically the last two, which may still be subject to changes.<br>
<br>
Cheers,<br>
Tal.<br>
<br>
On Sat, Jun 8, 2024 at 12:16=E2=80=AFPM Christian Schmutzer (cschmutz)<br>
<<a href=3D"mailto:[email protected]" target=3D"_blank">cschmutz@cisco.=
com</a>> wrote:<br>
><br>
> Hi Tal,<br>
><br>
> Sorry for taking so long. Below our comments and proposal for addressi=
ng your issues.<br>
><br>
> Can you please let us know your thoughts. Upon your feedback we will w=
ork towards uploading a new version addressing the issues.<br>
><br>
> regards<br>
> Christian<br>
><br>
> On 15.05.2024, at 01:20, Tal Mizrahi <<a href=3D"mailto:tal.mizrahi=
[email protected]" target=3D"_blank">[email protected]</a>> wrote:<=
br>
><br>
> Hello,<br>
><br>
> I have been selected as the Routing Directorate reviewer for this<br>
> draft. The Routing Directorate seeks to review all routing or<br>
> routing-related drafts as they pass through IETF last call and IESG<br=
>
> review, and sometimes on special request. The purpose of the review is=
<br>
> to provide assistance to the Routing ADs. For more information about<b=
r>
> the Routing Directorate, please see<br>
> <a href=3D"https://wiki.ietf.org/en/group/rtg/RtgDir" rel=3D"noreferre=
r" target=3D"_blank">https://wiki.ietf.org/en/group/rtg/RtgDir</a><br>
><br>
> Document: draft-ietf-pals-ple-04<br>
> Reviewer: Tal Mizrahi<br>
> Intended Status: Standards Track<br>
><br>
> Summary:<br>
> I have some concerns about this document that I think should be<br>
> resolved before publication.<br>
><br>
> The draft is well-written and clear from a grammatical and structural<=
br>
> perspective. However, there is a very long list of normative<br>
> references that are cited in almost every paragraph of the document,<b=
r>
> making it very difficult to follow for a reader who is somewhat<br>
> familiar with the area but is not an expert in the area.<br>
><br>
><br>
> [cs]<br>
> PLE has a lot of similarities with RFC 4553 and other referenced speci=
fications. We felt references are better as it avoids duplication of text a=
cross documents, but I see your point. We will work through the document an=
d add a bit more text / context before calling out a RFC reference.<br>
><br>
> Here an example from the introduction section. Will do something simil=
ar for other sections.<br>
><br>
> before:<br>
><br>
> The mechanisms described in this document follow principals similar to=
[RFC4553] but expanding the applicability beyond the narrow set of PDH int=
erfaces (T1, E1, T3 and E3) and allow the transport of signals from many di=
fferent technologies such as Ethernet, Fibre Channel, SONET/SDH [GR253]/[G.=
707] and OTN [G.709] at gigabit speeds by treating them as bit-stream paylo=
ad defined in sections 3.3.3 and 3.3.4 of [RFC3985].<br>
><br>
><br>
> after:<br>
><br>
> The mechanisms described in this document follow principles similar to=
Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP) de=
fined in [RFC4553]. The the applicability is expanded beyond the narrow set=
of PDH interfaces (T1, E1, T3 and E3) to allow the transport of signals fr=
om many different technologies such as Ethernet, Fibre Channel, SONET/SDH [=
GR253]/[G.707] and OTN [G.709] at gigabit speeds. The signals are treated a=
s bit-stream payload which was defined in the Pseudo Wire Emulation Edge-to=
-Edge (PWE3) architecture in [RFC3985] sections 3.3.3 and 3.3.4.<br>
><br>
><br>
> Where applicable we will remove the reference and just have appropriat=
e text. Once example<br>
><br>
> before:<br>
><br>
> Similar to [RFC4553] and [RFC5086] the term Interworking Function (IWF=
) is used to describe the functional block that encapsulates bit streams in=
to PLE packets and in the reverse direction decapsulates PLE packets and re=
constructs bit streams.<br>
><br>
><br>
> after:<br>
><br>
> The term Interworking Function (IWF) is used to describe the functiona=
l block that encapsulates bit streams into PLE packets and in the reverse d=
irection decapsulates PLE packets and reconstructs bit streams.<br>
><br>
><br>
><br>
> Issues:<br>
> - The target audience of the document should be clarified, preferably<=
br>
> in the abstract. On a related note, throughout the document it is a<br=
>
> bit difficult to distinguish between requirements defined for<br>
> operators vs. requirements defined for implementers. Perhaps the<br>
> authors could give some thought as to whether this issue can be<br>
> mitigated.<br>
><br>
><br>
> [cs]<br>
> the target audience is implementers. We adjusted the abstract to refle=
ct that<br>
><br>
> before:<br>
><br>
> This document describes a method for encapsulating high-speed bit-stre=
ams as virtual private wire services (VPWS) over packet switched networks (=
PSN) providing complete signal transport transparency.<br>
><br>
><br>
> after:<br>
><br>
> This document describes methods and requirements for implementing the =
encapsulation of high-speed bit-streams into virtual private wire services =
(VPWS) over packet switched networks (PSN) providing complete signal transp=
ort transparency.<br>
><br>
><br>
> - The security considerations should be more detailed. The cited<br>
> references are a good start, but the following issues should also be<b=
r>
> discussed:<br>
><br>
>=C2=A0 - The requirement for synchronization is potentially a<br>
> vulnerability. An on-path attacker may compromise the synchronization,=
<br>
> and thus compromise the service. You may want to take a look at RFC<br=
>
> 7384.<br>
><br>
>=C2=A0 - The requirements for low jitter, low loss and bandwidth<br>
> reservation (section 8) are also potentially an attack vector. You may=
<br>
> take a look at RFC 9055 for example.<br>
><br>
><br>
> [cs]<br>
> We have added a couple of sentences to provide more details, plus refe=
rred to respective RFCs for more information<br>
><br>
> before:<br>
><br>
> As PLE is leveraging VPWS as transport mechanism the security consider=
ations described in [RFC7432] and [RFC3985] are applicable.<br>
><br>
><br>
><br>
> after:<br>
><br>
> As PLE is leveraging VPWS as transport mechanism the security consider=
ations described in [RFC7432] and [RFC3985] are applicable.<br>
><br>
> PLE does not enhance or detract from the security performance of the u=
nderlying PSN. It relies upon the PSN mechanisms for encryption, integrity,=
and authentication whenever required.<br>
><br>
> A data plane attack may force PLE packets to be dropped, re-ordered or=
delayed beyond the limit of the CE-bound IWF's dejitter buffer leading=
to either degradation or service disruption. Considerations outlined in [R=
FC9055] are a good reference.<br>
><br>
> Clock synchronization leveraging PTP is sensitive to Packet Delay Vari=
ation (PDV) and vulnerable to various threads and attacked vectors. Conside=
rations outlined in [RFC7384] should be taken into account.<br>
><br>
><br>
><br>
> - The following two endpoint behaviors are defined in the IANA<br>
> considerations section, but not defined anywhere in the document.<br>
> These endpoint behaviors should either be removed or specified in<br>
> detail:<br>
> End.DX1 with NEXT-CSID<br>
> End.DX1 with REPLACE-CSID<br>
><br>
><br>
> [cs]<br>
> Good point and I realised we have also forgotten to add the required e=
ncaps description. We have reworded this section as follows (in markdown sy=
ntax)<br>
><br>
> When a SRv6 PSN layer is used, a SRv6 service SID does provide the dem=
ultiplexing mechanism and the mechanisms defined in {{?RFC8402}} and {{?RFC=
9252}} section 6 do apply. Both SRv6 service SIDs with the full IPv6 addres=
s format defined in {{?RFC8986}} and compressed SIDs (C-SIDs) with format d=
efined in {{?I-D.draft-ietf-spring-srv6-srh-compression}} can be used.<br>
><br>
> Two new encapsulation behaviors H.Encaps.L1 and H.Encaps.L1.Red are de=
fined in this document. The behavior procedures are applicable to both SIDs=
and C-SIDs.<br>
><br>
> The H.Encaps.L1 behavior encapsulates a frame received from an IWF in =
a IPv6 packet with an SRH. The received frame becomes the payload of the ne=
w IPv6 packet.<br>
><br>
> * The next header field of the SRH MUST be set to TBA1.<br>
><br>
> * The push of the SRH MAY be omitted when the SRv6 policy only contain=
s one segment.<br>
><br>
> The H.Encaps.L1.Red behavior is an optimization of the H.Encaps.L1 beh=
avior.<br>
><br>
> * H.Encaps.L1.Red reduces the length of the SRH by excluding the first=
SID in the SRH of the pushed IPv6 header. The first SID is only placed in =
the destination address field of the pushed IPv6 header.<br>
><br>
> * The push of the SRH MAY be omitted when the SRv6 policy only contain=
s one segment.<br>
><br>
> Three new "Endpoint with decapsulation and bit-stream cross-conne=
ct" behaviors called End.DX1, End.DX1 with NEXT-CSID and End.DX1 with =
REPLACE-CSID are defined in this document.<br>
><br>
> These new behaviors are variants of End.DX2 defined in {{?RFC8986}}, E=
nd.DX2 with REPLACE-CSID defined in {{?I-D.draft-ietf-spring-srv6-srh-compr=
ession}} and End.DX2 with NEXT-CSID defined in {{?I-D.draft-filsfils-spring=
-net-pgm-extension-srv6-usid}} and all have the following procedures in com=
mon</blockquote></div>
--000000000000464bdb061b01cac2--
--===============2974609163820782941==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KUGFscyBtYWls
aW5nIGxpc3QgLS0gcGFsc0BpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVtYWlsIHRv
IHBhbHMtbGVhdmVAaWV0Zi5vcmcK
--===============2974609163820782941==--