Subject: [savi] Identifying First-Hop Vs. Forwarded Traffic

From: Christian Vogt <[email-masked]>
Date: Thu, 30 Oct 2008 23:45:25 +0200

We have agreed that SAVI should be complementary to ingress filtering,
and not substitute it.  This implies that SAVI should not validate
packets that are forwarded by routers.  Thankfully, this makes the
design of SAVI simpler.  But it requires us to find a way for SAVI to
distinguish first-hop traffic from forwarded traffic (where "first-hop
traffic" is transmitted by the originating host, and "forwarded traffic"
is relayed by a router).  I would like to open a discussion about the
alternatives for achieving such traffic differentiation.  Which
techniques are possible, and which are the ones we prefer?

As for myself, I see two possible approaches to distinguish between
first-hop traffic and forwarded traffic:

(1) Based on whether or not a packet's source address is from an on-link
     subnet prefix.

(2) Based on whether or not the sending node is an authorized router.

Both approaches have pros and cons.  An advantage of approach (1) is
that a SAVI device can automatically detect the set of on-link subnet
prefixes by simply listening to Router Advertisement messages.  With
approach (2), similar auto-configuration is possible only with SeND
because a router can then be securely identified based on its verifiable
Router Advertisement messages.  There is no way for a SAVI device to
automatically and securely identify a router if plain ND is used.
Approach (2) therefore requires pre-configuration of SAVI devices with
information about local routers if plain ND is used.

On the other hand, a disadvantage of approach (1) is that SAVI may
erroneously validate forwarded packets with the consequence of false
drops.  This happens when a host sends a packet to a neighbor via the
local router instead of sending it to the neighbor directly.  The packet
is then dropped when forwarded by the local router.  With approach (2),
the SAVI device would not validate, and hence not drop, the packet given
that it is coming from the router.  This issue with approach (1) can be
mitigated if local routers use Redirect messages to enforce direct
neighbor-to-neighbor communications.

One conclusion from the above could be that approach (2) should only be
used when SeND is available.  And in such a case, approach (1) could be
omitted.  This would mean that, with plain ND, approach (1) would be
used exclusively.

What do you folks think about this?

- Christian

---

From: Pekka Savola <[email-masked]>
Date: Fri, 31 Oct 2008 08:38:28 +0200 (EET)

On Thu, 30 Oct 2008, Christian Vogt wrote:
> prefixes by simply listening to Router Advertisement messages.

Note that as both IPv4 and IPv6 need to be covered (1) would not be 
that simple for IPv4.  Additionally for v6, the system might need to 
snoop DHCPv6 traffic (in case RAs are not used to advertise onlink 
prefixes?), and I guess there would also need to be a provision for 
manual configuration.

Some mechanisms in ethernet switches already require identifying ports 
which attach the routers (e.g. IGMP snooping) or that are excluded 
from automatic checks (e.g. DHCP snooping, ARP inspection).  Maybe 
this would be a third alternative.  This is slightly complicated in a 
high-availability scenario like follows:

  router1 --- switch1 --- switch2 --- router2
               |          |
             hosts      hosts

.. to cover for high-availability, switch1 would also need to be 
configured to have the switch1-switch2 as a router port.  As such this 
kind of port-based checking has its own limitations or would need to 
be used as a last resort rule (allow if there is no specific binding).

Another possibility could be to identify forwarded traffic based on a 
set of source MAC addresses (and/or ports); while a router may use 
multiple MAC addresses for forwarding (e.g. when VRRP is used), it 
usually uses a relatively small number of them.  If the scenario is 
such that MAC address spoofing is prevented, this could also provide a 
method to distinguish traffic.

