Subject: Neighbor Discovery and on-link determination

From: David Miles <[email-masked]>
Date: Mon, 23 Jun 2008 00:21:16 -0500 (CDT)

I have seen an unusual scenario which I was wanting to run past people to 
comment on:

I have routerA and routerB connected to each other via Ethernet.

RouterA has the following addresses on the interface to RouterB:
2000:100::2/64
3000:100::2/64
With a default route to 2000:100::1

RouterB has the following addresses on the interface to RouterA:
2000:100::1/64
With a route for 3000:100::/64 to 2000:100::2

Per RFC4861, RouterA is sending ND as follows (assume it wants to 
src traffic from 3000:100::2 to a off-link address):
    3000:1::2 -> FF02::1:FF00:1
    Type: Neighbor Solicitation (135)
    Code: No Code (0)
       Tgt Addr: 2000:100::1
       Option  : Src Link Layer Addr 00:00:00:00:00:01

As 7.2.2 says "if the source address of the packet prompting the 
solicitation is the same as one of the addresses assigned to the outgoing 
interface, that address SHOULD be placed in the IP Source Address of the 
outgoing solicitation."

When RouterB will receive the ND as it is sent to the solicited-node MC 
address and will check the target address is valid (matches an addresss 
assigned to the receiving interface).
RouterB should then create a Neighbour Cache entry and set its state to 
STALE using the link-layer address in the ND. It should then send a 
solicited neighbor advertisement.

This means that the RouterB will have a single address 3000:1::2 in its 
Neighbour Cache, but the route will direct traffic to 2000:200::2. 
Obviously the Neighbour Cache would now contain an entry for an address 
that does not (appear) to be on-link from a route-table perspective.

How should Neighbour Cache and route table interact on a routerB? I had 
always assumed route table replaces Prefix List on a router, but that 
would mean Neighbour Cache would always be consulted with the next-hop of 
the static route (following the sending algorithm in RFC 4861).

This seems to directly relate to the definition of on-link as being:
- an address covered by on of the link's prefixes, or
- an address in the target of a rediect, or
- an address in the target of a neigbour advertisement, or
- an address in the source of a neighbour discovery message

Should a router really consider an address on-link just because it 
received a ND - I can see many potential security concerns if that is the 
case.

Any clarifications or experiance appreciated.

Regards,

-David Miles

---

From: Thomas Narten <[email-masked]>
Date: Tue, 24 Jun 2008 17:36:49 +0200

> that does not (appear) to be on-link from a route-table perspective.

Hmm. This would appear to be a bug.

I do not believe it was the intention to have any addresses that
appear as the source of an NS result in a recipient of the NS
concluding that the source address is on-link.

That said, if you follow the words in the spec (with the "conceptual
algorithms"), the result would appear to be a bogus entry in the
Neighbor Cache, but one that would not get used. I.e., when sending to
that destination, RouterB would first look in its Destination Cache,
find no entry and then do next-hop determination (i.e., by looking at
the on-link information. It would NOT look in the Neighbor Cache at
this point, it only does that after determining if the destination is
on-link.

In any case, I would have expected that before creating a Neighbor
Cache Entry for the source address mentioned above, the receiver
should first verify that the address would be considered on-link per
the standard checks.

> the static route (following the sending algorithm in RFC 4861).

That may be the common implementation, but that is not what the
conceptual sending alogrithm says should happen.

> - an address in the target of a rediect, or

yes

> - an address in the target of a neigbour advertisement, or

There is no definition that I know if that would allow you to draw
this conclusion. All one can conclude is that the sender of the NS
believes the target is on-link. They may be right, but they may also
be wrong.

> - an address in the source of a neighbour discovery message

No, per above.

> received a ND - I can see many potential security concerns if that is the 

I think not, with security concerns being one reason why not.

> Any clarifications or experiance appreciated.

Good catch!

Thomas

---

From: David Miles <[email-masked]>
Date: Wed, 25 Jun 2008 10:04:25 +1000

Thanks Thomas,

I'll move this into v6man if that is the case (and to ensure everyone  
is across it).

So in summary, the definition of on-link is where the uncertainty  
arose, because the current definition is:
on-link - an address that is assigned to an interface on a specified  
link. A node considers an address to be on- link if:
- it is covered by one of the link's prefixes (e.g., as indicated by  
the on-link flag in the Prefix Information option), or
- a neighboring router specifies the address as the target of a  
Redirect message, or
- a Neighbor Advertisement message is received for the (target)  
address, or
- any Neighbor Discovery message is received from the address.

