[anonsec] comments on the BTNS core I-D

[Derrell Piper]

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.