Subject: Re: SEND "triggers": passive vs. active use

From: <[email-masked]>
Date: Thu, 18 Mar 2004 12:46:09 +0200

Pekka,

This is an important issue to discuss, but I believe
solutions go beyond simple triggers. Most importantly,
SEND already has a built-in backwards compatibility
mechanism specifically designed to address at least
parts of the issue.

Going a bit deeper to the details, I believe the
situation is as follows:

- Hosts can generally follow the current
  SEND specification as soon as they have support
  for it; they will still work in non-SEND environments,
  and generating addresses via CGA or via EUI-64 IIDs
  should not have a significant difference to others.

- There's two exceptions, however, and the first one is
  stateful address autoconfig.

  Currently we do not have a specification for SEND
  protection of addresses assigned by someone else.
  So for such addresses, the hosts should continue
  to use regular ND (even if they use SEND otherwise).
  I believe our specifications say this too, though
  I should check to see how clearly it has been said.

- The other exception is that to protect the RAs,
  there is a need to configure a trust root that
  the hosts can trust. This looks like another
  "use it when you have it" case. That is, when
  you don't have a trust root you'll just be
  using the non-SEND routers or SEND routers with
  a different root.

  I may have to check that this is clearly described
  in Section 8, but this has at least been the
  intent.

- For routers, I think the answer is similar:
  if you haven't been configured to use SEND
  yet and have the certs for it, you pretty
  much cannot do SEND. No big deal, hosts survive
  even in this case.

--Jari

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

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 18 Mar 2004 16:53:59 +0200 (EET)

Thanks for replies, all; I'll just respond to one message to reduce 
list traffic.

> mechanism specifically designed to address at least

Agreed.
 
>   should not have a significant difference to others.

Yes.

The critical question, which I was really grasping at, was whether 
there could be any drawbacks for enabling SEND support immediately.  
The obvious one is at least the computational overhead but that is 
probably acceptable.  Are there others?  

One particular issue that triggered this discussion at v6ops was the
proposal to use ND-proxy in the unmanaged ("home") environment if the
ISP would not give other than just a /64 prefix.  This raises a number 
of questions like:

 - is SEND applicable in this scope (might be, if the home has 
   non-bridged WLAN router, but the ISP is unlikely to support SEND 
   routing certificates in any case)?

 - would this break SEND so badly that that might lead to disabling 
   SEND in the OS's deployed at home?  We would not want SEND turned 
   off by default (I think)

The point here would be either:

 a) making sure that enabling SEND by default has no problems, and 
   could be done by the supporting implementations, or

 b) ensuring that sufficient "triggers" or other transition mechanisms 
    are in place so that even if SEND is not active by default, it 
    would at least be "dormant" for the case when it would be needed.

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

---

From: "James Kempf" <[email-masked]>
Date: Thu, 18 Mar 2004 09:46:07 -0800

Pekka,

Thanx for bringing up this point.

> probably acceptable.  Are there others?

The WG tried hard in the compatibility design to make it possible for SEND
and nonSEND nodes to work together on a link without any need for additional
configuration on either the nodes or the network, or triggers to require
SEND to be turned off. If you or anyone else sees anything that the WG
missed please by all means let the WG know soon, since the draft is about to
go to the IESG.

W.r.t. computational overhead, there is more overhead initially when
calculating a CGA address, but the additional per ND operation overhead if
the link has no certified router or other SEND nodes should be really
minimal, since it should be just RFC 2461 ND with a couple of checks for
additional options.

>    routing certificates in any case)?

If the ISP only gives a /64 prefix, then the ISP's router would need to
provide a certificate for router discovery security. But the nodes could use
CGA for ND security among themselves, which would not require any action on
the part of the ISP.

 Not sure what your point is about a non-bridged WLAN router.

>    SEND in the OS's deployed at home?  We would not want SEND turned

Ignoring the issue of ND-proxy for the moment - that is, assuming the home
nodes are communicating directly to/from the Internet via the ISP's router -
the design is intended to have SEND nodes interoperate with nonSEND nodes,
including the router, without any hinderance.

>    could be done by the supporting implementations, or

This was the intent of Section 8 in draft-ietf-send-ndopt-04.txt. Of course,
the real test of whether the design's intent is met is when we hold some
interoperability tests and try it out. :-)

>     would at least be "dormant" for the case when it would be needed.

Again, the design is intended to have interoperation work without any
triggers or other transition mechanisms.

