Subject: Comments on SEND protocol

From: Pekka Savola <[email-masked]>
Date: Sat, 8 Mar 2003 23:56:59 +0200 (EET)

Hi,

Here are the technical & editorial comments I scribbled down on a quick 
read.  I didn't look at security considerations because they were too 
CGA-specific, and overlooked conclusions&path forward.

Substantial:
------------

==> Big issue (at least later): a security considerations section which
checks the protocol against the SEND requirements and threats to see that
there are no omissions etc.

==> One may have to consider whether Neighbor Discovery or IPsec changes 
have to go to separate document(s) -- in this case, the modifications are 
probably not as invasive as some in MIPv6, but some might argue for it.

4. Secure Neighbor Discovery Overview

   o  IPsec AH is used to protect all advertisement messages relating to
      Neighbor and Router discovery.  Solicitation messages are not
      protected, as they do not carry any information.

==> The latter sentence _incorrect_, and seems to be a show-stopper of a
kind.

With IPv4 ARP the link-layer address in Request is stored in the cache,
and this is in fact one away to perform ARP spoofing.  The same applies to 
solicitations, as below:

RFC2461, 7.2.3:

                        If the Source Address is not the unspecified
   address and, on link layers that have addresses, the solicitation
   includes a Source Link-Layer Address option, then the recipient
   SHOULD create or update the Neighbor Cache entry for the IP Source
   Address of the solicitation.  If an entry does not already exist, the
   node SHOULD create a new one and set its reachability state to STALE
   as specified in Section 7.3.3.  If an entry already exists, and the
   cached link-layer address differs from the one in the received Source
   Link-Layer option, the cached address should be replaced by the
   received address and the entry's reachability state MUST be set to
   STALE.

RFC2461, 6.2.6:

   Router Solicitations in which the Source Address is the unspecified
   address MUST NOT update the router's Neighbor Cache; solicitations
   with a proper source address update the Neighbor Cache as follows. If
   the router already has a Neighbor Cache entry for the solicitation's
   sender, the solicitation contains a Source Link-Layer Address option,
   and the received link-layer address differs from that already in the
   cache, the link-layer address SHOULD be updated in the appropriate
   Neighbor Cache entry, and its reachability state MUST also be set to
   STALE.  If there is no existing Neighbor Cache entry for the
   solicitation's sender, the router creates one, installs the link-
   layer address and sets its reachability state to STALE as specified
   in Section 7.3.3.  Whether or not a Source Link-Layer Address option
   is provided, if a Neighbor Cache entry for the solicitation's sender
   exists (or is created) the entry's IsRouter flag MUST be set to
   FALSE.

...

                             Note, however, that including these in the
   address requires the host to perform duplicate address detection for
   each address configured on the interface, not just for the link local
   address, as is allowed by RFC 2462.

==> right, so RFC2462/RFC2461 is being changed in this regard when it 
comes to SEND-secured links.  I think it may be appropriate to say this 
explicitly, even create a new section of Neighbor Discovery modifications.

   Delegation Chain Solicitations MUST NOT be sent if a valid
   certificate chain exists in the host's cache from the desired router
   (or host) to the host's trusted root.

   A host MUST send Delegation Chain Solicitations either to the
   All-Routers multicast address, if it hasn't selected a default router
   yet, or to the default router's IP address if it has already been
   selected.  If two hosts communicate with the solicitations and
   advertisements, these MUST be unicast to the hosts's address.

==> (and a few other places), I'm a bit confused on how certificate chains 
work between two hosts.  In some places, I get an impression that they are 
not supported at all, in some I get an impression that they're supported 
as an afterthought -- for example, the send paragraph would seem to imply 
("two hosts"...) that DCS/DCA could be done between two hosts but no DCS 
processing is specified for hosts.  This issue needs some serious 
rewording.

   o  If the cache becomes full, the receiver SHOULD temporarily reduce
      the Delta value for that source address so that all messages
      within that value can still be stored.

==> .. and discard messages outside of the new Delta, right?  Otherwise
the cache stays full until stuff in cache naturally expires, and the 
mechanism is useless.

   o  The packet, in the form defined for AH's coverage, is signed using
      the private key in the security association, and the resulting
      PCKS #1 signature is put to the Digital Signature field.

