Re: [secdir] Secdir early review of draft-ietf-bier-ping-08

[Greg Mirsky <[e-mail]>]

Hi David,
a new version of the draft includes updates we've discussed. Also, it
includes updates resulting from discussions of reviews by IntDir and RtgDir
experts. I would appreciate it if you could review the updates (diff
between the -08 version and the current version 10 is attached for your
convenience). Please let me know if you have any further questions.

Best regards,
Greg

On Wed, May 10, 2023 at 9:18 PM Greg Mirsky <[e-mail]> wrote:

> Hi David,
> thank you for the discussion. Please find my notes below under the GIM>>
> tag.
>
> Regards,
> Greg
>
> On Tue, May 9, 2023 at 5:04 PM David Mandelberg <[e-mail]>
> wrote:
>
>> I'm not familiar with LSP ping, but I just skimmed the security
>> considerations section of that RFC. Unless I missed something (which is
>> possible), it looks like it only talks about DoS attacks against the
>> recipient of the ping, not amplification to attack a third party using
>> the reply. With LSP ping, are the requests and responses roughly the
>> same size? If they are, then that seems to be a key difference between
>> BIER ping and LSP/ICMP ping, so it should be covered in BIER ping's
>> security considerations.
>>
> GIM>> I think that LSP Ping and BIER Ping are closer to each other
> functionally than to ICMP. As we noted in the draft, some informational
> elements used in the LSP Ping are equally applicable in BIER Ping (DDMAP).
>
>>
>> As for suggesting additional text/reference, how difficult would it be
>> in practice for an attacker to spoof the source address in BIER ping?
>> (That's the part I really don't have a sense of.) If it's pretty
>> difficult, then it's probably enough to just point that out as the
>> reason DDoS amplification isn't a big concern. If it's not that hard,
>> then there might be a bigger problem.
>>
> GIM>> I think that such a scenario in BIER is as difficult as in an MPLS
> network. Thank you for the suggestion. I will add that in the next version.
>
>>
>>
>> Op 2023-05-09 om 17:43 schreef Greg Mirsky:
>> > Hi David,
>> > that's a valid point. I may compare the scenario you describe with the
>> > commonly used in LSP Ping identical reply mode, i.e., over IPv4/IPv6
>> > network. In that case, the MPLS label stack may not identify the Echo
>> > Request sender, and the receiving node relies on the source IP address
>> > in the IP/UDP header that immediately follows the label stack. It seems
>> > like methods to mitigate the risk of exploiting LSP Ping as a DDoS
>> > attack described the Security Consideration in RFC 8029 accepted as
>> > sufficient. In our draft, we point them as equally relevant for BIER
>> > Ping. Would you suggest an additional text or reference for
>> > draft-ietf-bier-ping?
>> >
>> > Regards,
>> > Greg
>> >
>> > On Tue, May 9, 2023 at 12:37 PM David Mandelberg <[e-mail]
>> > <mailto:[e-mail]>> wrote:
>> >
>> >     The Reply-To TLV stood out to me as the easiest way to redirect
>> return
>> >     traffic to a vicim, but not necessarily the only way. Can the BFIR
>> >     ID be
>> >     spoofed to get return traffic sent to an unsuspecting third party?
>> >
>> >     Op 2023-05-08 om 12:16 schreef Greg Mirsky:
>> >      > Hi David,
>> >      > thank you for your thoughtful comments. After reviewing the use
>> >      > scenario, we decided to remove the Reply-To TLV. The BIER Header
>> >      > includes the BFIR ID that can be used to derive the IP address of
>> >     the
>> >      > Sender. I hope that addresses your concern.The new version of the
>> >     draft
>> >      > <https://datatracker.ietf.org/doc/draft-ietf-bier-ping/
>> >     <https://datatracker.ietf.org/doc/draft-ietf-bier-ping/>> also
>> includes
>> >      > updates addressing early reviews from Rtg and Int areas.
>> >      > Please let me know if you have any further questions.
>> >      >
>> >      > Best regards,
>> >      > Greg
>> >      >
>> >      > On Fri, Apr 21, 2023 at 2:33 PM David Mandelberg via Datatracker
>> >      > <[e-mail] <mailto:[e-mail]>
>> >     <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>> >      >
>> >      >     Reviewer: David Mandelberg
>> >      >     Review result: Has Nits
>> >      >
>> >      >     This mostly looks good, I think.
>> >      >
>> >      >     My only concern is about if/how this could be exploited to
>> DDoS
>> >      >     third parties.
>> >      >     It looks like there are a few ways that the responses can be
>> >     larger
>> >      >     than the
>> >      >     requests, either by responders adding additional TLVs, or by
>> >     multiple
>> >      >     responders responding to the same request. I'm not sure how
>> >     much of
>> >      >     a risk
>> >      >     source address spoofing is in the request's outer header,
>> but it
>> >      >     looks like the
>> >      >     Reply-To TLV can be used to send responses to another address
>> >     anyway,
>> >      >     regardless of the source address. So if this were on the open
>> >      >     internet, I'd
>> >      >     expect attackers to abuse it to send lots of data to their
>> >     targets.
>> >      >     But from
>> >      >     the mentions of MPLS, I'm guessing that this is not meant to
>> >     be used
>> >      >     on the
>> >      >     open internet? So it might not be an issue in the
>> >     environments this
>> >      >     is intended
>> >      >     to be deployed in, or there might be some other mitigation.
>> >      >
>> >      >
>> >
>>
>