Subject: Issue 14: Is CGA-only RD protection useful?

From: "James Kempf" <[email-masked]>
Date: Mon, 25 Aug 2003 11:57:18 -0700

Issue 14 received some discussion in Vienna. The question was raised by one
of the reviewers whether having CGA-only protection on RAs would be
sufficient for securing router discovery. This is independent of whether a
router would use CGA for neighbor discovery.

The best approach to an answer would seem to me to be to be to look at the
threats to RD in draft-ietf-send-psreq-03.txt and see whether CGA protection
will satisfy them. This email attempts that analysis.

Threats to RD are described in Section 4.2 of draft-ietf-send-psreq-03.txt.
The following threats are discussed:

1) Malicious Last Hop Router - the attacking node sends legitimate-looking
IPv6 RAs, or responds to a victim node's RSs with legitimate-looking IPv6
RAs, in an attempt to get the victim to use it as the default router.

2) Default router is 'killed' - the attacking node uses one of a variety of
means to spoof other nodes into believing that the default router on the
link has died, in which case, by RFC 2461, the nodes revert to using link
local addresses only. One of these means involves sending out a bogus RA for
the default router with lifetime 0.

3) Bogus On-Link Prefix - the attacking node sends a spoofed subnet prefix
to trick the victim into either using the prefix for an incorrect
autoconfigured address or into thinking that the prefix is on-link so that
the victim uses link local addressing instead of a global IPv6 unicast
address, by sending a legitimate-seeming RA.

4) Bogus Link Parameters - the attacking node sends bogus link parameters
(like whether or not stateful address configuration should be used) by
sending a legitimate-seeming RA.

The protection provided by CGAs is fairly simple: a receiver of a message
signed by the sender and verifiable with the sender's public key has the
assurance that the message was, in fact, sent from the CGA.

In the absence of any network element or any additional processing between
the router and the host, CGAs would seem insufficient to address all the
threats above, though they would address 2, since the victim could clearly
identify that the bogus RA did not issue from the legitimate default router.
A malicious host could construct a CGA from its public key and use its
private key to sign a bogus RA. The RA would be verifiable as issuing from
the correct IPv6 address, but the RA would contain bogus information
designed to launch an attack. Since there is no IP network element between
the host and the router in the standard IP subnet architecture, this would
suggest that CGA-only RD authentication is not sufficient to address all the
threats.

If, however, there exists a Layer 2 network element between the host and the
router that is programmable such that it can perform sufficient Layer 3
processing to cryptographically verify the RA signature and filter on the
CGA, then CGA-only RA security may be useful. The Layer 2 network element
could be programmed with an ACL of CGAs for known good routers, and only
pass RAs for those whose CGAs match the signatures and the ACL. Depending on
the Layer 2 technology and the network element, some part of the subnet may
still be vulnerable. For example, if the Layer 2 technology was multi-access
prior to the filtering device, some number of hosts may be exposed to the
bogus RA. Note that such a filtering device would still be subject to attack
if CGAs were not employed, since the device could not verify the RA as
issuing from the source address, providing an opening for an attacker.

The following are possible actions the WG could take w.r.t. resolving this
issue in the draft:

A) Since the IP subnet architecture does not admit of devices between the
host and router, the potential solution involving a Layer 2 filtering device
is not of interest in an IETF standard. Therefore, the draft should state
that CGA-only solutions are not sufficient for protecting RD in SEND.

B) As a practical matter, some Layer 2 technologies of interest support such
filtering devices, and adding the kind of Layer 3 filtering and network
management functions described above to such devices for CGA-only protection
is not all that difficult. Since a CGA-only solution may be simpler from a
deployment and network management perspective in some networks than
requiring routers to have certificates, the CGA-only solution should be
fully articulated in a separate section in the draft.

C) As in A), but mention the CGA-only solution in passing, and don't
encourage it as a part of SEND. Suggest it is up to Layer 2 standardization
bodies to incorporate this functionality in their specifications.

WG members are encouraged to discuss these alternatives, express their
preference, or suggest an additional alternative that I've missed.

            jak

--------------------------------------------------------------------
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: Alper Yegin <[email-masked]>
Date: Tue, 26 Aug 2003 17:29:00 -0700

Hi James,

I agree that relying on filtering capabilities in the access network for
solving router advertisement authorization problem cannot be "the IETF SEND
standard solution." But nevertheless, I think this should be noted as one
possible way to solve "the problem." Also stating the applicability of such
a solution, optionally along with its strengths/weaknesses, etc. would be
useful. After all, network administrators should understand not only the
problem and one of its solutions, but also other solutions and how they
might relate to each other. At the end, they'd be the one to choose among
these solutions.

On the CGA point: Physical access, MACsec or IPsec-based control already
helps enabling filtering. What does CGA-based approach add to this?

Alper

---

From: "James Kempf" <[email-masked]>
Date: Wed, 27 Aug 2003 08:12:55 -0700

So are you in favor of A, B, or C?

            jak

----- Original Message ----- 
From: "Alper Yegin" <[email-masked]>
To: "James Kempf" <[email-masked]>;
<[email-masked]>
Sent: Tuesday, August 26, 2003 5:29 PM
Subject: Re: Issue 14: Is CGA-only RD protection useful?

