Hi Christian, Please see inline via [cs]. The proposed changes are included in the new -10 revision I just uploaded Christian > On 19.10.2024, at 23:03, Christian Huitema via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Christian Huitema > Review result: Has Nits > > Draft 09 addresses many of the issues noted in my review of draft 08, but I am > a bit puzzled by some additions in the security section, such as: > > Misconnection detection using the SSRC of the RTP > header can increase the resilience to > misconfiguration and some types of denial-of- > service (DoS) attacks. > > Yes, that's probably true, but the description of how this will work in section > 5.2.2 is pretty minimal. In the threat model, we may distinguish on path > attackers, who can examine the traffic, and off path attackers, who may only > try to inject spoofed packets. The offpath attackers will have to guess the > value of the 32 bit SSRC, and will be reduced to guessing. The success of > failure of this guessing depends a lot on how the SSRC is set. If the sender > uses randomly allocated values, the guessing is hard. But if the sender uses a > fixed value (e.g., 0), or sequentially allocated values (e.g., 0, 1, 2, ..), > then the guessing is not so hard. I would feel better if 5.2.2 explained a bit > how the SSRC is generated, and what to do if a received value does not match > the previous ones. [cs] How about the following changes? OLD Misconnection detection using the SSRC of the RTP header can increase the resilience to misconfiguration and some types of denial-of-service (DoS) attacks. NEW Random initialization of sequence numbers, in both the control word and the RTP header, makes known-plaintext attacks more difficult. Misconnection detection using the SSRC of the RTP header can increase the resilience to misconfiguration and some types of denial-of-service (DoS) attacks. A randomly chosen expected SSRC value does decrease the chance of a spoofing attack being successful. Control plane mechanisms for signalling the expected SSRC value are described in [draft-schmutzer-bess-bitstream-vpws-signalling] and [draft-schmutzer-pals-ple-signaling]. > Another good addition to the security consideration is the paragraph stating > that "One of the requirements for protecting the data plane is that the PLE > packets be accepted only from valid interfaces." My only doubt is that > "interface" is a bit ambiguous in the case of IPv6 routing -- physical > interface or source IP address? Are you assuming that all routers in the AS are > implementing BCP 38? [cs] I have taken this sentence from RFC7432 section 19 but as PLE applies to MPLS and SRv6 I reworded it to be generic. I see your point, so I changed the wording back to be MPLS specific and moved it between the first sentence talking about considerations for MPLS and the sentence covering SR (MPLS and SRv6) OLD One of the requirements for protecting the data plane is that the PLE packets be accepted only from valid interfaces. For a PE, valid interfaces comprise links from other routers in the PE's own AS. For an ASBR, valid interfaces comprise links from other routers in the ASBR's own AS, and links from other ASBRs in ASes that have instances of a given PLE PW. It is especially important in the case of multi-AS PLE VPWS that one accept PLE packets only from valid interfaces. NEW The PSN is assumed to be trusted and secure. Considerations about the MPLS core network outlined in [RFC4381] are applicable. For MPLS based PSNs, one of the requirements for protecting the data plane is that the MPLS packets be accepted only from valid interfaces. For a PE, valid interfaces comprise links from other routers in the PE's own AS. For an ASBR, valid interfaces comprise links from other routers in the ASBR's own AS, and links from other ASBRs in ASes that have instances of a given PLE PWs. It is especially important in the case of multi-AS PLE PWs that one accepts PLE packets only from valid interfaces. When a Segment Routing (SR) based PSN is used (MPLS or SRv6) the considerations in Section 8 of [RFC8402] and Section 9.3 of [RFC9252] are applicable. > > > -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
