Re: net/ipv4/arp.c: arp_rcv, rfc2131 BREAKS communication

Re: net/ipv4/arp.c: arp_rcv, rfc2131 BREAKS communication

[Julian Anastasov]

	Hello,

pjordan@whitehorse.blackwire.com wrote:

>        16.bit Opcode                  = 2 (Reply)
>        48.bit Sender Ethernet Address = Hardware address of interface
>        32.bit Sender IP Address       = Local IP address
>        48.bit Target Ethernet Address = Sender Addr in Request packet
>        32.bit Target IP Address       = Local IP Address

	It seems in this experimental draft we see that the symmetry
is broken. The reply is from SIP to TIP and both are "Local IP address"
but the SHA and THA are different. When in replies SIP==TIP this is
something like we reply ourselfs. IMO, the same should be for SHA and
THA. Why to do duplicate address detection with SIP loaded with TIP?
There is already a way to do DAD: with SIP=0. May be the authors don't
know this solution? SIP=0 is used exactly for this purpose, not to
disturb the other hosts that already know TIP by some MAC. In this
draft I was not able to understand how DAD is performed. Of course,
with any mechanism used there is a race where two host can do DAD,
then nobody replies and then the both decide to configure the IPs.
But then who will agree to remove its IP? Someone would require
election process, something like VRRP. Or may be to configure the
IP (but not to advertise it if other hosts ask, i.e. passive mode),
to do DAD with SIP 0, to wait 1-2 seconds (or short random time) and
during that time to listen for remote hosts doing DAD and if
there are no other hosts that do DAD to advertise the IP. I agree that
after the IP is configured gratuitous ARP can be sent (and it is used in
setups where the IP is moved between the hosts to update the cached
values in remote caches) but I'm not sure the proposed scheme to remove
the duplicated IP is the best we can see, how you feel it?:

[
 (iii) If a host receives an ARP reply with both sender IP address
      and the target IP address fields match one of its interfaces,
      it MUST turn off the interface to stop using this address.
      It May log or display warning messages to indicate the error.
]

	What happens if we don't want to do it? Also, think for
shared IP addresses (same IP on many hosts, not advertised with
ARP from all hosts but still configured on some interface).

> So again, how does the snippet of code at the top of this message from arp.c
> in any way follow this scheme.  It looks for arp packets from 0.0.0.0
> not packets with 'target and sender IP address are the same'.

	IMO, the clients that do duplicate address detection shouldn't
drop replies that have THA != Destination Hardware Address. What is
that? A security measure? Linux does not check THA at all. And DAD
should be performed with SIP=0, why with SIP==TIP and when detection
is detected (and the remote caches damaged) the TIP to be unconfigured?
SIP=0 is the only way not to disturb the others because both the
requests and the replies with SIP!=0 can damage the caches (because
they are broadcasts destined to ff:ff:ff:ff:ff:ff).

	If your fix works for "PowerPC Open Firmware" then this
stack performs extra checks that I'm not sure they are specified
somewhere and are needed at all. May be I'm missing some standard?

Regards

--
Julian Anastasov <ja@ssi.bg>

Re: net/ipv4/arp.c: arp_rcv, rfc2131 BREAKS communication

[pjordan]

> 	Hello,

hi.

> >        16.bit Opcode                  = 2 (Reply)
> >        48.bit Sender Ethernet Address = Hardware address of interface
> >        32.bit Sender IP Address       = Local IP address
> >        48.bit Target Ethernet Address = Sender Addr in Request packet
> >        32.bit Target IP Address       = Local IP Address

> THA. Why to do duplicate address detection with SIP loaded with TIP?
> There is already a way to do DAD: with SIP=0. May be the authors don't
> know this solution? SIP=0 is used exactly for this purpose, not to

Could you point me to some documentation on this method, if you know
where some is ?

> election process, something like VRRP. Or may be to configure the

VRRP ?

> values in remote caches) but I'm not sure the proposed scheme to remove
> the duplicated IP is the best we can see, how you feel it?:

I would have to study the problem in more depth to give a good answer,
I am primarily concerned with not having to maintain a 'personal'
kernel patch to get DHCP relaying to work for G4's.  I doubt
writing Apple would get any responses :(

> [
>  (iii) If a host receives an ARP reply with both sender IP address
>       and the target IP address fields match one of its interfaces,
>       it MUST turn off the interface to stop using this address.
>       It May log or display warning messages to indicate the error.
> ]
> 
> 	What happens if we don't want to do it? Also, think for
> shared IP addresses (same IP on many hosts, not advertised with
> ARP from all hosts but still configured on some interface).

 I agree this MUST is overkill.  but then also
 'what is we want to send a normal arp packet ?'
 
> 	IMO, the clients that do duplicate address detection shouldn't
> drop replies that have THA != Destination Hardware Address. What is
> that? A security measure? Linux does not check THA at all. And DAD

I believe this is common behaviour for non-promiscuous interfaces .. ?
I agree it would be nicer if it didn't drop it but it does, and
DHCP relaying is a perfectly valid thing to do, so the current
code breaks this (for the G4 OF, possibly for other platforms as well).


> Should be performed with SIP=0, why with SIP==TIP and when detection
> is detected (and the remote caches damaged) the TIP to be unconfigured?
> SIP=0 is the only way not to disturb the others because both the
> requests and the replies with SIP!=0 can damage the caches (because
> they are broadcasts destined to ff:ff:ff:ff:ff:ff).

 Indeed that experimental document does not address arp cache corruption
 at all.  Presumably hosts would have to ignore packets
 that have SIP and TIP the same unless it is what they are using...
 
> 	If your fix works for "PowerPC Open Firmware" then this
> stack performs extra checks that I'm not sure they are specified
> somewhere and are needed at all. May be I'm missing some standard?

Who can we ask for an answer as to why this might be done ?

Hmm. http://www.freesoft.org/CIE/RFC/826/6.htm

Shows a pseudo-code that indicates a check should
be performed to see if THA is "ours" and if not, discard the packet

-- BEGIN snippet --

When an address resolution packet is received, the receiving Ethernet module gives the packet to the Address Resolution module which goes through an
algorithm similar to the following. Negative conditionals indicate an end of processing and a discarding of the packet. 

?Do I have the hardware type in ar$hrd?
Yes: (almost definitely)
  [optionally check the hardware length ar$hln]
  ?Do I speak the protocol in ar$pro?
  Yes:
    [optionally check the protocol length ar$pln]
    Merge_flag := false
    If the pair  is
        already in my translation table, update the sender
        hardware address field of the entry with the new
        information in the packet and set Merge_flag to true. 
    ?Am I the target protocol address?
    Yes:

-- END snippet --


Maybe the right fix then is to set DHA to all ones. ffffffffffff. ?

Regards,

Peter

Re: net/ipv4/arp.c: arp_rcv, rfc2131 BREAKS communication

[pjordan]

> When an address resolution packet is received, the receiving Ethernet module gives the packet to the Address Resolution module which goes through an
> algorithm similar to the following. Negative conditionals indicate an end of processing and a discarding of the packet. 
 
>     ?Am I the target protocol address?
>     Yes:

> Maybe the right fix then is to set DHA to all ones. ffffffffffff. ?

No. Shake my head, the above is a reference to TIP, not THA.
and DHA is already set correctly anyway. (what was I drinking..)

Anyway.. RFC2131 only talks about the format of the arp request and not of
the arp reply.  I will test again to see if OF is testing THA or TIP.
 My guess is TIP.

So how to get the fix incorporated into the kernel though.
I don't see why it would break anything else.

Peter

Re: net/ipv4/arp.c: arp_rcv, rfc2131 BREAKS communication

[Bernd Eckenfels]

In article <20011125181921.A16765@panama> you wrote:
> Shows a pseudo-code that indicates a check should
> be performed to see if THA is "ours" and if not, discard the packet

Ethernet cards are dropping other addresses, but if it is in promisc mode it
may catch some miss addressed. Therefore Linux Kernel is checking all
incoming frames and mark them OTHERHOST. This means they can travel up the
packet capture sockets, but are never handed to application tcp/udp sockets.

Greetings
Bernd

Re: net/ipv4/arp.c: arp_rcv, rfc2131 BREAKS communication

[Julian Anastasov]

	Hello,

On Sun, 25 Nov 2001 pjordan@whitehorse.blackwire.com wrote:

> > THA. Why to do duplicate address detection with SIP loaded with TIP?
> > There is already a way to do DAD: with SIP=0. May be the authors don't
> > know this solution? SIP=0 is used exactly for this purpose, not to
>
> Could you point me to some documentation on this method, if you know
> where some is ?

	You already mentioned it, DHCP SHOULD use SIP=0.0.0.0.

> > election process, something like VRRP. Or may be to configure the
>
> VRRP ?

	RFC2338. It guarantees unique IP but tries to keep the MAC.
It has other purposes.

> I am primarily concerned with not having to maintain a 'personal'
> kernel patch to get DHCP relaying to work for G4's.  I doubt
> writing Apple would get any responses :(

	Hm

>  I agree this MUST is overkill.  but then also
>  'what is we want to send a normal arp packet ?'

	Can you explain? I don't understand the Q

> > 	IMO, the clients that do duplicate address detection shouldn't
> > drop replies that have THA != Destination Hardware Address. What is
> > that? A security measure? Linux does not check THA at all. And DAD
>
> I believe this is common behaviour for non-promiscuous interfaces .. ?

	No, the ARP reply is destined directly to the target MAC but
with ARP data SIP==TIP and SHA==THA, i.e. THA!=target MAC

> > 	If your fix works for "PowerPC Open Firmware" then this
> > stack performs extra checks that I'm not sure they are specified
> > somewhere and are needed at all. May be I'm missing some standard?
>
> Who can we ask for an answer as to why this might be done ?

	If the maintainers don't read this thread then contact them
directly. I'm not sure there is a standard for duplicate address
detection. For now ARP is used to do the detection but without
protocol adapted from all vendors I'm not sure it will be race-free.
There are other client-server oriented protocols where the server
guarantees that the given IP is unique. I don't see an easy solution for
DAD for other purposes, i.e. when two hosts try to use same IP without
obtaining it from some authority. May be this is the reason iproute2 to
come with script (user space solution) to configure the IP addresses.
In this case the gap for race is small.

> Maybe the right fix then is to set DHA to all ones. ffffffffffff. ?

	You can try to feed the arp_send call that you change with
dest_hw=NULL and to see whether it works. If it works you will have
a second solution. In any case you need the maintainers' opinion
because it seems nobody recommends anything about the ARP replies,
i.e. for THA when SIP==TIP.

	You are not sure it will not break something else (answering your
next posting). You can also look at RARP (RFC903) where THA==Target MAC
is already a requirement but the request is SIP=0 and TIP=0 (similar
but not related to DAD). RFC2131 states that the client SHOULD perform
DAD for the suggested address from DHCP. Later: "may issue an ARP request".
It seems Linux doesn not like these recommendations.

> Regards,
>
> Peter

Regards

--
Julian Anastasov <ja@ssi.bg>

Re: net/ipv4/arp.c: arp_rcv, rfc2131 BREAKS communication

[kuznet]

Hello!

> directly. I'm not sure there is a standard for duplicate address
> detection.

The procedure is prescribed in rfc on dhcp, which is sort of standard.


> In this case the gap for race is small.

There is no races there. Before DAD did not pass address must not be used,
that's all. This is also described unambigously in dhcp specs.

Alexey

net/ipv4/arp.c: arp_rcv, rfc2131 BREAKS communication

[pjordan]

Hi, 

The following lines from arp.c refer to somethign in RFC2131 as an excuse for
sending out a malformed arp packet.

        /* Special case: IPv4 duplicate address detection packet (RFC2131) */
        if (sip == 0) {
                if (arp->ar_op == __constant_htons(ARPOP_REQUEST) &&
                    inet_addr_type(tip) == RTN_LOCAL)
                        arp_send(ARPOP_REPLY,ETH_P_ARP,tip,dev,tip,sha,dev->dev_addr,dev->dev_addr);
                goto out;
        }


In practice, when using a dhcp relay agent, and a client
(PowerPC Open Firmware in this example) sends a "gratutitous arp"

'arp who-has' from 0.0.0.0 to 192.168.2.1 for example,
the above lines of code send an arp reply that does not have the mac address
of the interface that made the 'arp who-has' and thus this interface
is not able to see the reply.  This means that now 192.168.2.1
is invisible to this machine and it can communicate with it.

Asjusting the above line to :
    arp_send(ARPOP_REPLY,ETH_P_ARP,sip,dev,tip,sha,dev->dev_addr,sha);

fixes the problem and normal communication can occur.
This of course makes this paragraph completely irrelevant.

Furthemre the following section from RFC2131 makes NO reference
to sending an arp packet with such a malformed structure.
"must fill in its own hardware address as the sender's hardware address"
is not strange behaviour, and DOES NOT refer to what a machine should
do when it RECEIVES an arp request packet from IP 0.0.0.0, but refers to
what a machine should do when it SENDS a gratuitous arp packet, one that
is not a response to an 'arp who-has' but IS an 'arp who-has'.

RFC2131 snippet BEGIN

     The client SHOULD perform a check on the
   suggested address to ensure that the address is not already in use.  For
   example, if the client is on a network that supports ARP, the client may
   issue an ARP request for the suggested request.  When broadcasting an ARP
   request for the suggested address, the client must fill in its own hardware
   address as the sender's hardware address, and 0 as the sender's IP address,
   to avoid confusing ARP caches in other hosts on the same subnet.  If the
   network address appears to be in use, the client MUST send a DHCPDECLINE
   message to the server.  The client SHOULD broadcast an ARP reply to announce
   the client's new IP address and clear any outdated ARP cache entries in
   hosts on the client's subnet.

RFC2131 snippet END


Furthermore,

In http://alternic.net/drafts/drafts-j-k/draft-jou-duplicate-ip-address-01.html

Which Updates RFC 826


We see reference to the gratuitous arp packet reception and the proper reply.

BEGIN snippet

   (ii) If a host receives an ARP request packet in which the
      Target IP address and the Sender IP address are the same and it
      matches one of its interface addresses, it then implies
      IP address duplication happens. The host MUST send a link layer
      broadcast ARP reply as defined below. The host MAY also log or
      display warning messages to indicate the detection of IP address
      duplication.

       48.bit Destination Address     = 0xffffffffffff (broadcast)
       48.bit Source Address          = Hardware adderss of interface
       16.bit Frame type              = 0x806 (ARP)
       ----------------------
       16.bit Hardware type           = 0x1 (Ethernet)
       16.bit Protocol Type           = 0x800 (IP)
        8.bit Hardware Address size   = 6
        8.bit Protocol Address size   = 4
       16.bit Opcode                  = 2 (Reply)
       48.bit Sender Ethernet Address = Hardware address of interface
       32.bit Sender IP Address       = Local IP address
       48.bit Target Ethernet Address = Sender Addr in Request packet
       32.bit Target IP Address       = Local IP Address

END snippet

So here yes we see sender and target IP and ethernet addresses being
sent out as the local addresses, but note that the first two lines refer to

   (ii) If a host receives an ARP request packet in which the
      Target IP address and the Sender IP address are the same and it

So again, how does the snippet of code at the top of this message from arp.c
in any way follow this scheme.  It looks for arp packets from 0.0.0.0
not packets with 'target and sender IP address are the same'.



So, can we have this apparently stupid error fixed please.
.. or can someone show the stupidity in my reasoning.

Kind regards,

Peter