Re: [secdir] SECDIR early review of draft-dunbar-armd-arp-nd-scaling-practices-07

[Tina TSOU <[e-mail]>]

Dear Linda,

The changes are OK to me.

In addition, the subject draft provides a brief description of common data center network designs for context, examines the ARP/ND scaling issues that arise in these designs, and concludes that the key issue is processing load on the L2/L3 boundary routers. It then proceeds to describe some practices for reducing that load. The description employs a mixture of bases for its organization:

(a) network design approach
 -- layer 3 to access switches or VMs (sec. 4)
 -- layer 2 measures (sec. 5.1)
 -- static ARP/ND entries on switches (sec. 5.2)
 -- ARP/ND proxying (sec. 5.3)
 -- overlay models (sec. 6)

(b) individual cases (secs. 5.1.1, 5.1.2, 5.1.3)

(c) IPv4 ARP vs. IPv6 ND (interspersed in all sections mentioned above except sec. 6. In addition, sec. 5.4 discusses multicast issues and is thus specifically related to ND.)

Because of the differences between ARP and ND and resulting applicability of the different measures described in sections 4-6, the reviewer's recommendation would be to reorganize the text by pulling ARP-specific and ND-specific discussions into separate sections of their own referring back to the remaining text. In this way sec. 5.4 in particular would fit more neatly into the framework. More importantly, it would become clear that scalability of IPv6 ND needs more work.

It is interesting to note that improving the scalability of ND is a matter under active discussion in 6man and v6ops but partly from a different angle: coping with battery-limited devices that are not always awake. Informational references to the relevant drafts (draft-chakrabarti-nordmark-6man-efficient-nd-05, draft-yourtchenko-colitti-nd-reduce-multicast-00, and draft-vyncke-6man-mcast-not-efficient-01) may be useful to add.

The Security Considerations section is currently just a 'motherhood'statement. Specific points are raised in the body of the text, such as the relationship of the bidirectional nature of ND to the correct operation of SeND. Any such specific points should be reflected in the Security Considerations section too.

Nits
====

-- Section 5.1 section header: s/APR/ARP/

-- Section 7 first bullet last sentence:

OLD

" ...  to have comprehensive study in making those changes."

NEW

" ... to make those changes only after comprehensive study."

-- Section 7 second bullet: s/Create an/Create/

-- References need updating to most recent versions.


Thank you,
Tina


From: Linda Dunbar
Sent: Friday, February 21, 2014 5:32 PM
To: Tina TSOU; '[e-mail]<mailto:[e-mail]>'; '[e-mail]<mailto:[e-mail]>'; '[e-mail]<mailto:[e-mail]>'
Subject: RE: SECDIR early review of draft-dunbar-armd-arp-nd-scaling-practices-07

Tina,

Please see the attached 08 version for the changes to address your comments. Please let me know if they are OK.

Thanks, Linda

From: Linda Dunbar
Sent: Friday, February 21, 2014 5:27 PM
To: Tina TSOU; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: SECDIR early review of draft-dunbar-armd-arp-nd-scaling-practices-07

Tina,

Thank you very much for the review.

Replies are inserted below

From: Tina TSOU [mailto:[e-mail]]
Sent: Friday, February 14, 2014 9:08 PM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: SECDIR early review of draft-dunbar-armd-arp-nd-scaling-practices-07

Dear  all,
I have reviewed this document as part of the security directorate's ongoing effort to for early review of WG drafts.  These comments were written primarily for the benefit of the security area directors.  Document editors and working group chairs should treat these comments just like any other comments.

Section 1:
Please expand ToR upon first occurrence.
[Linda] ToR is already defined in the Terminology section. Is it still necessary to expand?

Section 2, page 3/4:
Could you please clarify the difference between "node" and "end station"? Are they synonyms?
[Linda] Node can be switches/routers. “end station” doesn’t route or forward traffic. Packets are terminated by “end station”.



Section 5.1.1:

Shouldn't it be possible to avoid ND load by proper setting of the ReachableTime variable? -- This wouldn't require any protocol changes.

[Linda] Do you mean changing the setting on GuestOS? The issue is that many Guest OSs are out of network’s control. If Network can control Guest OS’s behavior, many things can be easier.


Section 5.1.1:

Snooping ARP packets probably means increased load (a disadvantage you didn't mention).
[Linda] yes, it increase the load, but in a controlled way. So the routers can process them within its capacity. So, it is not really disadvantage.

Section 5.1.1:

When address resolution is needed to deliver a packet, some routers just drop the packet when they engage in ARP (see http://tools.ietf.org/html/rfc6274#section-4.2.3) The same is true for
IPv6 ND.

[Linda] correct. The behavior is described in the second paragraph of Section 5.1.2:
Solution: To protect a router from being overburdened by resolving target MAC addresses, one solution is for the router to limit the rate of resolving target MAC addresses for inbound traffic whose target is not in the router’s ARP/ND cache. When the rate is exceeded, the incoming traffic whose target is not in the ARP/ND cache is dropped.


Section 8:

While this document does not introduce new issues itself, it should at least mention how the same ARP/ND issues may be intentionally triggered by an attacker. For example, you may reference RFC 6583

[Linda] Sure. Will add in the new version.

* Nits

Section 4, page 4:
> There are no address
>    resolution issue in this design.

Replace "issue" with "issues"
[Linda] In the latest draft ( 07 version: https://datatracker.ietf.org/doc/draft-dunbar-armd-arp-nd-scaling-practices/) it is already changed:

There is no address resolution issue in this design.



Section 5.1.1, page 5:

"Ipv6" -> "IPv6"

[Linda ] In the latest draft (07 version), it is already changed.


Section 5.1.2:

Please expand UNA (possibly in the terminology section) -- you probably mean "Unsolicited..", but this should be explicit.
[Linda] in the latest draft (07 version), UNA is already listed under the Terminology section.

Thank you very much for the review and comments.

Linda

Thank you,
Tina

From: secdir [mailto:[e-mail]] On Behalf Of Matthew Lepinski
Sent: Friday, February 14, 2014 2:52 AM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: [secdir] SECDIR review of draft-housley-pkix-oids

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 working group chairs should treat these comments just like any other last call comments.

This document returns control of the PKIX object identifier arc to IANA. That is, it establishes a new IANA registry for OIDs in the PKIX arc and populates that registry with the existing OID assignments. Finally, the document establishes expert review as the criteria for future additions to the registry and includes guidance that for review.

After reviewing the document, I agree with the author that this document introduces no new security concerns.

I found no issues in the document and I believe it is ready for publication.

-------------------------------

Nits

The author should consider including an expansion of the acronym SMI, which is used frequently in the document. (I believe in this context SMI = Structure of Management Information)

In Section 3:
s/be related to X.509 certificate/be related to X.509 certificates/

In Section 3.1:
s/to points to this document/to point to this document/



<draft-dunbar-armd-arp-nd-scaling-practices-08.docx>