Subject: [Gen-art] Gen-ART Telechat review of draft-ietf-l3vpn-ibgp-07

From: Suresh Krishnan <[email-masked]>
Date: Tue, 7 Jun 2011 18:51:25 -0400

I have been selected as the General Area Review Team (Gen-ART) reviewer
for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd or AD before
posting a new version of the draft.

Document: draft-ietf-l3vpn-ibgp-07
Reviewer: Suresh Krishnan
Review Date: 2011/06/07
IESG Telechat date: 2011/06/09

Summary: This draft is ready for publication as a Proposed Standard but
it has two minor issues.

Minor
=====

* Section 5

Since the Extended Length bit is not being set in the Attribute Flags, 
the Length can only be 1 octet (as opposed to 1 or 2 octets as shown in 
the figure right? This needs to be clarified.

* Security Considerations

Since the ATTR_SET can contain arbitrary customer attributes, is it 
possible that a set of customers can perform a memory exhaustion attack 
on the PE routers? I understand the same can occur when the customer is 
using communities but I think it is worth mentioning.

Thanks
Suresh

---

From: Pedro Marques <[email-masked]>
Date: Tue, 7 Jun 2011 16:15:59 -0700

Suresh,
Thank you for the review.

Regarding Section 5:
The Length can be either 1 or 2 octets. 4271 defines Attr Flags.
Bit 0 is the Optional bit; Bit 1 is the Transitive bit;  Bit 3 is the
Extended length bit.

This document specified that bits 0 and 1 must be set to 1 (Optional +
transitive). The Extended length bit must be set according to the
attribute payload as per 4271.

The convention is the same as for any other BGP attribute.

I'll add a clarification to this effect.

Regarding security considerations:
- The resource management considerations exist regarding routes as
well as attributes, with or without this specification. I don't mind
highlighting it, if you believe that improves the specification.

thanks,
  Pedro.

On Tue, Jun 7, 2011 at 3:51 PM, Suresh Krishnan
<[email-masked]> wrote:
> Since the Extended Length bit is not being set in the Attribute Flags, the
> Length can only be 1 octet (as opposed to 1 or 2 octets as shown in the
> figure right? This needs to be clarified.
>
> Since the ATTR_SET can contain arbitrary customer attributes, is it possible
> that a set of customers can perform a memory exhaustion attack on the PE
> routers? I understand the same can occur when the customer is using
> communities but I think it is worth mentioning.
>
> Thanks
> Suresh
>

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 8 Jun 2011 16:44:40 -0400

Hi Pedro,
   Thanks for the quick reply. Please find comments inline.

> I'll add a clarification to this effect.

Perfect. I did read up on Section 4.3 of RFC4271 before I sent my review 
but it was not clear whether setting the bit was per attribute type code 
or it was runtime. I think a clarification would be good here.

> highlighting it, if you believe that improves the specification.

I do believe this is worth mentioning, but I leave it up to your 
discretion on whether you want to add any text.

Thanks
Suresh