Subject: SEND "triggers": passive vs active use?

From: Pekka Savola <[email-masked]>
Date: Wed, 17 Mar 2004 17:45:50 +0200 (EET)

Hi,

During discussion of ND-proxy applicability w/ send at v6ops, an open
issue in SEND came up: what is the deployment model of SEND?  Is it
practical?

That is, I think we'd like the vendors to turn on SEND by default if 
they implement it, right?  But at the same time, it might take quite 
long before SEND is widely enough deployed that actively using it 
would make sense.

I don't quite remember how it is in the document, but it struck me 
that one possibility (if an "active model" would not be deemed useful) 
would be to have a "trigger" of a kind.  SEND would be active, but not 
used -- until some activity triggers it.  Such trigger could be e.g., 
receiving a SEND-enabled router advertisement, or CGA-signed Neighbor 
Discovery packet.

The idea here would be to make sure SEND is enabled and out there, 
in "passive" mode -- preserving resources and hassle until it's 
actually needed.

These are quite raw thoughts for now, but perhaps this might trigger 
some discussion on the transition to SEND.

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

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: "James Kempf" <[email-masked]>
Date: Wed, 17 Mar 2004 09:34:28 -0800

Pekka,

For hosts, I think it should be possible to have SEND be on by default,
since it has been designed to be completely backward compatible. Section 8
of draft-ietf-send-ndopt-04.txt describes that.

For routers, it's a bit more complicated since the router must be configured
with a certificate. This requires the network provider to take some action
to actually enable SEND for router authentication. This also requires the
host to have a suitable certificate for the common trust anchor. Many
operating system platforms now have certificate management systems that
contain a collection of certificates for various CAs used in SSL, so these
can be leveraged without requiring any host configuration, but a certificate
closer to the network provider's CA that would require configuration can
reduce the size of the certificate exchange and is obviously preferable.

Not sure if this answers your question?

            jak

----- Original Message ----- 
From: "Pekka Savola" <[email-masked]>
To: <[email-masked]>
Cc: "Erik Nordmark" <[email-masked]>
Sent: Wednesday, March 17, 2004 7:45 AM
Subject: SEND "triggers": passive vs active use?

> 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: Greg Daley <[email-masked]>
Date: Thu, 18 Mar 2004 10:37:36 +1100

Hi Pekka,

> some discussion on the transition to SEND.

As a deployment issue, you're right: there won't be many devices
using SEND initially, so there may be a requirement to fall back to
ND in the case that no-one is doing SEND.  We'll need to be careful
that decisions about this don't leave hosts with a mechanism where
other devices can cause them to turn off SEND though.

I'd guess that when operating within a particular network, it is
fairly straightforward:  Once you receive an authorized RA with a
SEND signature in it, SEND should be run on the host.

I'd guess that hosts may wish to use SENDC before then
though, for the purpose of mutual authentication with other SEND
devices on the link.

Also, it may not make sense to delay generation or utilization of
CGAs until SEND authorization occurs (especially for link-local).

There are also devices which will be moving around between different
IP links/subnets, though.  These won't have a choice as to whether
SEND is turned on for a particular router or subnet.

In the case that SEND is on for one router, it doesn't imply that SEND
should be used on nearby subnets.  We may see a situation where
a host has had SEND operation on one subnet, and ignores
router advertisements on a new subnet because of that.

