Subject: Re: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility

From: Greg Daley <[email-masked]>
Date: Sun, 11 Jul 2004 22:12:22 +1000

Hi Mohan, 

I think I've only half answered your question

Please see below.

...
> If MIPv6 is deployed in an enterprise, the trust is sufficient
> enough to not require proxy ND i guess.
...

I actually think this is a big problem: 
assuming that devices on the home link are
secured.

Typically, I'd ask the question:
How many viruses attack other hosts from inside
the corporate firewall?

It's reasonable to expect that any attack is
possible. I heard of an attack a long time ago
which used ARP spoofing and SNMP to destroy 
a certain brand of router's configuration.

The attacker needed to be on-link.

Nowadays in IPv4, a single person receiving an e-mail attachment can cause grief for anyone on the link (or on multiple links), by scanning or
multicasting to all IP addresses in the subnet.

My guess is that with IPv6 on-link address suffixes
using (typically) 64 bits, attackers will need to
use multicast to identify other nodes on-link, or
monitor exchanges such as ND to identify and
attack victims.

Of course, this is likely not to be a problem
for the short term, nor may it be explicitly
related to Proxy Neighbour Disocvery and its
use in MIPv6.

Greg

--------------------------------------------------------------------
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: "Mohan Parthasarathy" <[email-masked]>
Date: Sun, 11 Jul 2004 15:09:54 -0700

> ...                                ^^^
Just to clarify :  "secure"  was missing above.

> assuming that devices on the home link are
What do you mean by "secured" ? SEND or something else ?

> monitor exchanges such as ND to identify and
I am not sure i understood all of it. A virus infecting a machine that uses SEND
can enjoy all the benefits of SEND. How does SEND prevent the virus from
spreading ? Perhaps, i am missing something here.

I agree that if the enterprise adopts SEND for some reason, then when it deploys MIP6,
for the same reason it may also want to secure proxy-ND also. But it will be
interesting to see how and when enterprise begins to deploy SEND.

> related to Proxy Neighbour Disocvery and its
-mohan

---

From: Greg Daley <[email-masked]>
Date: Mon, 12 Jul 2004 09:25:18 +1000

Hi Mohan,

Perhaps I may have used some
unclear terminology...

> Just to clarify :  "secure"  was missing above.

OK.

> What do you mean by "secured" ? SEND or something else ?

Actually, I was talking about the concept
that people assume that once you're firewalled
off from the Internet, that robust security measures
don't need to be applied.

SEND helps provide robustness, because it is harder to
break another's neighbour cache entries.

>>Nowadays in IPv4, a single person receiving an e-mail attachment can cause grief for anyone on the link (or on multiple links), by
> 
> scanning or
> 

The SEND device which is infected has all of the abilities
of a SEND node:

It can create neighbour cache entries for itself, and solicit
others to advertise (that's all).

Compromising a SEND node only allows the SEND node to change
state related to itself.

If nodes on the link didn't use SEND, a compromised node could
attack any Neighbour Cache Entry it saw fit by generating bogus
packets.

The same issue exists for any node compromised when insecure
proxy ND is available.

> interesting to see how and when enterprise begins to deploy SEND.

I think that SEND's costs are all to do with authorizing routers
and configuring hosts to recognize at least one trust anchor.

If an organization can set up certificates for Router Discovery,
protecting on-link communications using SEND/CGA comes almost
for free (except managing DNS records).

Greg

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 12 Jul 2004 19:00:26 -0700

<snip>
> The same issue exists for any node compromised when insecure
Ok. But for this to work, you can't have a mix of SEND and non-SEND nodes.
I am not sure whether it is realistic to transition completely to SEND.

> for free (except managing DNS records).
With the approach that you wrote up in this thread, you need certificates
for NS/NA also if i am not mistaken. Are there any specific reasons why
current SEND does not use non-CGA approach for NS/NA ? From section 4
of SEND:

      This specification also allows a node to use non-CGAs with
      certificates to authorize their use.  However, the details of such
      use are beyond the scope of this specification.

-mohan

---

From: Greg Daley <[email-masked]>
Date: Tue, 13 Jul 2004 12:22:39 +1000

Hi Mohan,

> I am not sure whether it is realistic to transition completely to SEND.

Actually non-send nodes will never see the SEND options, so
it may be possible to be backwards compatible with them
(as is already done in SEND).

The actual resources devoted to non-SEND nodes can be restricted,
and the main thing is that SEND advertisements cannot be overwritten
with a non-SEND advertisement.

>       use are beyond the scope of this specification.

I think that people were considering what may be necessary in the
future (alternative security mechanisms such as ABKs, for example)
and also the need for proxying, which was not unheard of at the time.

What we need to see is if the security for proxying is needed,
particularly that there are valid scenarios where PND needs to
be done.

Greg

---

From: "James Kempf" <[email-masked]>
Date: Tue, 13 Jul 2004 09:01:24 -0700

> with a non-SEND advertisement.

Right, I'm not sure exactly what led to that conclusion, Mohan. The SEND
spec supports both secure and insecure nodes on the same link. A node can be
configured to accept or reject nonsecured NAs and RAs. If the node rejects
nonsecured NAs and RAs, then there shouldn't be a problem with proxies if
they are secured. Am I missing something?

> particularly that there are valid scenarios where PND needs to

Actually, there are a couple issues with address certificates for hosts:

1) Host certificate provisioning is one of the thorniest issues in IP
security. In general, it hasn't really proven to be widely deployable, and
many equate it with the "global PKI" bogie. The solutions (like TLS/SSL)
that have been widely deployed primarily involve cert provisioning of
network entities like servers. In the SEND case, the base spec only requires
the routers to be provisioned. Hosts only need root CA certs. Since there
are far fewer routers than hosts, ISPs don't have to go the the difficulty
and expense of running a PKI for all their customers, just for their
internal equipment.*