---

From: Alper Yegin <[email-masked]>
Date: Wed, 27 Aug 2003 13:53:00 -0700

> So are you in favor of A, B, or C?

D) Mention the possibility of filtering unauthorized RAs by relying on the
physical access or crypto-based access authorization (i.e., using MACsec or
IPsec). Such a solution is applicable when the hosts cannot directly
communicate with each other without going through an access network device
(such as an access point or access router) where this fitlering can take
place.

I would not suggest CGA-based RA filtering for the text, unless someone
explains its benefits over the existing ways to check authorization.

Alper

---

From: "James Kempf" <[email-masked]>
Date: Wed, 27 Aug 2003 14:49:18 -0700

> (such as an access point or access router) where this fitlering can take

By physical access I assume you mean a lock on the door, for example?

By MACsec I assume you mean cryptographic protection on the MAC layer, or
possibly the kind of port-based filtering done by 802.1x?

Can you explain how IPsec would work in this context?

> explains its benefits over the existing ways to check authorization.

What existing ways? The reason SEND was chartered is that the security in
RFC 2461 was considered inadequate (note: if you are thinking of AAA-based
solutions, not every access network will deploy AAA).

            jak

---

From: Alper Yegin <[email-masked]>
Date: Wed, 27 Aug 2003 17:45:09 -0700

> By physical access I assume you mean a lock on the door, for example?

For example, an access point has two sides: wireless, and wired. In various
deployments, the wired side is protected by physical security (e.g., doors,
walls, hard-to-reach areas, etc.). This is also where the routers would
connect. In that case, the access point can filter out any router
advertisements sent from the wireless side while allowing any sent from the
wired side. The assumption is, only service provider's devices are allowed
to access the wired segment. And this is guaranteed by physical security.

> possibly the kind of port-based filtering done by 802.1x?

Possible combination of the two.. In the aforementioned network, if the
physical security is not adequate (or you don't want to automatically
authorize any node connected to the wired segment as a "router") then you
can load a list of MAC addresses (or client IDs which are bound to MAC
addresses upon 802.1X - if used) as ACL, and the AP filters out any router
advertisement if it does not arrive on a MACsecured packet with an
authorized identifier.

> Can you explain how IPsec would work in this context?

Similar to the L2 case...

> solutions, not every access network will deploy AAA).

We are just talking about how to prevent unauthorized router advertisements,
which is just one half of SEND. Current approach of SEND WG is to use
certificates to prove authorization for an advertisement. As I understand
from your original e-mail, the WG is also considering a filter-based
approach where CGAs are used as the "authentication/authorization method."
What I'm saying is, yes, filter-based approaches are valid, but asking why
we need a CGA-based scheme where physical security, MACsec, or IPsec-based
filtering can be used.

This has nothing to do with using CGAs for solving the address ownership
problem (the other half of SEND).

Alper

---

From: "James Kempf" <[email-masked]>
Date: Thu, 28 Aug 2003 11:15:38 -0700

> to access the wired segment. And this is guaranteed by physical security.

These comments have nothing to do with Issue 14: whether CGA alone can be
used for RAs. These comments have to do with deployment alternatives for RA
security, which is outside the scope of SEND. The SEND charter only deals
with security enhancements to the protocol defined in RFC 2461 & 2462, not
deployment issues.

> advertisement if it does not arrive on a MACsecured packet with an

Again, this is an alternative deployment that is outside the scope of the
SEND charter.

> Similar to the L2 case...

Another deployment issue.

> problem (the other half of SEND).

With regard to the original point of this email thread, I interpret your
response to be that you don't see any need to mention CGA-based RA filtering
in the draft, i.e. alternative A, because there are existing filter-based
alternatives that satisfy any requirement for non-cert based RA security.
Your alternative D involves deployment issues, which, as I've stated, are
outside of SEND's scope, and therefore not appropriate for insertion in the
WG draft.

If you are interested in pursuing these deployment issues, I'd suggest
talking to the OPS ADs about scheduling a BOF. Unlike other WGs, the SEND WG
has made very strenuous attempts to stay focussed on completing its charter
as quickly as possible, and not wandering off into trying to solve all the
problems of local link security.

Anybody else have some comments specifically on the intended focus of the
email thread?

            jak

---

From: Alper Yegin <[email-masked]>
Date: Thu, 28 Aug 2003 12:34:37 -0700

> used for RAs. 

The relevance, if it wasn't clear in my message, is this:
- If SEND WG wants to talk about how to "filter out" router advertisements
on an enforcement point, it does not have to invent new CGA-based
mechanisms, the already existing ones are good enough.

> These comments have to do with deployment alternatives for RA

Sure, but acknowledging presence of these alternatives, considering possible
co-existence, and interaction if there is any, is a good thing, imo.

Good examples are the Mobile IPv6 draft and RFC3344. They do not dodge the
"link-layer mobility" issue as not for Mobile IP WG to deal with, instead
they acknowledge its presence, solution to the problem, strengths and
weaknesses. Just briefly, of course.

Alper