[anonsec] comments on the BTNS core I-D
ddp at electric-loft.org (Derrell Piper) Mon, 30 July 2007 16:26 UTC
From: "ddp at electric-loft.org"
Date: Mon, 30 Jul 2007 09:26:51 -0700
Subject: [anonsec] comments on the BTNS core I-D
Message-ID: <1E2CD67A-DAC3-4981-A4AC-2BEAB31EDE1A@electric-loft.org>
Overall: 'system' 'host' and 'node' are intermingled. 'node' in particular implies cluster to some of us and could easily be replaced with 'host' or 'system'. You need to specify exactly what happens for every failure mode and you ought to be sending IKE informational or Notify payloads for all error cases. Your bracketed notation is confusing. The brackets aren't adding anything. pg 3, third bullet "...replaces the ID with into the new ID..." -> "...replaces the ID with the new ID..." pg 3, last paragraph "These certificates need not to have been pre-shared with their peers (e.g., because ephermal, self-signed)." -> "These certificates do not need to be pre-shared with their peers and may be ephemeral self-signed certificates." I generally don't like the idea of sending self-signed certificates for ephemeral keys. If the point is solely to maintain IKEv2 semantics, you should say that. Otherwise, there's little reason to require the extra overhead of the certificate processing (and parsing) when all you're really doing is extracting the public key anyway. pg 6, Figure 1 "In this diagram, there are six end-nodes: A, B, C and D." That's four, not six. Do you mean "...nodes: A, B, C, D, Q and R."? "Node [D] has a non-fixed address." "non-fixed" meaning what exactly? Why is that relevant? pg 6, "The machine that we will care in this example is [SG-A]" Grammar. "Let's first examine [SG-A], a firewall..." pg 8, first bullet, maching PAD #3 but no Child SAs Is there an IKE informational generated in this case? I think maybe you should show exactly what you intend the IKE exchange to look like in this case. pg 8, second bullet "...a rogue BTNS nodes..." -> "...a rogue BTNS node..." I'm not sure I understand what you mean here. If you're authenticating on C's address with BTNS, you're C. In essence, aren't all BTNS nodes rogue nodes? I think your use of the term 'rogue node' is confusing throughout because using it at all sort of implies that there's some protection when there's not. Alternatively, perhaps this whole discussion belongs in the Security Considerations section. pg 8, "...and it's NFSv4 implementation is..." -> "...and its..." pg 8, "traffice" -> "traffic" pg 9, "As [Q] has no formal relationship with [SG-B], rogues can impersonate [B] (i.e., assert [B]'s addresses)." You need to specify what should happen if a second [B] or [SG-B] comes along. pg. 11, Section 4.2 "If so, records the server's name..." is a sentence fragment. pg. 11, "Leap of faith can work in a similar way for BTNS nodes, but it is currently still being designed and specified b y the IETF BNTS WG." This statement is close to useless. Either say something substantive or remove it.
- [anonsec] comments on the BTNS core I-D Stephen Kent
- [anonsec] comments on the BTNS core I-D Sam Hartman
- [anonsec] comments on the BTNS core I-D Michael Richardson
- [anonsec] comments on the BTNS core I-D Stephen Kent
- [anonsec] comments on the BTNS core I-D Michael Richardson
- [anonsec] comments on the BTNS core I-D Michael Richardson
- [anonsec] comments on the BTNS core I-D Nico
- [anonsec] comments on the BTNS core I-D Stephen Kent
- [anonsec] comments on the BTNS core I-D Nicolas Williams
- [anonsec] comments on the BTNS core I-D Derrell Piper
- [anonsec] comments on the BTNS core I-D Stephen Kent
- [anonsec] comments on the BTNS core I-D Nicolas Williams
- [anonsec] comments on the BTNS core I-D Nicolas Williams
- [anonsec] comments on the BTNS core I-D Stephen Kent
- [anonsec] comments on the BTNS core I-D Nicolas Williams
- [anonsec] comments on the BTNS core I-D Derrell Piper
- [anonsec] comments on the BTNS core I-D Nicolas Williams