Subject: [secdir] SECDIR Review of http://tools.ietf.org/html/draft-ietf-v6ops-clatip-02

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 30 May 2014 09:09:38 -0400

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

The document is simply an assignment request for a reserved IP address
block for a scheme described in [RFC6333] and [RFC6877]. The block
previously assigned to DSLite is now assigned to related,
non-competing functions.

The document would be rather easier to make sense of if the start and
the end of the address range had been given.

192.0.0.0/29 is 192.0.0.0...192.0.0.7

This does not matter much because RFC6333 actually assigns specific
addresses for specific functions within this range. Exhaustion is not
really an issue since in extremis the response could be more tunnels.

---

From: "Zhangdacheng (Dacheng)" <[email-masked]>
Date: Sat, 31 May 2014 07:06:57 +0000

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

This short document tries to enhance the existing BGP route refresh mechanisms to provide for the demarcation of the beginning and the ending of a route refresh. In order to achieve this, the "Reserved" field of the ROUTE-REFRESH message is redefined to indicate the beginning and the ending of a route refresh. I agree this extension will not introduce new security issues to the BGP protocol.

The document is clear. I consider it ready with a few issues:

I suggest defining how a BGP speaker should handle a EoRR without receiving the associated BoRR especially when the peer does not support graceful start. 

The description in the last paragraph of section 4 is not very clear. It would be better to briefly explain why the introduced procedures can simplify the interaction with the BGP Graceful Restart. In addition, the EOR and EoR messages (the typos of EoRR?) mentioned in this paragraph are not defined elsewhere. 

Cheers

Dacheng