In all these cases the issue is if the router ports/MAC addresses 
would need to be automatically discovered.  This might be a challenge 
(FWIW, for multicast router ports, RFC 4286 already specified a 
solution, though I'm not sure if anyone has implemented it).

-- 
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: marcelo bagnulo braun <[email-masked]>
Date: Fri, 31 Oct 2008 10:17:42 +0100

Pekka Savola escribió:
> that simple for IPv4.
Why not?
I mean, i understand that in general, any device running IP should know 
what are the prefixes that are directly connected to its interfaces, so 
it can directly deliver the datagrams, right?

I understand that the next hop is always directly connects to the 
sending interface, so both the host and the router shouls be aware of 
the prefix used in the source address afaiu

what am missing?

> Additionally for v6, the system might need to snoop DHCPv6 traffic (in 
> case RAs are not used to advertise onlink prefixes?), and I guess 
> there would also need to be a provision for manual configuration.
>

---

From: Pekka Savola <[email-masked]>
Date: Fri, 31 Oct 2008 12:21:43 +0200 (EET)

On Fri, 31 Oct 2008, marcelo bagnulo braun wrote:
>>  Note that as both IPv4 and IPv6 need to be covered (1) would not be that
>>  simple for IPv4.
> Why not?
> I mean, i understand that in general, any device running IP should know what 
> are the prefixes that are directly connected to its interfaces, so it can 
> directly deliver the datagrams, right?

If an ethernet switch is operating in layer 2 only, it doesn't know 
anything about IP prefixes on the link.  In IPv4 specifically, there 
are no RA's that could be snooped.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 31 Oct 2008 11:33:11 +0100

Pekka Savola escribió:
>>> that
>> I mean, i understand that in general, any device running IP should 
>> know what are the prefixes that are directly connected to its 
>> interfaces, so it can directly deliver the datagrams, right?
>
Right
The SAVI function can be implemented in routers or in switches.
In the case of routers we can assume that the routers will know the on 
link prefixes for all their interfaces.
In the case of switches, this information is not available and needs to 
be configured. I don't think this is a big problem. I mean, we have a 
very constrained environment here. We cannot change the hosts, we cannot 
make new protocols. We must limit ourselves to include a new 
functionality in the switch or in the router. It would be great if we 
don't have to configure the SAVI device, but is think it is reasonable 
to accept some that configuration is needed e.g. configuring the on-link 
prefixes for IPv4, makes sense?

Regards, marcelo

---

From: Christian Vogt <[email-masked]>
Date: Fri, 31 Oct 2008 13:48:21 +0200

Marcelo and Pekka -

> I mean, we have a very constrained environment here. We cannot change
> the hosts, we cannot make new protocols. We must limit ourselves to
> include a new functionality in the switch or in the router. It would  
> be
> great if we don't have to configure the SAVI device, but is think it  
> is
> reasonable to accept some that configuration is needed e.g.  
> configuring
> the on-link prefixes for IPv4, makes sense?

I agree that we have to make compromises.  Manual configuration seems to
be unavoidable in some cases.

To summarize your and Pekka's comments:  Of the two approaches to
distinguish first-hop traffic from forwarded traffic...

...both are feasible, but neither enables complete auto-configuration of
SAVI devices in all cases.

For auto-configuration in approach (1), we could:

- rely on routing information if SAVI is colocated with a router,
- snoop Router Advertisement messages (and DHCP messages) in IPv6.

For auto-configuration in approach (2), we could:

- rely on routing information if SAVI is colocated with a router and if
  the routing information is authenticated,
- snoop IGMP or Router Advertisement messages if the messages are
  authenticated.

In either case, the property of being an authorized router could be
associated with a router's MAC address, or with a switch port to which
the router connects.  The same applies if a SAVI device is manually
configured.

It is worthwhile emphasizing the following important difference between
approaches (1) and (2):  Approach (1) is inherently secure because it is
an "opt-in" approach:  The injection of a bogus on-link subnet prefix
does not reduce the strictness of SAVI devices; it can at most increase
the strictness.  Approach (2), on the other hand, requires
authentication because it is an "opt-out" approach:  If an attacker
manages to convince a SAVI device that it is an authorized router, the
SAVI device would deactivate source address validation for the packets
sent by the attacker.  This can be protected against only through
authentication of authorized routers.

This difference between approaches (1) and (2) has an impact on the
applicability of SAVI device auto-configuration.  The need for
authentication in approach (2) is a deployment hurdle in my opinion, so
I would argue that approach (1) should be preferred for
auto-configuration.  The difference between approaches (1) and (2) has
no impact on manual configuration of SAVI devices because manually
configured information necessarily needs to be trusted.

- Christian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 31 Oct 2008 13:39:19 +0100

Christian Vogt escribió:
>> include a new functionality in the switch or in the router. It would be
>> great if we don't have to configure the SAVI device, but is think it is
>> reasonable to accept some that configuration is needed e.g. configuring
well, it doesn't need much routing information, only on link prefixes 
(i.e. what any device with layer 3 knows)
>  the routing information is authenticated,
well, as i say before, you don't need routing information. What you need 
to to know what are the onlink prefixes. Normally any layer 3 device 
knows that, sicne when you configure an address and a mask, you are 
configuring this information.
So, i am not sure how much authentication we need here

> the strictness.
not sure what you mean... If an attacker manages to convince the savi 
device that a given prefix is onlink, then the attacker can send packets 
using that source address, which is one of the things we want to 
prevent, right?
So, i am not sure i agree with the assertion that this is inherently 
secure... what am i missing?

>   Approach (2), on the other hand, requires
> sent by the attacker.  
right,

this case is worse, cause the attacker can send packets from any prefix.
but we are not taking ingress filtering into account, right?
Ingress filtering could actually solve this, right?

> This can be protected against only through
doesn't ingress filtering mitigates this?

regards, marcelo

---

From: Christian Vogt <[email-masked]>
Date: Fri, 31 Oct 2008 15:28:05 +0200

Marcelo -

> prevent, right? So, i am not sure i agree with the assertion that this
> is inherently secure... what am i missing?

The reason I am saying that approach (1) is "opt-in" is this:  Before
the attack, the SAVI device does not even perform any validation at all.
The SAVI device starts validating only once the attacker has convinced
the SAVI device that the bogus prefix is on-link.  So the attack can at
most increase the strictness of the SAVI device; it cannot reduce it.

Of course, the attacker could still get away with an address from the
bogus prefix:  If the attacker configured an address from the bogus
prefix using legitimate mechanisms such as ND, the SAVI device would
accept this address.  But I think this is acceptable because, since SAVI
should be complementary to ingress filtering and not replace it, the
responsibility for validating prefixes and hence detecting off-link
addresses could be delegated to ingress filtering.  This would mean that
it would be OK for SAVI devices to accept addresses from bogus on-link
prefixes, because those are just a special case of off-link prefixes.

> doesn't ingress filtering mitigates this?

It mitigates it, but the validation still becomes weaker.  More
specifically, we should differentiate two cases:

(1) no SAVI validation for any packets from a router,

(2) no SAVI validation for packets with off-link source addresses from a
    router.

In case (a), an attacker can spoof any on-link source address once it
has convinced the SAVI device that it is an authorized router.  This is
because the SAVI device will then discontinue the validation of packets
from the router, and ingress filtering won't detect the spoofing because
the spoofed addresses have a correct prefix.  The attacker can also
spoof off-link source addresses with a prefix that appears to be
topologically correct from the perspective of ingress filtering.

In case (b), an attacker can spoof only off-link source addresses from
prefixes that appear to be topologically correct from the perspective of
ingress filtering.

- Christian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 31 Oct 2008 15:56:33 +0100

> the attack, the SAVI device does not even perform any validation at all.
what do you mean?
AFAIU, the SAVI device by default drops all the packets except those 
coming with a source address containing one of the on-link prefixes. So, 
SAVI is perfroming validation and dropping everything.
When the attacker manages to convince that one additional prefix is 
onlink, then this new prefix is acceptable to be used in the source 
address and then the savi filtering does not applies to these packets.
> most increase the strictness of the SAVI device; it cannot reduce it.
i don't think i understand your point.

> addresses could be delegated to ingress filtering.
well, i am not sure if this is the case
If we don't know which are on-link prefixes then this means that any 
node can send packets with any source address, since the SAVI function 
does not knows whether the prefix is onlink or not

>   This would mean that
no, i don't think this is ever the case.... If the source address has 
the onlink prefix and it is being used by another device, then savi 
should drop the packets, even if they come from a router.
I mean, if the CGA proof that another node is the owner of th given 
address, then no other node (not even a router) can send packets from 
that source imho

> (2) no SAVI validation for packets with off-link source addresses from a
i think this is the actual case
Moreover, i think that ingress filtering does provides higher granularity
If SAVI tells you a list of auhtorized routers, ingress filtering tells 
you more, ingress fitlering tells you which of these routers are able to 
send using which prefixes.

> prefixes that appear to be topologically correct from the perspective of
right (agree with b)

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 31 Oct 2008 15:59:28 +0100

> (2) Based on whether or not the sending node is an authorized router.

coming back to this original question, i think that in any case we need 
both.
I mean, we need the list of onlink prefixes, if not SAVI does not know 
which source addresses can be generated by onlink nodes
We need the list of routers cause if not we don't know which of the 
directly connected devices can generate packets with off-link source 
addresses.

I am don't see how you can build a savi solution with only one of those
I don't see these as one or the other, but i think you need one _and_ 
the other.

Regards, marcelo

> _______________________________________________
> savi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/savi
>

---

From: Christian Vogt <[email-masked]>
Date: Thu, 13 Nov 2008 17:41:11 +0200

> both. I mean, we need the list of onlink prefixes, if not SAVI does  
> not
> know which source addresses can be generated by onlink nodes We need  
> the
> list of routers cause if not we don't know which of the directly
> connected devices can generate packets with off-link source addresses.

Marcelo -

Sorry for coming back late to this.

I agree that SAVI devices need to know the on-link prefixes in any case.
But I also believe that SAVI devices could do without knowing which
neighbors are routers.  The reason is that we could rely on ingress
filtering to detect spoofed off-link source addresses.  In that case, a
SAVI device would not validate any packets with off-link source
addresses; only when a packet goes through ingress filtering would a
spoofed off-link source address be detected.  This would provide
somewhat lower, but still acceptable security IMO.

The reason why the security would be lower if we rely on ingress
filtering is that packets with off-link source addresses would not be
checked if directly transmitted between neighbors.  They would only be
checked if relayed through a router, because only routers perform
ingress filtering.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Sun, 16 Nov 2008 13:06:04 -0600

On Oct 31, 2008, marcelo bagnulo braun wrote:

> what do you mean? AFAIU, the SAVI device by default drops all the
> packets except those coming with a source address containing one of  
> the
> on-link prefixes.

So a SAVI device by default drops all packets from off-link prefixes?
But the validation of these packets is exactly what we want to leave to
ingress filtering, right?

Then, since we leave to ingress filtering the validation of packets with
off-link prefixes, the SAVI device should let these packets pass IMO.

- Christian