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

From: RFC Errata System <[email-masked]>
Date: Sun, 30 Apr 2017 01:15:54 -0700 (PDT)

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-masked]>

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sun, 30 Apr 2017 14:18:52 +0000

Alexander -

> o	Are assigned with IP addresses and subnet masks yielding different

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-masked]] On Behalf Of RFC Errata
> System
> Sent: Sunday, April 30, 2017 1:16 AM
> To: Naiming Shen (naiming); [email-masked];
> [email-masked]; [email-masked]; Alvaro Retana (aretana);
> [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; rfc-editor@rfc-
> editor.org
> 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".
> 
> 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
> --------------
> 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
> -----
> -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.
> 
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 30 Apr 2017 15:50:57 +0000

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

Cell:      +972-549266302

Email:   [email-masked]

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Sunday, April 30, 2017 5:19 PM
To: RFC Errata System <[email-masked]>; Naiming Shen (naiming) <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; Alvaro Retana (aretana) <[email-masked]>; [email-masked]; [email-masked]
Cc: Alexander Vainshtein <[email-masked]>; [email-masked]
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

???

   Les

> From: Isis-wg [mailto:[email-masked]] On Behalf Of RFC

> Errata System

> To: Naiming Shen (naiming); [email-masked]<mailto:[email-masked]>;

> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Alvaro Retana (aretana);

> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;

> rfc-editor@rfc- editor.org

> Reported by: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>

> address of the ARP request matches the local interface address), this

> check needs to be relaxed for the unnumbered p2p-over-lan circuits.

> 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).

> 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.

> o          Are assigned with IP addresses and subnet masks yielding different

> subnets

> (becase it ignores subnet in Hello messages received via P2P

> interfaces)

> 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.

> 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.

> Title               : Point-to-Point Operation over LAN in Link State Routing

> Protocols

> [email-masked]<mailto:[email-masked]>

> 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.
___________________________________________________________________________

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sun, 30 Apr 2017 19:43:58 +0000

Sasha -

The language you are asking to be changed is in regards to ARP. I am saying allowing an adjacency to be formed on a numbered LAN with mismatched subnets is neither introduced nor altered by these RFCs .
What is introduced is the possibility of operating on an unnumbered LAN - which is why the RFCs speak to that.

If you want to ask that protocol base specifications discuss ARP issues when mismatched subnets are allowed (which I am NOT encouraging you to do) then you will be directing your comments at the correct documents.
Asking that of these RFCs is inappropriate.

   Les

From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Sunday, April 30, 2017 8:51 AM
To: Les Ginsberg (ginsberg)
Cc: [email-masked]; RFC Errata System; Naiming Shen (naiming); [email-masked]; [email-masked]; [email-masked]; Alvaro Retana (aretana); [email-masked]; [email-masked]
Subject: RE: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

Les,

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

Email:   [email-masked]<mailto:[email-masked]>

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Sunday, April 30, 2017 5:19 PM
To: RFC Errata System <[email-masked]<mailto:[email-masked]>>; Naiming Shen (naiming) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Alvaro Retana (aretana) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

Alexander -

???

   Les

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Mon, 1 May 2017 02:33:31 +0000

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-masked]<mailto:[email-masked]>> wrote:

Les,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Sunday, April 30, 2017 5:19 PM
To: RFC Errata System <[email-masked]<mailto:[email-masked]>>; Naiming Shen (naiming) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Alvaro Retana (aretana) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

Alexander -

???

   Les

> rfc-editor@rfc- editor.org<http://editor.org>