2) Even if host certificates were easy to provision, it is not exactly clear
how one would indicate in the certificate that a particular host is entitled
to a particular IP address. An extension or something, like the address
prefix extension for routers, would be one way to go. But the extension
probably wouldn't give the entire address, probably just the MAC address
used to form the interface identifier (Mobile IP home addresses might be an
exception). That way, the certificate could be used with a variety of subnet
prefixes. However, the MAC address isn't controlled by the IETF, and very
few MAC layers provide such certs (I think Cablelabs and 802.16 do). And, in
addition, there's DHCP to consider. The base SEND spec doesn't include
support for DHCP, since CGAs are autoconfigured, but any spec using certs
should.

So, given these deployment issues, the SEND WG decided to punt on address
certs for now, until its clear whether people are actually willing to
implement and deploy the technology. The base spec allows address certs, but
it doesn't provide any details about how to use them. Again, if there's
interest, it can be done later.

        jak

*Small plug for my employer: Docomo runs a PKI called FirstPass that allows
all FOMA hosts to be provisioned with a certificate for bidirectional TLS
authentication.

---

From: Greg Daley <[email-masked]>
Date: Wed, 14 Jul 2004 10:44:40 +1000

Hi James,

James Kempf wrote:
[chop]
> interest, it can be done later.

Please don't think I'm "teaching you to suck eggs" (instructing
you in what you already know), but just clarifying if we're on the
same path.

I'd guess that the principle difference is that CGA's provide
sufficient proof of ownership for ND (since we're adjacent to
the device, and the prefix is one of a small set we're interested
in).

In proxy neighbour discovery the assumption is modified a little,
allowing devices which aren't present to be advertised, but only
through a currently existing local SEND node.

Using CGAs as the start of authority for securing PND seems to be
an appropriate step considering the existing setup in SEND.
certificates prove that the CGA owner (through the included public
key and signature) has delegated its authority itself.

This removes a requirement for central control of the certificates.

Does this sound alright to you?

> all FOMA hosts to be provisioned with a certificate for bidirectional TLS
we know who to address all the PKI questions to then....

Greg

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 13 Jul 2004 19:19:04 -0700

> they are secured. Am I missing something?
No. But SEND nodes have to accept NAs from non-SEND nodes
in a mixed mode environment. So, it is possible that you receive the
insecure NA, send the queued packet, receive the secure NA, overide the
NCE with information from secure NA. I don't know what that one packet
can do. Anyway, i am a bit confused about how this relates to the original
virus attack that Greg explained..

> to a particular IP address. An extension or something, like the address

Hmm.. if i have the right private key, isn't that sufficient that i own the
address on the certificate ?

> interest, it can be done later.
Thanks for the clarification..

-mohan

---