but earlier:

   Digital Signatures

      This variable length field, if present, contains the signature

==> in 7.1.5 text seems to say that PCKS#1 is always put to DS field, but 
earlier DS is not necessarily always present -- what's the deal?

==> editorial: "in the form defined for AH's coverage", perhaps this 
should be stated more explicitly?

   o  Hosts configured for SEND MUST validate all Router Advertisements
      with the protocol described in Section 8.  Note that this includes
      discarding advertisements received without a valid IPsec AH header
      and CGA address, thus making insecure prefixes invisible to them.

==> _and CGA address_ doesn't enhance my hope that CGA is only optional 
:-)

   o  Hosts configured for SEND MUST secure and validate all Neighbor
      Advertisements with the protocol described in Section 8.  Note
      that this includes discarding advertisements received without a
      valid IPsec AH header and CGA address.

==> note that this would seem to imply that if there are multiple nodes 
with the same layer 2 address, it will go undetected or cause A Great Deal 
of Trouble.  Also, theoretically CGA address and manually configured 
link-local address could clash, but this should not happen unintentionally 
due to different u/g bit settings.

   o  Routers MUST assign different addresses for their secure and
      insecure communications, including their link-local addresses.

==> Note that many none of router-only platforms I know of (IIRC) support
multiple link-local addresses.  Of course, this will change at the latest
with SEND ;-), but maybe something to keep in mind, operationally -- it
may not be as trivial as stated here.

   Signatures related to the use of the AH_RSA_Sig transform MAY be
   precomputed for Multicast Neighbor and Router Advertisements.
   Typically, solicited advertisements are sent to the unicast address
   from which the solicitation was sent.  Given that the IPv6 header is
   covered by the AH integrity protection, it is typically not possible
   to precompute solicited advertisements.

==> uh, what about Timestamps in the messages?  I guess if you time them 
just so (withing a sufficient delta), you can precompute them too, but I 
think this should be explicitly noted here?

Appendix C. IPR Considerations

   The optional CGA part of SEND uses public keys and hashes to prove
   address ownership.  Several IPR claims have been made about such
   methods.

==> "optional"?  It's not april fools yet :-)

Semi-subtantial/editorial:
--------------------------

   Section 5 describes the mechanism for showing address ownership,
   based on the use of Cryptographically Generated Addresses (CGAs).
   Section 6 describes the mechanism for distributing certificate chains
   to establish authorization delegation chain to a common trusted root.
   Section 7 describes the necessary modifications to IPsec.  Finally,
   Section 8 show how to apply these components to securing Neighbor and
   Router Discovery.

==> this should be expanded slightly, so that when reading the 
Introduction you would have a better picture of how the components a 
connected.  

The Address
      Autoconfiguration mechanism is stateless, where the hosts use
      prefix information delivered to them during Router Discovery to
      create addresses, and then test these addresses for uniqueness
      using the DAD procedure.

==> s/test/typically test/, it's not necessary!

   o  Router Advertisement: The destination address can be either a
      unicast or the All Nodes multicast address [1].  Like the
      solicitation message, the advertisement is also local to the link
      only.

==> The last sentence applies to all the messages here, I think, so the 
fact should be stated up front somewhere.

5. Cryptographically Generated Addresses

   Cryptographically Generated Addresses (CGAs) [22][23][20][25] are a
   technique whereby a node's IPv6 address can be unalterably tied to
   the node's public key.  

                  *        Conceptually, CGAs allow a recipient of a
   message to determine whether the sender is authorized to use the
   public key and address claimed to be associated with the packet.

   Typically, this requires the sender to use the hash of the node's
   public key as the interface identifier in the bottom 64 bits of the
   IPv6 address.

==> Even though there are a number of references, it might be useful (if
one can summarize in a paragraph of less than 5-10 lines) to describe why
exactly the sentence marked above is true.  This is because there are a
lot of bogus specifications and proclamations of security mechanisms (e.g.  
many papers on HIP) which neglect to mention that you really need
something like DNSsec to be secure, or the like.  In this case, it is good
to give very quick overview why such are *really* not needed.

   Equation (1).
       H(N) = Hash-160(public_key |
                       nonce |
                       routing_prefix)
       H(i) = Hash-160(H(i+1))

   where Hash-160 is the 160 bits obtained from applying the SHA-1
   secure hashing algorithm [12], public_key is the node's public key in
   the format defined in Section 7.1.2, and nonce is a random octet
   string of 8 or more bytes.  The selection N is a local matter, but it
   MUST be at least 3.  N is used as a defense mechanism against
   denial-of-service attacks.

