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

[David Mandelberg <[e-mail]>]

Looks good, thanks!

Greg Mirsky schreef op 2023-05-19 15:40:
> 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.
>>>>> 
>>>>> 
>>>>