From: Greg Daley <[email-masked]>
Date: Wed, 14 Jul 2004 13:17:26 +1000

Hi Mohan,

Mohan Parthasarathy wrote:
>  
> 
> 
>>>>>>I am not sure i understood all of it. A virus infecting a machine that
>>>>>
>>uses SEND
>>
>>>>>>can enjoy all the benefits of SEND. How does SEND prevent the virus
>>>>>
>>from
>>
>>>>Ok. But for this to work, you can't have a mix of SEND and non-SEND
>>>
>>nodes.
>>

Sorry, It seems we've strayed a bit from there.

OK.  The virus infected machine can transmit both SEND and non-SEND
NS or NA's.  In some of the most important cases though, existing
devices won't believe the non-SEND transmissions from a host.

This is because non-SEND NC entries cannnot override SEND NC entries
(and are overriden in return), and where no non-SEND host exists,
no neighbour cache creation matters unless it is for a SEND host
(other creation is just an attempt to steal resources and may be
controlled by limiting available resources).

Almost no ND hosts will not create a neighbour cache entry from
an unsolicited NA.

If an uncompromised solicitor transmits a SEND NS, it may accept
an NA from an unsecured attacker, but if the SEND host is present
on the link, it will receive the NS and respond with a SEND NA
almost immediately.

Similarly, once an existing SEND neighbour cache entry exists,
it cannot be overridden by a non-SEND NC entry.

I guess it may be possible to set the NC entry from an unsolicited
unsecured NS containing the SLLAO.  In this case, the SEND neighbour
will attempt to do NS/NA exchange with 5 seconds after packet
flow begins on that interface, if the NC entry hasn't been updated to
reachable in the interval.  When the NS from the SEND node goes out,
any existing SEND device which owns this address will crush the
attacker's fake NC entry.

It may be important to see how such upper-layer confirmations are 
provided for unsecured NC entries.  I'd guess that a SEND node may
not believe in upper layer confirmations until it has seen a
(real) solicited NA from the unsecured host in response to one of
its NS's.

I'd have to check the existing SEND draft to see how this is covered...
Hmmm. it's not.

For the SEND NS/NA transmissions which a compromised device makes,
they only refer to itself (as specified but the public key, signature
and CGA).

>>>>>>I agree that if the enterprise adopts SEND for some reason, then when
>>>>>
>>it deploys MIP6,
>>
>>>>>>for the same reason it may also want to secure proxy-ND also. But it
>>>>>
>>will be
>>
>>>>With the approach that you wrote up in this thread, you need
>>>
>>certificates
>>

Yes, but how did you get the certificate?

universal PKI has a chicken and egg problem.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 14 Jul 2004 07:32:11 +0300

> Does this sound alright to you?

This sounds right.

--Jari

---

From: "James Kempf" <[email-masked]>
Date: Wed, 14 Jul 2004 09:36:39 -0700

> virus attack that Greg explained..

OK, I think I understand. You're concerned that a node might first accept an
insecure NA from an attacker, then later get a secure NA. I agree that's a
problem if acceptance of insecure NAs is turned on, but turning on
acceptance is at the option of the user.

Regarding Greg's virus attack, I'm not familiar with the details of how ARP
spoofing is used, but SEND is designed to counter the threat of ARP spoofing
(ND spoofing on IPv6 I guess).

            jak

---

From: "James Kempf" <[email-masked]>
Date: Wed, 14 Jul 2004 10:35:00 -0700

Yes, this sounds like a start.

Address certs for hosts are a separate issue, also potentially valuable, but
not to be confused with PND. It would be useful if whatever mechanism was
developed for PND security would cover both CGAs and address certs, as I
believe we tried to do with some of the basic mechanisms in the base SEND
draft.

            jak

