Re: [MBONED] Kathleen Moriarty's Discuss on draft-ietf-mboned-interdomain-peering-bcp-11: (with DISCUSS and COMMENT)

[Toerless Eckert <[e-mail]>]

[The following text up to the individual reply comments is identical for 
 the replies to all ballot comments. I originally wanted to coalesce the reply to
 all positions into one email but the auto-generated header from datatracker
 makes it sound as if per-submitter replied are required. So, here we go with some
 repeated text followed by more individualized text:]

Dear Reviewer,

This is in response of your reviews of
    https://www.ietf.org/id/draft-ietf-mboned-interdomain-peering-bcp-11.txt
as entered in the ballot:
    https://datatracker.ietf.org/doc/draft-ietf-mboned-interdomain-peering-bcp/ballot/

A version of this email containing replies to all IESG feedback for -11 is also in: 
    https://raw.githubusercontent.com/toerless/peering-bcp/master/11-iesg-review-reply.txt

Thank you so much for your thorough review. In response to the IESG
feedback, version -12 and -13 of the draft where posted which we hope 
will resolve the open issues.
make 2

Version -12 of the draft was just a conversion from docx generated txt to XML (previous generations
where not built from XML), this introduced formatting changes (line wraps etc.) that rfcdiff can not ignore
and that would have obfuscated actual content changes. 

Version -13 of the draft contains the text changes done in response to your
comments and discusses. The following RFC diff shows the content diffs
vs. -11 without any formatting introduced changes:

http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-mboned-interdomain-peering-bcp-12.txt&url2=https://tools.ietf.org/id/draft-ietf-mboned-interdomain-peering-bcp-13.txt

In summary:
   Beside the various smaller fixups from comments, the mayor rewritten/new blocks are:

   4.1.1 - bandwidth management (aka: congestion control section). 
           I didn't just want to put the magic CC sentence in but wanted to let
           readers understand what it means in the context of specifically
   6. Security considerations
      6.1.  DoS attacks (against state and bandwidth)	
      6.2.  Content security	
      6.3.  Peering encryption
      6.4.  Operational Aspects
            This is where the securing of log exchange is discussed.
   7. Privacy Considerations
      Got somewhat longer to explain because the specifics of multicast content and privacy
      are likely not that obious to non-multicast  experienced readers, and given how this
      is a BCP and i don't even think we did describe this anywhere else, it had to be
      explanatory.
   
   4.2.4.  Public Peering Routing Aspects
      text did mention non-private peerings, but i was afraid that readers would not
      understand the problematic implications, so i detailled them given how those
      peering L2 domains are still common for unicast.


Cheers
    Toerless for the Authors

====================================================================================
Kathleen Moriarty:
> 
> Thanks for your work on this draft.  I'd like to see some text clarifications on security recommendations that should not be difficult to resolve.
> 
> Section 4.4 - the exchange of supporting information could be sensitive, are there security requirements on the exchange?  I don’t see them in this section.

I thought about this a lot, and i hope the fixed up text in various sections is now better.

In the end i tried to focus the description on the model that makes this closest to
unicast, eg.: where the end-to-end application is in control and just gets network
transport information from the other parties involved, eg.: AD-2 -> AD-1. So all the
information collected via logs etc. to the extend that it is per-user is really only about the transport service
and not the payload. Something which in unicast the content source would already have.

The only privacy sensitive information directly related to multicast is really "who is watching
what content" and i created a privacy consideration section for that aspect, pls. review.

[ Side note:

  Personally i think there is a real bad amount of personal info collected by
  end-to-end applications, especially what i've seen in the past in content delivery for
  monetization strategies such as targeted advertisements and the like, but seemingly there is no
  place in the IETF where this is discussed (would have to be somehwere in ART).
  IETF only seems to obsess about protecting the sensitive information against third parties
  which is good but totally not sufficient.

  I did add the last paragraph in the privacy section to hint at this and that
  multicast could help to solve this, but alas i fear that there is no interest
  in the paycheck generating part of the IETF community to explore those options
  because that invasion on privacy is at the core of the business model of most application
  service providers.  *sigh*
  ]

> Section 6 - For the following text, it would be helpful to see some recommendations:
>    “DRM and Application Accounting, Authorization and Authentication
>    should be the responsibility of the multicast application source
>    provider and/or AD-1. AD-1 needs to work out the appropriate
>    agreements with the source provider.”
> 
> I agree with and support Alissa's Discuss and comments.  Since she already holds a discuss on this point, here are my comments:
> Section 4.3.3 clearly refers to different types of logs, some have well known methods of delivery (syslog) and authentication, but setting a minimum requirement for secure exchange including encryption and authentication should be included in this section. The protocols and options may vary between the log types.

Right.

Alas, I am not aware of any established security standards to protect equivalent operational data
exchanged for unicast between SPs. I fear i would not like the answers if i asked what
is actually done. That makes it somewhat hard to be very specific. besides, with the
advent of SDN and the slow sunset of lots of insecure NNI protocols (IPfix anybody),
the option are endless.

I've tried to describe what i hope are sufficient recommendations into te first
paragraphs of section 7.4, "operational aspects" of security considerations. Please check it out.