Re: [Technical Errata Reported] RFC5309 (5007)

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 <
[email protected]> 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: +972-39266302 <+972%203-926-6302>
>
> Cell:      +972-549266302 <+972%2054-926-6302>
>
> Email:   [email protected]
>
>
>
> *From:* Naiming Shen (naiming) [mailto:[email protected]]
> *Sent:* Friday, May 05, 2017 8:44 AM
>
> *To:* Alexander Vainshtein <[email protected]>
> *Cc:* Les Ginsberg (ginsberg) <[email protected]>; [email protected]; RFC
> Errata System <[email protected]>; [email protected];
> [email protected]; [email protected]; Alvaro Retana (aretana) <
> [email protected]>; [email protected]; [email protected]
> *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
>
>
>
> 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
>
>
>
> 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) <—> vaio (enp2s8 with IP
> 192.168.2.100/24)
>
>
>
> on vaio: I run an arping to request ARP resolution of 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 <
> [email protected]> 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: +972-39266302 <+972%203-926-6302>
>
> Cell:      +972-549266302 <+972%2054-926-6302>
>
> Email:   [email protected]
>
>
>
> *From:* Naiming Shen (naiming) [mailto:[email protected]
> <[email protected]>]
> *Sent:* Monday, May 01, 2017 5:34 AM
> *To:* Alexander Vainshtein <[email protected]>
> *Cc:* Les Ginsberg (ginsberg) <[email protected]>; [email protected]; RFC
> Errata System <[email protected]>; [email protected];
> [email protected]; [email protected]; Alvaro Retana (aretana) <
> [email protected]>; [email protected]; [email protected]
> *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 <
> [email protected]> 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: +972-39266302 <+972%203-926-6302>
>
> Cell:      +972-549266302 <+972%2054-926-6302>
>
> Email:   [email protected]
>
>
>
>
>
> -----Original Message-----
> From: Les Ginsberg (ginsberg) [mailto:[email protected]
> <[email protected]>]
> Sent: Sunday, April 30, 2017 5:19 PM
> To: RFC Errata System <[email protected]>; Naiming Shen (naiming)
> <[email protected]>;[email protected]; [email protected];
> [email protected]; Alvaro Retana (aretana) <[email protected]>; chopps@
> chopps.org; [email protected]
> Cc: Alexander Vainshtein <[email protected]>;
> [email protected]
> 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:[email protected]
> <[email protected]>] On Behalf Of RFC
>
> > Errata System
>
> > Sent: Sunday, April 30, 2017 1:16 AM
>
> > To: Naiming Shen (naiming); [email protected];
>
> > [email protected]; [email protected]; Alvaro Retana (aretana);
>
> > [email protected]; [email protected]
>
> > Cc: [email protected]; [email protected];
>
> > 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
>
> >
>
> > --------------------------------------
>
> > Type: Technical
>
> > Reported by: Alexander Vainshtein <[email protected]>
>
> >
>
> > 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
>
> > [email protected]
>
> > 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.
> ____________________________________________________________
> _______________
>

_______________________________________________
Isis-wg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/isis-wg