==> in the equation I think you have to say that "nonce" = "N", or the 
like.  Some rewording on N may also be appropriate in the last two 
sentences.

                                                         The 'M' flag,
         when set, indicates that there are more components coming in
         this advertisement.

      Component

         This is a 15 bit unsigned integer field.  The first message in
         a multi-component advertisement has the Component field set to
         0, the second set to 1, and so on.

==> note that with 'M' flag, there is the obvious issue of packets getting 
reordered in the IP (or beneath) layer.  That is why "Component" is 
useful (which should be explicitly stated for clarity, perhaps).

==> I think the field would be better named "Component Number"
==> I assume on a single-component advertisement, Component is zero (it 
isn't stated above)?
==> The last sentence could also be reworded for simplicity like:

  The value of the Component field allocated sequentially, starting from 
  zero for each advertisement, to distinguish different parts of the
  original data.

(I wonder if that's any clearer though! :-)

  Valid Options:

      Certificate

      Trusted Root

==> swap the order of these options, as Trusted Root is described first so 
that they're in the same order.

 MUST be set to zero by senders and ignored by receivers

==> is this the usual way of saying MBZ? I've also noted ".. and MUST BE 
ignored", but one can read the "MUST be" to apply to both parts of the 
sentence..

      specification defines only one legal value for this field:  

==> I'd strike out "legal" everywhere in this context in the spec, it 
seems out of place here, with wrong connotations.

   A host MUST silently discard any received Router Advertisement
   messages that do not satisfy all of the following validity checks:

==> this a/RA/DCA/ was already noted it seems (in a few other places also, 
of course, under this subsection)

Delegation
   Chain Solicitations may be sent after any of the following events:

==> "may be sent" is slightly ambiguous: one should clarify that the list 
is not exhaustive, perhaps like (or simpler than that):

Delegation
   Chain Solicitations may be sent after any event that might affect 
local network connectivity, including but not limited to:

6.5:
   Rate limitation of Delegation Chain Advertisements is performed as
   specified for Router Advertisements in RFC 2461 [6].
6.6:

   Delegation Chain Solicitations SHOULD be rate limited and timed
   similarly with Router Solicitations, as specified in RFC 2461 [6].

==> The language in these should be similar.  The former approach seems 
better to me, but I'm indifferent.

  o  The sum of the PK_Len, Nonce_Len, and LLA_Len fields does not
      exceed the length of the Authentication Data field.

==> LLA_Len was never defined anywhere!

   It is outside the scope of this specification to describe trusted
   roots and address autoconfiguration (stateful or stateless) with
   dynamically changing addresses works.  It is also outside the scope
   of this specification to describe how stateful address
   autoconfiguration works with the CGA method.

==> s/describe/describe how/
==> s/works/work/ ?
==> "dynamically changing addresses" --> I assume you mean RFC3041, add a 
reference there, like "dynamically changing addresses, like [ref], work"

Editorial:
----------

2. Terms

   Cryptographically Generated Addresses (CGAs) A technique [22] where
      the address of the node is cryptographically generated from the
      public key of the node and some other parameters using a one-way
      hash function.

==> The formatting must be changed, e.g. make the term explanations go on 
separate paragraphs or something.

   o  Redirect: This message is always sent from the router's link-local
      address to the source address of the packet that triggered the
      Redirect.  Hosts verify that the IP source address of the Redirect
      is the same as the current first-hop router for the specified ICMP
      Destination Address.

==> s/Hosts verify/Host verifies/ (singular seems better) ?

      The new transform uses also a fixed, standardized SPI (Security

==> s/uses also/also uses/

   The authorization provide by CGA is computational in nature, deriving

==> s/provide/provided/

   information when the node needs this information before to
   communicate off-link.

==> s/before to/before being able to/

   selected.  If two hosts communicate with the solicitations and
   advertisements, these MUST be unicast to the hosts's address.

==> s/hosts's address/hosts' addresses/ (or something else like that, I 
don't know the intent)

   When processing a possible advertisement sent as a response to a

==> s/as a/in/ ?

   Digital Signatures

==> s/res/re/

  o  If the use of CGA has been specified in the security association,
      we additionally require that A node receiving an Neighbor or

==> "we .." -- use the passive voice for consistency with the rest of the 
doc.
==> s/A/a/

     parameter from the rightmost two bits of the Target Address.  If
      the interface identifier checks, the recipient proceeds with the

==> s/checks/check succeeds/ ?

10. Operational Considerations

   During the transition to secure links or as a policy consideration,

==> s/links/neighbor discovery/ ?

10. Operational Considerations

      addresses, including link local addresses.

==> s/link local/link-local/

   to use asymmetric transforms for a significant amount packets.

==> s/amount/amount of/

  recipient.  As a result both participants are forced to believe that

==> s/As a result/As a result,/ (not required but maybe good.)

Normative References

   [1]   Hinden, R. and S. Deering, "IP Version 6 Addressing
         Architecture", RFC 2373, July 1998.

==> s/S. Deering/Deering, S./ (similar to others where multiple authors)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------

---

From: Jari Arkko <[email-masked]>
Date: Sun, 09 Mar 2003 10:02:27 +0200

Thank you Pekka for your (as always) in-depth comments. This is a

> there are no omissions etc.

Agreed.

> ==> The latter sentence _incorrect_, and seems to be a show-stopper of a

Yes, and this is indeed the biggest problem in the protocol that I know
of at the moment. I think we mention it already in Section 14, by the way,
but we didn't have time to invent a solution. One approach would be to
avoid the solitications with an effect in SEND, but this would increase
the number of messages in typical situations, which would be unfortunate
for e.g. fast movements. More seriously, DAD would not work between two
nodes who are testing the same address at the same time. Also, we wouldn't
like to change the ND protocol as such.

So what's wrong with just protecting solicitations in the same manner
as advertisements? The reason is tricky. Consider the DAD probes, where
the solicitation message has the unspecified address as a source, and the
solicited node multicast address as a destination. The tested address
appears within the ND packet in the Target Address option. If our
security solution is at the IPsec layer, how can we test that the
tested address and the signature have been associated in the right
way? (Whether that association is through a cert with an address or
via CGA is not relevant, but IPsec needs to access the address which
for now only appears inside the application layer.)

> processing is specified for hosts.  This issue needs some serious 

Yes. One of our pre-00 versions only supported cert chains between a host and
a router, and the host to host case was indeed an afterthought. Unfortunately
we didn't have time to edit the specification to make it really clear
how it works between hosts.

> the cache stays full until stuff in cache naturally expires, and the 

That's right. Good point.

> earlier DS is not necessarily always present -- what's the deal?

This is a bug. The DS field must always be present.

> ==> _and CGA address_ doesn't enhance my hope that CGA is only optional 

Another bug in the text. CGA was indeed intended to be optional. Maybe
it should have read "... a valid IPsec AH header with AH-RSA-Sig transform"
or even "... a valid IPsec AH header".

> due to different u/g bit settings.

Hmmm... interesting. With GDT, do you mean that switches and the like
would "forward" packets incorrectly? I mean if the router would not
react in any way to someone claiming the same ll address as one of
the SEND nodes, that wouldn't by itself be bad?

> may not be as trivial as stated here.

Yes. I'm by the way not too happy with the current SEND transition
specification. It doesn't deal with routers belonging to just the
SEND or the non-SEND category, I'm not sure how it works with multiple
routers, the address thing you mention above is somewhat troublesome
etc. Good ideas sought...

> think this should be explicitly noted here?

Ah, a good point. I'm not sure we can precompute then.

> like.  Some rewording on N may also be appropriate in the last two 

But N is not the nonce. Maybe we should have used "K" and "nonce" instead.
"N" is a small integer number, and allows us to demand a sequence of hashes.
(Anyway, we probably shouldn't discuss these details before we take a
look at Tuomas' draft which IMHO defines the CGA addresses generation
formulas in a very clean manner.)

> ==> LLA_Len was never defined anywhere!

This a leftover of something we had in an earlier version. At that
time, we included even the link-layer addresses in the computations.
After the discussion on the IPv6 list, we no longer do...

Jari

---

From: Pekka Savola <[email-masked]>
Date: Sun, 9 Mar 2003 20:53:46 +0200 (EET)

Thanks for the quick response. Replying only to "left-over" issues.

> for now only appears inside the application layer.)

Perhaps an intermediate solution, if securing certain solicitations is too
tricky, to take some messages in the consideration *BUT* specify that
using such "possibly insecure" solicitations the neighbor discovery cache
MUST NOT be updated.

Another approach would be to modify IPsec processing even further, to make 
it associate the source address, in the case of unspecified, with the 
target address (if it exists) .. but this seems rather dirty a solution.
 
> would "forward" packets incorrectly? 

Yes.  (But I guess this is unavoidable, and happens even today.)

This seems to be a possible bigger problem if the SEND-router (also acting 
as non-SEND) would take a ll-addr clash into consideration.  I.e. when a 
SEND and non-SEND node claim they have the same ll address, who to 
believe?

> I mean if the router would not

With proper checks in router, this would seem to be ok.

(Note: in the SEND router implementations, you might need a toggle 
"allow SEND only" vs "allow SEND and ND interaction" -- in the first case, 
some things would get simpler.)

> etc. Good ideas sought...

Yes, I believe the transition part will require a lot of thought (whether 
in this document or elsewhere).  Too difficult to imagine all the 
situations just yet, though.
 
> Ah, a good point. I'm not sure we can precompute then.

Well, you can "precompute", strictly speaking, if you know when you'd be
sending the multicasts, *but* you have to compute every message *anyway*,
you just can influence when that precomputation happens (e.g. when you
need to compute, you could spread it even over a couple of seconds,
running on low priority, not when you're building the packet to send it
out).

Not that useful it seems, perhaps a bit to some very low-end devices.

---

From: "James Kempf" <[email-masked]>
Date: Tue, 11 Mar 2003 11:05:15 -0800

> for now only appears inside the application layer.)

Even if an IPsec header were put on, what would be the IP address of the SA? DAD
packets are sent with the unspecified address, as you indicate. This is a
problem with the IPsec approach v.s. the ICMP option approach, but we committed
to the IPsec approach now so it would be difficult to change.

Perhaps we could specify a "Secure Target Address" option that contained the
Target Address with a digital signature and the public key? This could be used
in the DAD case.

In the RS case, the packet is sent to the All Routers Multicast Address, but I
believe it can have the link local unicast address of the node. I could also
have the unspecified address, so the node could solicit a router before
performing DAD, but we could require a node to not use the unspecified address.
Or we could allow the "Secure Target Address" option in that case too, to allow
the unspecified address.

Note that if CGA addresses aren't used, the node receiving an NS with a Secure
Target Address option doesn't have any assurance that the sending node has a
right to claim the address, unless an authenticatable certificate is also
included in the NS.

            jak

---

From: Greg Daley <[email-masked]>
Date: Wed, 12 Mar 2003 09:11:44 +1100

Hi James,

I'm not sure that a new option is needed.

> Target Address with a digital signature and the public key? This could be used

I agree that it's not really possible to protect DAD NS's,
although care should be taken by nodes defending their
addresses with cryptography, that they are not depleted
of resources by doing so. (when we cannot guarantee the'
validity of DAD NS's).  DAD NA's are likely to be sufficiently
secured, especially when CGA is used.

As you mention, the src address is unspecified for DAD.
All NS packets which don't have a specified source address
MUST contain a Source-Link-Layer-Address-Option(SLLAO).

This option updates neighbor cache entries by default.
If no security is required on solicitations with SLLAO,
then existing 'secure' NC entries will be overwritten by
unsecured messages.

Requiring security on NS's which contain SLLAO avoids the
issue of unspecified address. This could allow similar mechanisms
to those used for NA to be undertaken, since a unicast source
address is available for an SA, and similar updates are made
to neighbor cache entries.

> right to claim the address, unless an authenticatable certificate is also

Similar to the previous suggestion for NS's, RS's SHOULD contain
SLLAO if they have a specified source address.  It is possible to
ensure that no insecure neighbor cache updates are performed solely
by requiring security for RS's if SLLAO is present.

Greg