W.r.t. ND-proxy, as brought up in the thread on the IPv6 list during IETF
59, the difficulty is that the current ND-proxy draft in the IPv6 WG assumes
the proxy is basically an L2 device, so there is really no way for a "proxy"
SEND, should one be designed, to be used, since there is no L3 entity on
which to anchor it. A L2 ND-proxy could, of course, strip SEND ND options
off of RAs, in which case the RAs would be accepted by the SEND nodes as if
they had been sent by a nonSEND router. In any case, the L2 proxy shouldn't
affect SEND for nodes performing ND address resolution on the same side of
the proxy, and packets to nodes with L2 addresses on the other side of the
proxy would have to go through the router anyway because their L2 addresses
would not be visible through the proxy, though SEND could presumably be used
on packets sent for DAD.

            jak

---

From: Jari Arkko <[email-masked]>
Date: Thu, 18 Mar 2004 21:32:07 +0200

Pekka,

The starting point of the SEND design has been that it
should work in a mixed environment, including the case
where you are the only node supporting it. The specification
does allow you to configure yourself as strictly SEND-only,
but the default is required to be the mixed mode.

The mixed operation has been described Section 8 of the
specification, and is based on individual default router
and neighbor cache entries. This means that you will be
able to benefit from SEND on a communication with another
SEND node while not preventing communications with a non-SEND
node that has a different address. Similarly, if you use
both stateless and stateful autoconfiguration, you will
be able to use both addresses, just that only the ones
coming from stateless can benefit from SEND (until we
publish an extension for DHCP/home agent/proxy case).

This implies that most of what you appear to require
should work in the current specification. Take a look
at Section 8 and tell us if something is missing.

But I'd like to understand your example better to
determine what you are worried about. Who is the
proxy in this case and where is the router?

If there is an ND proxy and you mistakenly configured
your hosts to be strictly SEND-only, then you have
a problem. But as explained above, this is not
recommended.

In the default use-SEND-if-possible configuration, the
proxy is not an issue for communicating between SEND
and non-SEND hosts and routers. Depending a bit on
how the proxy is provided, it may or may not have an
effect on SEND node to SEND node communications, however.
If the proxy just modifies the link layer address in
the ND message, this would be seen as an attack, and
the message dropped. If the proxy sends its own ND
message or strips off the SEND options, this would
be seen simply as a non-SEND ND message and communications
would be possible, albeit without protected ND. How much
current deployment is there for IPv6 capable ND proxies,
and what do they do? Draft-thaler-ipv6-ndproxy-01
does not talk about this, nor the use of AH, maybe
it should...

The only other problematic case that I can think of is a
SEND mobile node on a home network, moving off somewhere
else, which would cause other nodes on the link to
not respect the home agent's claim of ownership.
However, this can be dealt with by having the mobile
node not use SEND in its home network for its home
address (until the extension for the proxy case is
available). Perhaps this is something that should
be mentioned in the current SEND specification.

--Jari

---

From: Pekka Savola <[email-masked]>
Date: Sun, 21 Mar 2004 16:47:18 +0200 (EET)

Again, just replying to one message, to avoid a message flood.

I added Dave Thaler in Cc: just in case. (We're discussing ND-proxy + 
SEND scenarios..)

> at Section 8 and tell us if something is missing.

Right.  This appears to be fine.

> proxy in this case and where is the router?

For example:

                                      /-- ND node A
                                     /--- SEND node 1
                                    / eth0  /-- SEND node 2
  [ISP router] --- p2p link --- [ND-proxy] ---- SEND node 3
                                            \-- ND node B

In this case, SEND would work out of the box between SEND nodes 2 and 
3.  If ND-proxy didn't strip off SEND options (i.e., just modified the 
L2 information), communication between SEND node 1 and {2,3} would 
fail without fallback.  Communication between any SEND and any ND node 
would work still.

Another case would be:

                                             /-- ND node A
                                      [WLAN]/--- SEND node 1
                                           /      /-- SEND node 2
[ISP router] --- p2p link - [ND-proxy] -- bridge ----- SEND node 3
                                                   \-- ND node B
                                                [wired eth]

.. where the sole purpose of ND-proxy would be to be able to extend a
/64 subnet provided by the ISP to the home network when the p2p link
and the home network would have dissimilar media that bridging them
would be impossible (PPP + Ethernet?).

In this scenario, SEND would work inside the network with everyone --
It would not work with the ISP router if it supported SEND though (but
in that case, the ISP might probably be offering prefix delegation in
any case).

> the message dropped. 

Right.

> If the proxy sends its own ND

Agreed.  Stripping off would make the communication work (I think, may 
need some analysis?) but would disable SEND.  So, if ND-proxy and SEND 
is a concern, maybe this would be a workaround; something to consider 
for ND-proxy document.