Checking reachability to the current SEND router may be one mechanism
which is useful to ensure that we are still connected to a subnet
(so unsecured ND messages can't override SEND messages), but when
the host has moved, or the SEND router has died, this may take a long
time with existing NUD/SEND Timestamp techniques.

So it may also be necessary to "trigger (?)" switching SEND off in
some cases.  These devices may know about their wireless connectivity
(for example upper later (secured?) packet reception halts, Link layer
information suggests change...), and would have to reset the ND state,
including potentially security.

---

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

Greg,

Please read Section 8 of draft-ietf-send-ndopt-04.txt and let the WG know if
you see anything there that would require SEND to be turned or "triggered"
off on a network where the router or any of the other nodes do not support
SEND. The intent of the design is that SEND nodes should "just work" with
standard RFC 2461 nodes (including routers).

            jak

----- Original Message ----- 
From: "Greg Daley" <[email-masked]>
To: "Pekka Savola" <[email-masked]>
Cc: <[email-masked]>; "Erik Nordmark"
<[email-masked]>
Sent: Wednesday, March 17, 2004 3:37 PM
Subject: Re: SEND "triggers": passive vs active use?

---

From: Greg Daley <[email-masked]>
Date: Fri, 26 Mar 2004 16:10:03 +1100

Hi James,

It's not text, but here are some ideas about the section.

I think that the rules which ae defined in section 8
are basically OK.

I'm still unsure whether we believe a SEND router
is secure just based on the signature option, since
when we arrive on the network, we don't necessarily have
a delegation chain for that router.   For the first
0-500ms, we has essentially an "unsecured router".

The rules in section 8 are sound and don't leave holes in the case
that a host moves for non-SEND routers, although it looks
like this implies the standard reachability testing from ND (NUD).

The second last dot point indicates that we should select
reachable SEND routers over reachable non-SEND routers (and
there are similar explanations for ND). This is the trigger
to switch on SEND for Router Discovery.

I'd guess that this implies that we want reachable non-SEND
routers over unreachable SEND routers.
This may be the switch-off for SEND, but may have to be
specified.

If we want to talk a bit more about SEND router/neighbour
reachability, it may be possible to keep some reachability
state for a SEND router until  we've checked that it isn't
in fact reachable, but allow usage of a non-SEND router in
the case we have other reliable information which can be used
for change detection (This is starting to sound a little
like DNA though).
For example this could be our own link-layer telling us about
arrival on a new LAN segment.

The current non-SEND to SEND transition case needs some checks,
since a signed CGA addressed router advertisement may take
routing away from a legitimate non-SEND router, without using
any authorization information. This is worse than the current state
since it occurs without NUD checks for the current router.

Perhaps this is one strategy:

??

A host MAY treat unauthorized SEND routers as insecure,
but allow temporary adoption of insecure routers
(including non-SEND routers) while authorization
is being checked. This SHOULD only be done if
the host believes there may have been a link or L2 change.
This aims to prevent overriding a good SEND config
with an unsecured one.

Checking authorization in this case is the determination
of delegation information for SEND, or the unreachability
of the currently configured router (whichever
is determined sooner).

This may cause a temporary state change of state
such as:

1)  default router configuration

2)  neighbour cache state for the configured router

Packets sent to these unsecured routers may be lost or subverted
to other addresses or used for man-in-the-middle attacks.

Care should be taken to ensure that any routing state
changes can be rolled back in the case of current router
indicates its reachability.

In the case that the unreachability of the current router
router is determined, such changes MAY be committed,
and a unsecured or non-SEND router adopted as current.

Otherwise, only authorized SEND router advertisements can override
existing SEND configurations.

??

I'm not sure if this preserves the same security
properties in the general case, though.

In this case, we'd need two indicators (flags?): one for signed
NC messages, and one for router authorization.
reception of a signed NC message wouldn't be sufficient to
override the (signed, authorized) SEND router.

Currently there's only a 'Secured' flag. Which may be misleading.

Greg

---

From: "James Kempf" <[email-masked]>
Date: Fri, 26 Mar 2004 09:07:38 -0800

Hi Greg,

Thanx for taking a look at the draft.

> 0-500ms, we has essentially an "unsecured router".

If speed is not at issue, the node can use DCS/DCA in order to solicit a
delegation chain if it doesn't have one. If speed is at issue (as in a
handover situation), then the node should obtain the certificate chain prior
to moving using something like CARD.

