comments on the BTNS core I-D

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.


_______________________________________________

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).

> 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.

> Your bracketed notation is confusing.  The brackets
aren't adding  
> anything.

In the examples?

> 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.

> 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?

> 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?

> 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.

> 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.

> 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
-- 
_______________________________________________

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

_______________________________________________

On Mon, Jul 30, 2007 at 11:53:25AM -0700, Derrell Piper
wrote:
> 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

Actually, this is not the case.  Looking at the usage in -04
I see

 - "system" is used as a synonym for
"node" in one place; the other uses
   of it could be in reference to the implementation (as in
"operating
   system")

 - "node" is mostly, but not always used when
referring to a system
   operating with IPsec support

 - "host" is used only in reference to systems
running behind a security
   gateway

None of these uses seems to be inconsistent with the various
glossaries
of the IETF.

For example, RFC1983 says this about "node":
"An addressable device
attached to a computer network.  See also: host,
router."  And it says
this about "host": "A computer that allows
users to communicate with
other host computers on a network.  Individual users
communicate by
using application programs, such as electronic mail, Telnet
and FTP.
[Source: NNSC]."

Whereas RFC2828 says this about "host": "(I)
Specific Internet Protocol
Suite usage: A networked computer that does not forward
Internet
Protocol packets that are not addressed to the computer
itself. (See:
router.)"

Only RFC2828 defines "system": "(C) In this
Glossary, the term is mainly
used as an abbreviation for "automated information
system"."  From the
usage of "system" elsewhere in RFC2828 I gather
that "automated
information system" means something like
"computer."

RFC4301 seems to use "system" to mean
"networked computer" and includes,
in some cases, intermediate systems ("A security
gateway is an
intermediate system...").  RFC4301 mostly does not
refer to nodes, but
it does not use "system" as having a single
meaning ("system" usually
appears in RFC4301 with or as a modifier).

I see nothing about "node" denoting "possibly
a cluster," only that it
is a networked, addressable computer, including middle boxes
(e.g.,
routers).

OTOH, if a "node" can be replaced by a cluster of
other nodes then
presumably the cluster should behave as if it were a
monolythic node to
the best of the implementor's ability.  And *this* leads me
to conclude
that "node" is a perfectly good word to be using
in the BTNS core I-D,
and in the way that we have used it.

> >>implies
> >>cluster to some of us and could easily be
replaced with 'host' or
> >>'system'.

I simply fail to see where this implication comes from,
although I do
not reject the proposition that "every node could be a
cluster [i.e.,
multiple systems behaving as though they were one]." 
And here I think
"system" has a much broader meaning than
"node," which leads me to
conclude that...

> >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.

...to replace "node" with "system" would
be inappropriate, and to
replace "node" with "host" when some
nodes in our examples are security
gateways (and, therefore, a kind of router), is even more
inappropriate
still (since "host" is a "node" that
does not forward packets, according
to at least one glossary).

I'd be happy to entertain an argument that
"system" or some phrase
including that word should replace "node" because
RFC4301 does just
that, but I've not seen such an argument.

I'd also be happy to add a glossary, and to make sure that
the I-D is
consistent in its use of these three words, but this is a
damned short
I-D (particularly if you strip off the informative
examples).  Just how
long must we make it?!  And I'll note that RFC4301 does not
define
"system," nor "host," nor
"node" in its glossary -- I think it doesn't
even use "host" in the sense of "node that
doesn't forward packets,"
which might make it a sloppily written RFC...  But I think
I'd rather
conclude that English is not the formal language that ASN.1,
XML, UML,
etcetera are, and that this is actually a good thing.

> >>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.

Agreed, it's just notation and we'll stick to it.

> >>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.

Sorry, we're allowed to have MAYs, and we'll keep this one.
Implementors are free to ignore this "MAY," as
usual.

> >>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.

It's relevant because dynamically addressed systems can take
over each
other's addresses with a modicum of active attack effort. 
Perhaps this
needs to be explained in more detail.

In -04 we removed text that referred to the problems that
may arise from
having PAD entries with large address constraints.  We
presented on
these problems at earlier meetings; from Stephen's input we
concluded
that describing these problems was not important in this
document, and
that the consequent need to be rigorous in describing them
would be a
waste of our time.

So perhaps it is, indeed, irrelevant now.  But I'm not
convinced that
it's completely irrelevant: because such a system's address
can be one
of so many it becomes undesirable to write PAD entries for
them that say
to search the SPD by IP address; of course, we don't have
example
PAD/SPD entries for [D].

Perhaps the examples have served their purpose (help
reviewers) and now
it's time to remove them?

Michael?

> >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.)

For now we'll leave this as is.

> >>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)?

The PAD says how to authenticate SG-B, and the text of the
I-D tells you
that a BTNS node cannot assert SG-B's addresses because
child SA
requests by BTNS peers MUST be rejected if they assert
addresses that
are referenced by other non-BTNS PAD entries.

The next to last bullet in example #1 covers this too.

Nico
-- 
_______________________________________________