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

[Linda Dunbar <[e-mail]>]

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]; [e-mail]; [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/