----- Original Message ----- 
From: "Greg Daley" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Mohan Parthasarathy" <[email-masked]>; "Vijay Devarapalli"
<[email-masked]>; "Jean-Michel COMBES"
<[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Tuesday, July 13, 2004 5:44 PM
Subject: Re: RE : Problem of interaction between SEND(CGA) and the IPv6
mobility

---

From: "James Kempf" <[email-masked]>
Date: Wed, 14 Jul 2004 10:38:59 -0700

Greg,

The draft is currently in revision based on IESG feedback. If you want to
raise an issue about upper layer confirmation, now's the time to do it. If
you do, please give very specific text describing how to handle it and where
in the draft the text should be inserted. Random discussion on the issue
isn't what we need right now.

Thanx.

            jak

----- Original Message ----- 
From: "Greg Daley" <[email-masked]>
To: "Mohan Parthasarathy" <[email-masked]>
Cc: "James Kempf" <[email-masked]>; "Vijay Devarapalli"
Sent: Tuesday, July 13, 2004 8:17 PM

---

From: Fred Templin <[email-masked]>
Date: Wed, 14 Jul 2004 13:37:25 -0700

Based on my loose interpretation of these discussions, it seems as
if an unsolicited SEND NA might be useful as an authenticated
mechansim for informing a neighbor of an L2 address change.
Is my understanding correct on this?

Thanks - Fred
[email-masked]

---

From: Fred Templin <[email-masked]>
Date: Wed, 14 Jul 2004 13:56:58 -0700

Hmm... I guess for routers, an unsolicited SEND RA with
an SLLAO and sent to an IPv6 unicast address will do
pretty much the same thing - right? I guess I'd better
go off and take a closer look at the specs now...

Fred
[email-masked]

---

From: Greg Daley <[email-masked]>
Date: Thu, 15 Jul 2004 13:02:55 +1000

Hi Fred

> Is my understanding correct on this?

Yes,  although it will only update existing NC entries.

Where unsolicited NAs are multicast, they'll
update any of the  neighbour cache entries for hosts
where they're received, if they have enough SEND foo to
do so.

Greg

---

From: Greg Daley <[email-masked]>
Date: Thu, 15 Jul 2004 13:08:51 +1000

Hi Fred,

> go off and take a closer look at the specs now...

Yes, the routers will probably do unsolicited RAs
anyway though.

The difference between the unsolicited NA and the unsolicited
RA is that hosts will probably create a neighbour cache entry
for the unsolicited RA, whereas only existing NCEs will be
updated with the unsolicited NA.

If we're talking proxyND, the unsolicited NA (override flag set)
should do the trick if there's been a link-layer change caused
by a node moving away, or the proxy being changed.

Greg

---

From: Greg Daley <[email-masked]>
Date: Thu, 15 Jul 2004 10:20:05 +1000

Hi James,

> isn't what we need right now.

I understand, but haven't read through the latest
draft (pre-06) in depth yet.

I'll try to get text if there's a good space for it.

(the randomness comes easier at first.
In fact I only thought of the issue as
I was composing the e-mail).

Greg

---

From: Fred Templin <[email-masked]>
Date: Thu, 15 Jul 2004 10:11:56 -0700

Thanks Greg,

Looking at RFC 2461 (and, reversing the order of things a bit)
what actually seems more clear to me now is that a SEND RS
with a source address other than the unspecified address and
an SLLAO will certainly update the router's NCE.

So, a node that changes its L2 address can certainly update the
NCEs in any routers right away by sending them SEND RSs.
(Getting an RA back would provide good evidence that the
L2 address change has been registered.)

Regards - Fred
[email-masked]

---

From: Greg Daley <[email-masked]>
Date: Fri, 16 Jul 2004 15:40:13 +1000

Hi Fred,

> L2 address change has been registered.)

This isn't exactly what I had in mind (link address change)
but the idea that you can push NC state to routers is
indicated in:

http://www.ietf.org/internet-drafts/draft-daley-ipv6-preempt-nd-00.txt

The main goal there was to provide new NCE's for global addresses
when we're expecting off-link data through routers using Mobile IPv6.

If the routers already have an NCE for you, then an unsolicited NA
also works.  This won't work in the Mobile IPv6 case though,
since the address is being used for the first time.

Greg

---

From: Fred Templin <[email-masked]>
Date: Fri, 16 Jul 2004 10:34:02 -0700

Greg,

> http://www.ietf.org/internet-drafts/draft-daley-ipv6-preempt-nd-00.txt

OK, but I guess what I'm looking (at least in terms of updating
a router's NC state) is sufficiently covered under RFC 2461
along with SEND/CGA extensions.

Thanks - Fred
[email-masked]

---

From: Greg Daley <[email-masked]>
Date: Mon, 19 Jul 2004 10:04:08 +1000

Hi Fred,

> along with SEND/CGA extensions.

Yes. The draft only describes how the existing behaviour
can be made use of.

Greg