[anonsec] comments on the BTNS core I-D

[ddp at electric-loft.org (Derrell Piper)]

On Jul 30, 2007, at 10:31 AM, Nicolas Williams wrote:

> On Mon, Jul 30, 2007 at 09:26:51AM -0700, Derrell Piper wrote:
>> 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'.
>
> I'm not sure we want to do that.  For one, nothing says that you can't
> cluster BTNS hosts.  It is about as difficult to cluster BTNS hosts as
> it is to cluster hosts using IPsec in general (a little worse once you
> add connection latching if you use the dynamic IPsec policy editing
> implementation approach).

If you just replace 'node' with either 'system' or 'host' throughout,  
you'll address my point.

>> 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.
>
> Failure is handled as specified in RFC4301 and RFC4306.  There is a
> separate I-D adding an IKE notify payload to indicate to the peer that
> it has matched a BTNS PAD entry.

Are there no new BNTS specific errors?  Are they described somewhere  
else?

>> Your bracketed notation is confusing.  The brackets aren't adding
>> anything.
>
> In the examples?

Yes, but whatever.  It's just notation.

>> 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.
>
> Sending such certs is an option, not a requirement.

I dislike the reference to self-signed certificates here because I  
believe the mere reference
to them will encourage their use with BTNS and I don't think that's  
goodness.  It's adding complexity
for no additional value.

>> 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."?
>
> Yes.
>
>> "Node [D] has a non-fixed address."  "non-fixed" meaning what
>> exactly?  Why is that relevant?
>
> That it uses DHCP.  Michael?

I assumed as much but I don't see how that's relevant in your examples.

>> pg 6, "The machine that we will care in this example is [SG-A]"
>>
>> Grammar.  "Let's first examine [SG-A], a firewall..."
>
> A word was missing ("about").
>
>> pg 8, first bullet, maching PAD #3 but no Child SAs
>>
>> Is there an IKE informational generated in this case?  I think  
>> maybe you
>
> There can be (it's an option specified in a separate I-D).
>
>> should show exactly what you intend the IKE exchange to look like in
>> this case.
>
> Why?

Because the failure mode is bad for the other side if you don't  
generate an informational/notify.

>> 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?
>
> Yes, they are.  The point is to illustrate that [C] gets no protection
> from other BTNS nodes (unless PAD entries are added to its regular
> peers' PADs that match on [C]'s public key).
>
>> 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.
>
> I don't see the implication, particularly when the text is explicit
> about [C] not being protected from other BTNS nodes.

We agree there's no protection.  I still think the fact that you  
mention 'rogue nodes' tends
to make people question whether or not BTNS is providing protection  
from this when in fact it
does not (by design).  (FWIW, I do understand what you saying about C  
and the PAD.)

>> Alternatively, perhaps this whole discussion belongs in the Security
>> Considerations section.
>
> They are examples.  The security considerations section already has  
> text
> about the weaknesses of BTNS.
>
>> 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.
>
> I'm not sure what you mean here.

Well, do you want to say anything about what you're going to do if  
you encounter a second BTNS
host that's asserting a conflict network block (i.e., what are you  
going to do if you have a BTNS
SA with SG-B and then a second SG-B comes along)?

>> 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.
>
> There are RFCs with similar statements (e.g., RFC2743, in relation to
> "channel binding").  These kinds of statements are informative, not
> normative, and inform the reader about concurrent efforts at the time
> that the document was being progressed.  Such information can become
> stale, and therefore useless, but this is generally true for all RFCs.
>
> Nico
> --