Alternatively, as we discussed on this list earlier, the ISP can provision
the access network routers with the same certificate, as some Web services
do with duplicate servers, with correspondingly more risk in the event of
compromise. Then a mobile node would not need to obtain any additional cert
chain information unless it moved outside of the access network.

I don't see this as any different than any other security protocol, in which
there is some time up front in which both sides don't trust each other, then
they negotiate via a procedure whereby they prove their trustworthiness. So,
in a sense, you are right that for an initial period, the router is not
known to the node to be trustworthy, but that is not much different than any
other security situation. How long it takes depends on the amount of
preconfiguration available.

It is true that the node doesn't have the opportunity to do a CRL check
prior to accepting the signature, but this is unavoidable, since the node
does not, at that time, have a connection to the Internet. The spec says
that the node should perform certificate revocation checking as soon as
possible afterwards and terminate using the router if the check fails or
fails to complete. So there will be some period of time in which the node is
using the router but has not yet verified the revocation status of the
router's certificate.

> like this implies the standard reachability testing from ND (NUD).

The SEND spec is not concerned with the basic discovery procedure of 2461.
In that sense, it is different from DNA.

> to switch on SEND for Router Discovery.

Essentially, yes.

> This may be the switch-off for SEND, but may have to be

Doesn't this cover it:

   o  The conceptual sending algorithm is modified so that an insecure
      router is selected only if there is no reachable SEND router for
      the prefix.  That is, the algorithm for selecting a default router
      favors reachable SEND routers over reachable non-SEND ones.

How about adding this as a bullet to the list:

    o A node MAY adopt an insecure router, including a SEND
       router for which full security checks have not yet been completed,
      while security checking for the SEND router is underway. Security
      checks in this case include delegation chain solicitation, certificate
      verification, CRL checks, and RA signature checks. A node
      MAY also adopt an insecure router if a SEND router
      becomes unreachable, but SHOULD attempt to find a SEND
      router as soon as possible, since the unreachability may be the
      result of an attack. Note that accepting an insecure router
      opens the node to possible attacks, and nodes that
      choose to accept insecure routers do so at their own risk. The node
      SHOULD in any case prefer the SEND router as soon as
      a new SEND router appears and security checks are complete

I think we should leave out the L2 change part because this might also be
useful for fixed hosts. I also don't think we need to delineate the attacks,
since they are described elsewhere.

> Currently there's only a 'Secured' flag. Which may be misleading.

Where would flags be necessary?

            jak

---

From: Greg Daley <[email-masked]>
Date: Mon, 29 Mar 2004 10:16:08 +1000

Hi James,

> Thanx for taking a look at the draft.

That's OK. SEND's one of the most interesting
technologies around.

> chain information unless it moved outside of the access network.

I'd actually be loathe to put this into a specification though.
There are better ways to do this.

> using the router but has not yet verified the revocation status of the

I agree.

There's a tradeoff between preconfiguration, speed and trust
which may come up.  Describing some of these issues may be
relevant to do in DNA, though.

>       favors reachable SEND routers over reachable non-SEND ones.

I think it does, but there the duration to determine unreachability
is a lot longer than to determine reachability (for example
if we move subnets).

In this case, we may have received messages from devices
purporting to be routers well before we time-out on our NUD tests.

Alternatively, if there was some extra information in a router
advertisement which implies the old router's unreachability
(like a link identifier) then there may be an indication of
unreachability which hasn't been confirmed.

Indicating that there may be situations where you'd like to
use the unsecured router though makes sense.
I think discussions of the timing/tradeoffs are best made
elsewhere.

>       a new SEND router appears and security checks are complete

This looks good.

> since they are described elsewhere.

Indeed.

> Where would flags be necessary?

Don't worry, I was guessing that the 'secured' indication used
prevuiously was just the RA signature check (which is immediately
available and didn't include the authorization which isn't).

Your new text block clarified that.

Greg