Re: [Pce] Eric Rescorla's Discuss on draft-ietf-pce-rfc6006bis-03: (with DISCUSS)

No, not really. You're still citing to 5440 which has the TCP-MD5 stuff,
and there's no requirement to use AO. I think what's needed here is a
normative requirement for something strong than TCP-MD5. I defer to the WG
on what that should be, but it's really not OK to keep using TCP-MD5 as our
basic security measure for TCP connections for routing protocols

-Ekr

On Thu, Aug 31, 2017 at 12:36 AM, Dhruv Dhody <dhruv.dhody@huawei.com>
wrote:

> Hi Eric,
>
> > -----Original Message-----
> > From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Eric Rescorla
> > Sent: 31 August 2017 05:12
> > To: The IESG <iesg@ietf.org>
> > Cc: draft-ietf-pce-rfc6006bis@ietf.org; pce@ietf.org;
> pce-chairs@ietf.org
> > Subject: [Pce] Eric Rescorla's Discuss on draft-ietf-pce-rfc6006bis-03:
> > (with DISCUSS)
> >
> > Eric Rescorla has entered the following ballot position for
> > draft-ietf-pce-rfc6006bis-03: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.
> html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-pce-rfc6006bis/
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > The Security Considerations is worrisome, as it points to RFC 5440;
> > Section 10.2, which basically recommends TCP-MD5:
> >
> >    At the time of writing, TCP-MD5 [RFC2385] is the only available
> >    security mechanism for securing the TCP connections that underly PCEP
> >    sessions.
> >
> >    As explained in [RFC2385], the use of MD5 faces some limitations and
> >    does not provide as high a level of security as was once believed.  A
> >    PCEP implementation supporting TCP-MD5 SHOULD be designed so that
> >    stronger security keying techniques or algorithms that may be
> >    specified for TCP can be easily integrated in future releases.
> >
> >    The TCP Authentication Option [TCP-AUTH] (TCP-AO) specifies new
> >    security procedures for TCP, but is not yet complete.  Since it is
> >    believed that [TCP-AUTH] will offer significantly improved security
> >    for applications using TCP, implementers should expect to update
> >    their implementation as soon as the TCP Authentication Option is
> >    published as an RFC.
> >
> >    Implementations MUST support TCP-MD5 and should make the security
> >    function available as a configuration option.
> >
> > TCP-AO has now been published as an RFC for quite some time, so it's
> > probably not really appropriate to just point to a document which
> > recommends TCP-MD5.
> >
> [[Dhruv Dhody]] Let me know if this change is okay -
>
> OLD:
> 5.  Security Considerations
>
>    As described in [RFC5862], P2MP path computation requests are more
>    CPU-intensive and also utilize more link bandwidth.  In the event of
>    an unauthorized P2MP path computation request, or a denial of service
>    attack, the subsequent PCEP requests and processing may be disruptive
>    to the network.  Consequently, it is important that implementations
>    conform to the relevant security requirements of [RFC5440] that
>    specifically help to minimize or negate unauthorized P2MP path
>    computation requests and denial of service attacks.  These mechanisms
>    include:
>
>    o  Securing the PCEP session requests and responses using TCP
>       security techniques (Section 10.2 of [RFC5440]).
>
>    o  Authenticating the PCEP requests and responses to ensure the
>       message is intact and sent from an authorized node (Section 10.3
>       of [RFC5440]).
>
>    o  Providing policy control by explicitly defining which PCCs, via IP
>       access-lists, are allowed to send P2MP path requests to the PCE
>       (Section 10.6 of [RFC5440]).
>
>    PCEP operates over TCP, so it is also important to secure the PCE and
>    PCC against TCP denial of service attacks.  Section 10.7.1 of
>    [RFC5440] outlines a number of mechanisms for minimizing the risk of
>    TCP based denial of service attacks against PCEs and PCCs.
>
>    PCEP implementations SHOULD consider the additional security provided
>    by Transport Layer Security (TLS) [I-D.ietf-pce-pceps].
> NEW:
> 5.  Security Considerations
>
>    As described in [RFC5862], P2MP path computation requests are more
>    CPU-intensive and also utilize more link bandwidth.  In the event of
>    an unauthorized P2MP path computation request, or a denial of service
>    attack, the subsequent PCEP requests and processing may be disruptive
>    to the network.  Consequently, it is important that implementations
>    conform to the relevant security requirements that specifically help
>    to minimize or negate unauthorized P2MP path computation requests and
>    denial of service attacks.  These mechanisms include:
>
>    o  Securing the PCEP session requests and responses using TCP
>       security techniques such as TCP Authentication Option (TCP-AO)
>       [RFC5925] or using Transport Layer Security (TLS) [I-D.ietf-pce-
>       pceps], as per the recommendations and best current practices in
>       [RFC7525].
>
>    o  Authenticating the PCEP requests and responses to ensure the
>       message is intact and sent from an authorized node using TCP-AO or
>       TLS.
>
>    o  Providing policy control by explicitly defining which PCCs, via IP
>       access-lists, are allowed to send P2MP path requests to the PCE
>       (Section 10.6 of [RFC5440]).
>
>    PCEP operates over TCP, so it is also important to secure the PCE and
>    PCC against TCP denial of service attacks.  Section 10.7.1 of
>    [RFC5440] outlines a number of mechanisms for minimizing the risk of
>    TCP based denial of service attacks against PCEs and PCCs.
> END
>
> Thanks,
> Dhruv
>
>
> >
> >
> >
> > _______________________________________________
> > Pce mailing list
> > Pce@ietf.org
> > https://www.ietf.org/mailman/listinfo/pce
>
>