Re: Comments & suggestions to draft-mm-wg-effect-encrypt-13

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Linda,



On Mon, Dec 4, 2017 at 3:42 PM, Linda Dunbar <linda.dunbar@xxxxxxxxxx> wrote:
> Kathleen and Al,
>
>
>
> Great draft! Captured the deep concerns of our customers (network service
> providers) of not being able to troubleshoot network issues and achieve
> better load balance when all traffic are encrypted.
>
>
>
> But the network providers can’t really dictate how end points encrypt their
> traffic. Suggest add some description on how Network operators can have the
> options of using encapsulation (such as LISP, GENEVE, etc) at the network
> edges to carry all the information needed by the network operators for
> network maintenance or any other purposes.
>
>
Thanks for your input.  The routing ADs have made the same comment, which
is inevitable when network providers are handling only encrypted sessions.  We
 have some text from Alia in the network management section, so I added a brief
sentence to this point in that section.  We've been staying away from solution
work in the draft, but a quick sentence on this point is probably
worth mentioning.

Here's the updated paragraph:

In overlay networks (e.g. VXLAN, Geneve, etc.) that are used to
        provide hosted services, management access for a customer to support
        application management may depend upon the security mechanisms
        available as part of that overlay network. While overlay network data
        encapsulations may be used to indicate the desired isolation, this is
        not sufficient to prevent deliberate attacks that are aware of the use
        of the overlay network. [draft-mglt-nvo3-geneve-security-requirements]
        describes requirements to handle attacks. It is possible to use an
        overlay header in combination with IPsec or other encrypted traffic
        sessions, but this adds the requirement for authentication
        infrastructure and may reduce packet transfer performance. The use of
        an overlay header may also be deployed as a mechanism to manage
        encrypted traffic streams on the network by  network service providers.
        Additional extension mechanisms to provide integrity and/or privacy
        protections are being investigated for overlay encapsulations. Section 7
        of [RFC7348] describes some of the security issues possible when
        deploying VXLAN on Layer 2 networks. Rogue endpoints can join the
        multicast groups that carry broadcast traffic, for example.
>
> With Net Neutrality almost being overturned, network service providers can
> provide more favorable services to the End Points that indicate the needed
> information from network operators, such as stream size, Latency Needs, etc.

We'll stay away from text on this as I think it may be too early add
meaningful text.

Thanks again!
Kathleen & Al

>
> Like your Section 6.3 Application Layer Protocol negotiation (ALPN). IMHO,
> the similar protocol should be expanded beyond TLS. IETF is a perfect
> position to specify those bits for end points to indicate to network, like
> the shim layer specified by PLUS initiative. Once the Shim Layer is
> specified, the End Points that need better service will be obligated to
> provide the information.
>
>
>
> My two cents,
>
>
>
> Linda Dunbar
>
>
>
>



-- 

Best regards,
Kathleen





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]