It sounds as though we should remove the last two conditions?

I'd also suggest that in the Message Validation section we include the  
checks you mention (is the source of the ND or target of the NA an on- 
link prefix per Prefix List)

Best Regards,

-David

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 25 Jun 2008 03:35:14 -0700

David Miles wrote:
> I have seen an unusual scenario which I was wanting to run past people 
> to comment on:
> 

So the routers are intentionally configured to have different on-link 
prefixes?

> Per RFC4861, RouterA is sending ND as follows (assume it wants to src 
> traffic from 3000:100::2 to a off-link address):
> solicitation is the same as one of the addresses assigned to the 
> outgoing interface, that address SHOULD be placed in the IP Source 
> Address of the outgoing solicitation."
> 

Correct. The same thing is true for a host receiving a redirect where 
the target is on-link.

> would mean Neighbour Cache would always be consulted with the next-hop 
> of the static route (following the sending algorithm in RFC 4861).

Since the neighbor cache is per-interface the routing table needs to be 
consulted first, and only what that results in knowing the interface on 
which to send the packet does the neighbor cache get consulted.

But I don't think there is anything in the RFC that explicitly spells 
that out.

> received a ND - I can see many potential security concerns if that is 
> the case.

Given that the neighbor cache is per interface, can you give me an 
example of where this causes a security concern?

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 25 Jun 2008 03:38:18 -0700

David Miles wrote:

> checks you mention (is the source of the ND or target of the NA an 
> on-link prefix per Prefix List)

If you do that, how would communication work in your example?
The NS would be dropped since its source isn't covered by an on-link 
prefix on the receiver, right?

    Erik

---

From: David Miles <[email-masked]>
Date: Wed, 25 Jun 2008 21:18:05 +1000

Hi Erik,

I'll put both answers into one email:

If routerA sent a ND to routerB and the source address of the ND if  
off-link, populating the Neighbour Cache will not achieve any real  
functionality. Yes, I'd propose it is ignored by the router. Possibly  
we could trigger a unsolicited Neighbour Advertisement from RouterB?
I cannot see any impact on redirect or proxy service functionality and  
I really see this as a misconfiguration.

With respect to your other email and my security concerns:  if  the  
receipt of a ND or NA on any interface, irrespective of prefix list,  
were able to both populate the Neighbour Cache and update/affect the  
forwarding behaviour then I would be worried. Seeing you have both  
clarified this was not the intent I do not have an issue, but it does  
seem of little benefit to populate a Neighbour Cache entry if it is  
never consulted.

I know the scenario is contrived however it was brought to my  
attention from another source, so the clarifications are appreciated.

Best Regards,

-David

On 25/06/2008, at 8:38 PM, Erik Nordmark wrote:

> David Miles wrote:
>
>> I'd also suggest that in the Message Validation section we include  
>> the checks you mention (is the source of the ND or target of the NA  
>> an on-link prefix per Prefix List)
>

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 25 Jun 2008 06:25:38 -0700

David Miles wrote:
> functionality. Yes, I'd propose it is ignored by the router. Possibly we 
> could trigger a unsolicited Neighbour Advertisement from RouterB?
> I cannot see any impact on redirect or proxy service functionality and I 
> really see this as a misconfiguration.

The message validation rules that you referred to are cases when the 
packet would be ignored (and that would be problematic for sure.)

It makes sense to look carefully at the effect of "do not create a 
neighbor cache entry for the sender if sender is not in one of the 
on-link prefixes".

> I know the scenario is contrived however it was brought to my attention 
> from another source, so the clarifications are appreciated.

OK

    Erik