Subject: [secdir] SECDIR review of draft-housley-pkix-oids

From: Matthew Lepinski <[email-masked]>
Date: Thu, 13 Feb 2014 13:52:23 -0500

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/

---

From: Tina TSOU <[email-masked]>
Date: Sat, 15 Feb 2014 03:07:50 +0000

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.

Section 2, page 3/4:
Could you please clarify the difference between "node" and "end station"? Are they synonyms?

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.

Section 5.1.1:

Snooping ARP packets probably means increased load (a disadvantage you didn't mention).

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.

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

* Nits

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

Replace "issue" with "issues"

Section 5.1.1, page 5:

"Ipv6" -> "IPv6"

Section 5.1.2:

Please expand UNA (possibly in the terminology section) -- you probably mean "Unsolicited..", but this should be explicit.

Thank you,
Tina

From: secdir [mailto:[email-masked]] On Behalf Of Matthew Lepinski
Sent: Friday, February 14, 2014 2:52 AM
To: [email-masked]; [email-masked]; [email-masked]
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.

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:

In Section 3.1:

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 21 Feb 2014 23:26:49 +0000

Tina,

Thank you very much for the review.

Replies are inserted below

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

Dear  all,

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:

[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:

[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:

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

* Nits

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:[email-masked]] On Behalf Of Matthew Lepinski
Sent: Friday, February 14, 2014 2:52 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [secdir] SECDIR review of draft-housley-pkix-oids

Nits

In Section 3:

In Section 3.1:

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 21 Feb 2014 23:32:13 +0000

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; [email-masked]; [email-masked]; [email-masked]
Subject: RE: SECDIR early review of draft-dunbar-armd-arp-nd-scaling-practices-07

Tina,

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

Dear  all,

Section 1:

Section 2, page 3/4:

Section 5.1.1:

Section 5.1.1:

Section 5.1.1:

Section 8:

* Nits

Section 5.1.1, page 5:

"Ipv6" -> "IPv6"

Section 5.1.2:

Linda

Thank you,
Tina

Nits

In Section 3:

In Section 3.1: