Re: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

[Hannes Gredler <[e-mail]>]

hi alia,

the issue at hand IMO does not warrant an errata.

this is more related to how ARP & nexthop handling
is performed internally in a routing-stack which is IMO a bit outside
of what isis-wg should work on.


/hannes

On 6/13/17 23:18, Alia Atlas wrote:
> Chris, Hannes, Les, Sasha,
> 
> Is there a conclusion about this Errata report?
> 
> From the discussion, it sounds like there is a problem and the argument
> is about
> what layer it should be handled by.  Perhaps, instead of normative text,
> it could be
> a note?
> 
> Regards,
> Alia
> 
> On Sun, May 7, 2017 at 1:35 AM, Alexander Vainshtein
> <[e-mail]
> <mailto:[e-mail]>> wrote:
> 
>     Naiming,____
> 
>     Lots of thanks for a very detailed response.____
> 
>     __ __
> 
>     I fully agree with you that reasonable ARP implementations
>     (including Linux) provide for enabling or disabling the check of the
>     source IP address. ____
> 
>     I also agree that disabling this check on unnumbered P2P-over-LAN
>     interfaces is the most useful use case when this check must be
>     disabled.____
> 
>     __ __
> 
>     I also agree that the if a pair of connected interfaces are
>     configured with IP addresses from mismatched subnets, traffic would
>     not pass unless ARP check is relaxed for both LAN and P2P
>     interfaces. My point is that, in the case of OSPF, if the interfaces
>     were not configured as P2P, */an OSPF adjacency would not be
>     formed/*. Therefore the link would not be part of the network graph
>     and not taken into account in the OSPF routes computation. ____
> 
>     __ __
> 
>     But if these interfaces are configured as P2P for OSPF, an adjacency
>     is formed and it reaches its FULL state. The result is blackholing,
>     and RFC 5309 neither instructs the operators to avoid such
>     configuration nor requires from the implementations to relax the ARP
>     check.____
> 
>     __ __
> 
>     Regards,____
> 
>     Sasha____
> 
>     __ __
> 
>     Office: [phone] <tel:+972%203-926-6302>____
> 
>     Cell:      [phone] <tel:+972%2054-926-6302>____
> 
>     Email:   [e-mail]
>     <mailto:[e-mail]>____
> 
>     __ __
> 
>     *From:*Naiming Shen (naiming) [mailto:[e-mail]
>     <mailto:[e-mail]>]
>     *Sent:* Friday, May 05, 2017 8:44 AM
> 
> 
>     *To:* Alexander Vainshtein <[e-mail]
>     <mailto:[e-mail]>>
>     *Cc:* Les Ginsberg (ginsberg) <[e-mail]
>     <mailto:[e-mail]>>; [e-mail]
>     <mailto:[e-mail]>; RFC Errata System
>     <[e-mail] <mailto:[e-mail]>>;
>     [e-mail]
>     <mailto:[e-mail]>; [e-mail]
>     <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>;
>     Alvaro Retana (aretana) <[e-mail]
>     <mailto:[e-mail]>>; [e-mail]
>     <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
>     *Subject:* Re: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)____
> 
>     __ __
> 
>     __ __
> 
>     Sasha,____
> 
>     __ __
> 
>     Thanks for the comments.____
> 
>     __ __
> 
>     In OS implementations, in particular linux, there are various
>     releases and____
> 
>     configure options, so it varies quite a bit for ARP. This pointer
>     shows how to change____
> 
>     the ARP behavior on linux:____
> 
>     __ __
> 
>     http://kb.linuxvirtualserver.org/wiki/Using_arp_announce/arp_ignore_to_disable_ARP
>     <http://kb.linuxvirtualserver.org/wiki/Using_arp_announce/arp_ignore_to_disable_ARP>____
> 
>     __ __
> 
>     For example, the variable ‘arp_ignore’, has the code sample in
>     ‘arp.c’:____
> 
>     http://elixir.free-electrons.com/linux/latest/source/net/ipv4/arp.c
>     <http://elixir.free-electrons.com/linux/latest/source/net/ipv4/arp.c>____
> 
>     __ __
> 
>     static int arp_ignore
>     <http://elixir.free-electrons.com/linux/latest/ident/arp_ignore>(struct
>     in_device
>     <http://elixir.free-electrons.com/linux/latest/ident/in_device>
>     *in_dev, __be32
>     <http://elixir.free-electrons.com/linux/latest/ident/__be32> sip
>     <http://elixir.free-electrons.com/linux/latest/ident/sip>, __be32
>     <http://elixir.free-electrons.com/linux/latest/ident/__be32> tip)____
> 
>     {____
> 
>                         struct net *net = dev_net
>     <http://elixir.free-electrons.com/linux/latest/ident/dev_net>(in_dev->dev);____
> 
>                         int scope
>     <http://elixir.free-electrons.com/linux/latest/ident/scope>;____
> 
>     __ __
> 
>                         switch (IN_DEV_ARP_IGNORE
>     <http://elixir.free-electrons.com/linux/latest/ident/IN_DEV_ARP_IGNORE>(in_dev))
>     {____
> 
>                         case 0:          /* Reply, the tip is already
>     validated */____
> 
>                                              return 0;____
> 
>                         case 1:          /* Reply only if tip is
>     configured on the incoming interface */____
> 
>                                              sip
>     <http://elixir.free-electrons.com/linux/latest/ident/sip> = 0;____
> 
>                                              scope
>     <http://elixir.free-electrons.com/linux/latest/ident/scope> =
>     RT_SCOPE_HOST
>     <http://elixir.free-electrons.com/linux/latest/ident/RT_SCOPE_HOST>;____
> 
>                                              break;____
> 
>                         case 2:          /*____
> 
>                                              * Reply only if tip is
>     configured on the incoming interface____
> 
>                                              * and is in same subnet as
>     sip____
> 
>                                              */____
> 
>                                              scope
>     <http://elixir.free-electrons.com/linux/latest/ident/scope> =
>     RT_SCOPE_HOST
>     <http://elixir.free-electrons.com/linux/latest/ident/RT_SCOPE_HOST>;____
> 
>                                              break;____
> 
>     I have two linux boxes with ubuntu 16.04 connected on an ethernet ____
> 
>     and with two different subnet:____
> 
>     lenovo (enp3s0 with IP 192.168.1.35/24 <http://192.168.1.35/24>) <—>
>     vaio (enp2s8 with IP 192.168.2.100/24 <http://192.168.2.100/24>)____
> 
>     __ __
> 
>     on vaio: I run an arping to request ARP resolution of 192.168.1.35
>     <http://192.168.1.35>:____
> 
>     vaio:~$ sudo arping 192.168.1.35 -i enp2s8____
> 
>     60 bytes from ec:a8:6b:c0:82:23 (192.168.1.35): index=0 time=6.538
>     msec____
> 
>     60 bytes from ec:a8:6b:c0:82:23 (192.168.1.35): index=1 time=1.464
>     msec____
> 
>     60 bytes from ec:a8:6b:c0:82:23 (192.168.1.35): index=2 time=8.418
>     msec____
> 
>     __ __
> 
>     I made sure on lenovo as described arp_announce is ‘2’, and
>     arp_ignore is ‘0’:____
> 
>     root@lenovo:/proc/sys/net/ipv4/conf/enp3s0# echo 2 > arp_announce ____
> 
>     root@lenovo:/proc/sys/net/ipv4/conf/enp3s0# cat arp_ignore ____
> 
>     __ __
> 
>     Run tcpdump on lenovo interface enp3s0 to get ARP packets:____
> 
>     root@lenovo:/proc/sys/net/ipv4/conf/enp3s0# tcpdump -i enp3s0 arp
>     -vv____
> 
>     __ __
> 
>     22:14:01.774491 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
>     192.168.1.35 tell 192.168.2.100, length 46____
> 
>     22:14:01.774511 ARP, Ethernet (len 6), IPv4 (len 4), Reply
>     192.168.1.35 is-at ec:a8:6b:c0:82:23 (oui Unknown), length 28____
> 
>     22:14:02.775522 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
>     192.168.1.35 tell 192.168.2.100, length 46____
> 
>     22:14:02.775541 ARP, Ethernet (len 6), IPv4 (len 4), Reply
>     192.168.1.35 is-at ec:a8:6b:c0:82:23 (oui Unknown), length 28____
> 
>     __ __
> 
>     __ __
> 
>     Ok, so what I’m getting at is that, if you know the system needs to
>     run____
> 
>     numbered and mismatched IP addresses over the same cable, then____
> 
>     regardless of p2p-over-lan or other applications, you probably need
>     to____
> 
>     adjust the local ARP behavior to match what is expected on the OS.____
> 
>     __ __
> 
>     I agree that RFC 5309 does mention the matching IP subnet, and
>     probably____
> 
>     should refer to unnumbered is the most useful use case.____
> 
>     __ __
> 
>     Best Regards,____
> 
>     - Naiming____
> 
>     __ __
> 
>         On May 1, 2017, at 12:40 AM, Alexander Vainshtein
>         <[e-mail]
>         <mailto:[e-mail]>> wrote:____
> 
>         __ __
> 
>         Naiming,____
> 
>         Lots of thanks for a prompt response.____
> 
>          ____
> 
>         Unfortunately, I do not think that your response addresses your
>         concern.____
> 
>          ____
> 
>         RFC 5309 explicitly mentions “ARP implementation (which /checks
>         that the subnet of the source address of the ARP request matches
>         the local interface address/)”. Actually, ARP implementations
>         frequently check that /the source IP address in an ARP request
>         is in the subnet of the local interface address/. E.g., AFAIK,
>         this is the standard behavior of the Linux ARP implementation.
>         To the best of my understanding this was the check that RFC 5309
>         implied, /because there is no way the subnet of the source
>         address of the ARP request could be known/.____
> 
>          ____
> 
>         If such check is applied, then the scenario I’ve described
>         becomes valid. I can add that I have observed several
>         implementations that experience the described behavior (i.e.,
>         blackholing of unicast IP traffic that OSPF tries to route via
>         such a link). Some other implementations seem to behave better.____
> 
>          ____
> 
>         Regards,____
> 
>         Sasha____
> 
>          ____
> 
>          ____
> 
>          ____
> 
>          ____
> 
>          ____
> 
>         Regards,____
> 
>         Sasha____
> 
>          ____
> 
>         Office: [phone] <tel:+972%203-926-6302>____
> 
>         Cell:      [phone] <tel:+972%2054-926-6302>____
> 
>         Email:   [e-mail]
>         <mailto:[e-mail]>____
> 
>          ____
> 
>         *From:* Naiming Shen (naiming) [mailto:[e-mail]] 
>         *Sent:* Monday, May 01, 2017 5:34 AM
>         *To:* Alexander Vainshtein <[e-mail]
>         <mailto:[e-mail]>>
>         *Cc:* Les Ginsberg (ginsberg) <[e-mail]
>         <mailto:[e-mail]>>; [e-mail]
>         <mailto:[e-mail]>; RFC Errata System
>         <[e-mail] <mailto:[e-mail]>>;
>         [e-mail]
>         <mailto:[e-mail]>; [e-mail]
>         <mailto:[e-mail]>; [e-mail]
>         <mailto:[e-mail]>; Alvaro Retana (aretana)
>         <[e-mail] <mailto:[e-mail]>>;
>         [e-mail] <mailto:[e-mail]>; [e-mail]
>         <mailto:[e-mail]>
>         *Subject:* Re: [Isis-wg] [Technical Errata Reported] RFC5309
>         (5007)____
> 
>          ____
> 
>          ____
> 
>         Alexander, ____
> 
>          ____
> 
>         If you are saying the local LAN interface is explicitly
>         configured with____
> 
>         a different subnet IP address then the peer, I don’t think there
>         is any____
> 
>         problem with the ARP, and also with this RFC. Since ARP will
>         always____
> 
>         reply to answer its own IP addresses on the interface upon
>         request.____
> 
>          ____
> 
>         This RFC is only saying, if it’s p2p-over-lan over an unnumbered
>         IP address,____
> 
>         and this LAN interface needs to proxy-ARP the IP address it
>         binds to.____
> 
>         If the ARP already replies since you have an IP address, and our____
> 
>         p2p-over-LAN intf also uses this IP address, nothing is broken.____
> 
>          ____
> 
>         thanks.____
> 
>         - Naiming____
> 
>          ____
> 
>             On Apr 30, 2017, at 8:50 AM, Alexander Vainshtein
>             <[e-mail]
>             <mailto:[e-mail]>> wrote:____
> 
>              ____
> 
>             Les,____
> 
>             Lots of thanks for a prompt response.____
> 
>              ____
> 
>             As I see it, the difference between the P2P and LAN modes is
>             essential for OSPF:____
> 
>             - If an OSPF interface is a LAN (broadcast) interface, there
>             is a check of the same subnet for received Hello packets. If
>             the received Hello packets do not pass this check, they are
>             discarded and an error is reported via SNMP.____
> 
>             - However, if an OSPF interface is a P2P interface, then the
>             subnet check on the Hello packets is bypassed  by design as
>             defined in Section 10.5 of RFC 2328:____
> 
>                    ____
> 
>                                  The generic input processing of OSPF
>             packets will____
> 
>                     have checked the validity of the IP header and the
>             OSPF packet____
> 
>                     header.  Next, the values of the Network Mask,
>             HelloInterval,____
> 
>                     and RouterDeadInterval fields in the received Hello
>             packet must____
> 
>                     be checked against the values configured for the
>             receiving____
> 
>                     interface.  Any mismatch causes processing to stop
>             and the____
> 
>                     packet to be dropped.  In other words, the above
>             fields are____
> 
>                     really describing the attached network's
>             configuration. However,____
> 
>                     there is one exception to the above rule: on
>             point-to-point____
> 
>                     networks and on virtual links, the Network Mask in
>             the received____
> 
>                     Hello Packet should be ignored.____
> 
>              ____
> 
>             I.e., having different subnets on two ends of a PPP link
>             would not cause any problems for OSPF - the adjacency would
>             be successfully recognized, it would progress to its FULL
>             state, and unicast traffic would cross such a link without
>             any problem.____
> 
>              ____
> 
>             But if we have a P2P-over-LAN link (which is the case for
>             RFC 5309), the result would be quite different - unless the
>             ARP implementations go beyond what 5309 says and relax the
>             check for all such links, be they numbered or unnumbered.____
> 
>              ____
> 
>             Do I miss something substantial here?____
> 
>              ____
> 
>              ____
> 
>              ____
> 
>             Regards,____
> 
>             Sasha____
> 
>              ____
> 
>             Office: [phone] <tel:+972%203-926-6302>____
> 
>             Cell:      [phone] <tel:+972%2054-926-6302>____
> 
>             Email:   [e-mail]
>             <mailto:[e-mail]>____
> 
>              ____
> 
>              ____
> 
>             -----Original Message-----
>             From: Les Ginsberg (ginsberg) [mailto:[e-mail]] 
>             Sent: Sunday, April 30, 2017 5:19 PM
>             To: RFC Errata System <[e-mail]
>             <mailto:[e-mail]>>; Naiming Shen (naiming)
>             <[e-mail]
>             <mailto:[e-mail]>>;[e-mail]
>             <mailto:[e-mail]>; [e-mail]
>             <mailto:[e-mail]>; [e-mail]
>             <mailto:[e-mail]>; Alvaro Retana (aretana)
>             <[e-mail]
>             <mailto:[e-mail]>>; [e-mail]
>             <mailto:[e-mail]>; [e-mail]
>             <mailto:[e-mail]>
>             Cc: Alexander Vainshtein <[e-mail]
>             <mailto:[e-mail]>>; [e-mail]
>             <mailto:[e-mail]>
>             Subject: RE: [Isis-wg] [Technical Errata Reported] RFC5309
>             (5007)____
> 
>              ____
> 
>             Alexander -____
> 
>              ____
> 
>             I am not speaking for the RFC authors, but regarding your
>             point:____
> 
>              ____
> 
>             > o          Are assigned with IP addresses and subnet masks yielding different____
> 
>             > subnets____
> 
>              ____
> 
>             I fail to see why this issue is unique to (or associated
>             with) running in P2P mode.____
> 
>              ____
> 
>             The unnumbered case is specifically mentioned because in
>             such a case it can be expected that the next hop address
>             will be a loopback address and therefore there will be no
>             common subnet.____
> 
>             But in the numbered case whether you have one neighbor in
>             P2P mode or many neighbors in multi-access mode the
>             msimatched subnet issue is the same. Therefore I see no
>             reason why these RFCs should discuss it.____
> 
>              ____
> 
>             ???____
> 
>              ____
> 
>                Les____
> 
>              ____
> 
>              ____
> 
>             > -----Original Message-----____
> 
>             > From: Isis-wg [mailto:[e-mail]
>             <mailto:[e-mail]>] On Behalf Of RFC____
> 
>             > Errata System____
> 
>             > Sent: Sunday, April 30, 2017 1:16 AM____
> 
>             > To: Naiming Shen (naiming); [e-mail]
>             <mailto:[e-mail]>;____
> 
>             > [e-mail]
>             <mailto:[e-mail]>; [e-mail]
>             <mailto:[e-mail]>; Alvaro Retana (aretana);____
> 
>             > [e-mail]
>             <mailto:[e-mail]>; [e-mail]
>             <mailto:[e-mail]>____
> 
>             > Cc: [e-mail]
>             <mailto:[e-mail]>; [e-mail]
>             <mailto:[e-mail]>;____
> 
>             > rfc-editor@rfc- editor.org
>             <http://webdefence.global.blackspider.com/urlwrap/?q=AXicE3RmiL7GwDDlCANDUU6lgUmSXnFRmV5uYmZOcn5eSVF-jl5yfi5DmYmhUUREcLmBkaGRuQmDY05qRWJeSmqRXlhiZl5xRklqZp5DanJmSWpOKlh9RklJgZW-fmpKZkl-kV5-UToDA0PFQQYGAOFQJGs&Z>____
> 
>             > Subject: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)____
> 
>             > ____
> 
>             > The following errata report has been submitted for RFC5309,____
> 
>             > "Point-to-Point Operation over LAN in Link State Routing Protocols".____
> 
>             > ____
> 
>             > --------------------------------------____
> 
>             > You may review the report below and at:____
> 
>             > http://www.rfc-editor.org/errata_search.php?rfc=5309&eid=5007
>             <http://www.rfc-editor.org/errata_search.php?rfc=5309&eid=5007>____
> 
>             > ____
> 
>             > --------------------------------------____
> 
>             > Type: Technical____
> 
>             > Reported by: Alexander Vainshtein <[e-mail]
>             <mailto:[e-mail]>>____
> 
>             > ____
> 
>             > Section: 4.3____
> 
>             > ____
> 
>             > Original Text____
> 
>             > -------------____
> 
>             > For the ARP implementation (which checks that the subnet of the source____
> 
>             > address of the ARP request matches the local interface address), this____
> 
>             > check needs to be relaxed for the unnumbered p2p-over-lan circuits.____
> 
>             > ____
> 
>             > Corrected Text____
> 
>             > --------------____
> 
>             > For the ARP implementation (which checks that the subnet of the source____
> 
>             > address of the ARP request matches the local interface address), this____
> 
>             > check needs to be relaxed for the p2p-over-lan circuits (both numbered____
> 
>             > and unnumbered).____
> 
>             > ____
> 
>             > Notes____
> 
>             > -----____
> 
>             > Consider the following situation:____
> 
>             > 1.         Two routers, R1 and R2, are connected by a physical P2P  Ethernet____
> 
>             > link____
> 
>             > 2.         OSPFv2 is enabled on the interfaces representing the endpoints of____
> 
>             > this link.____
> 
>             > 3.      From the OSPF POV these interfaces:____
> 
>             > o          Are configured as P2P____
> 
>             > o          Belong to the same area____
> 
>             > o          Are assigned with IP addresses and subnet masks yielding different____
> 
>             > subnets____
> 
>             > 4.    ARP check mentioned in the problematic text is not relaxed.____
> 
>             > ____
> 
>             > Under this conditions:____
> 
>             > -Both R1 and R2 will accept Hello messages sent by the other router____
> 
>             > (becase it ignores subnet in Hello messages received via P2P____
> 
>             > interfaces)____
> 
>             > - Adjacency between R1 and R2 will progress to FULL state (because all____
> 
>             > OSPFv2 messages will be sent with AllSPFRouters multicast IPv4____
> 
>             > address)____
> 
>             > - Unicast traffic sent by R1 to R2 (and vice versa) will be blackholed____
> 
>             > because ARP will not resolve addresses assigned to the corresponding interfaces.____
> 
>             > ____
> 
>             > Instructions:____
> 
>             > -------------____
> 
>             > This erratum is currently posted as "Reported". If necessary, please____
> 
>             > use "Reply All" to discuss whether it should be verified or rejected.____
> 
>             > When a decision is reached, the verifying party can log in to change____
> 
>             > the status and edit the report, if necessary.____
> 
>             > ____
> 
>             > --------------------------------------____
> 
>             > RFC5309 (draft-ietf-isis-igp-p2p-over-lan-06)____
> 
>             > --------------------------------------____
> 
>             > Title               : Point-to-Point Operation over LAN in Link State Routing____
> 
>             > Protocols____
> 
>             > Publication Date    : October 2008____
> 
>             > Author(s)           : N. Shen, Ed., A. Zinin, Ed.____
> 
>             > Category            : INFORMATIONAL____
> 
>             > Source              : IS-IS for IP Internets____
> 
>             > Area                : Routing____
> 
>             > Stream              : IETF____
> 
>             > Verifying Party     : IESG____
> 
>             > ____
> 
>             > ___________________________________________________
> 
>             > Isis-wg mailing list____
> 
>             > [e-mail] <mailto:[e-mail]>____
> 
>             > https://www.ietf.org/mailman/listinfo/isis-wg
>             <https://www.ietf.org/mailman/listinfo/isis-wg>____
> 
> 
>             ___________________________________________________________________________
> 
>             This e-mail message is intended for the recipient only and
>             contains information which is 
>             CONFIDENTIAL and which may be proprietary to ECI Telecom. If
>             you have received this 
>             transmission in error, please inform us by e-mail, phone or
>             fax, and then delete the original 
>             and all copies thereof.
>             _______________________________________________________________________________
> 
>          ____
> 
> 
>         ___________________________________________________________________________
> 
>         This e-mail message is intended for the recipient only and
>         contains information which is 
>         CONFIDENTIAL and which may be proprietary to ECI Telecom. If you
>         have received this 
>         transmission in error, please inform us by e-mail, phone or fax,
>         and then delete the original 
>         and all copies thereof.
>         _______________________________________________________________________________
> 
>     __ __
> 
> 
>     ___________________________________________________________________________
> 
>     This e-mail message is intended for the recipient only and contains
>     information which is
>     CONFIDENTIAL and which may be proprietary to ECI Telecom. If you
>     have received this
>     transmission in error, please inform us by e-mail, phone or fax, and
>     then delete the original
>     and all copies thereof.
>     ___________________________________________________________________________
> 
>