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

[Greg Mirsky <[e-mail]>]

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.
> >      >
> >      >
> >
>