Subject: [OSPF] Suresh Krishnan's Discuss on draft-ietf-ospf-transition-to-ospfv3-10: (with DISCUSS and COMMENT)

From: "Suresh Krishnan" <[email-masked]>
Date: Tue, 28 Jun 2016 20:41:22 -0700

Suresh Krishnan has entered the following ballot position for
draft-ietf-ospf-transition-to-ospfv3-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ospf-transition-to-ospfv3/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I do think this is a good mechanism to transition from IPv4-only OSPFv2
to dual-stack capable OSPFv3 and I intend to switch to a Yes once my
discuss points are addressed. 

* The calculation for the checksum field in the OSPFv3 packet is not
specified in this document. The RFC5340 checksum calculation uses the
IPv6 pseudo-header mechanism for upper layer checksums as specified in
Section 8.1 of RFC2460. Since that obviously won't work here (as there
are no source and dest IPv6 addresses) some different mechanism needs to
be specified here.
* (based on the above) Why doesn't this document update RFC5340?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I do have one question that I am curious about. Can this mechanism be run
alongside OSPFv2 on the same router? If so, how does the demultiplexing
take place to dispatch the packet to either the OSPFv2 or the
OSPFv3-over-IPv4 implementation (as the endpoints are potentially the
same and the IP proto number 89 is usually dispatched to OSPFv2)? Does it
require inserting some sort of shim in the OSPFv2 implementation to
further dispatch on the version number octet?

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 29 Jun 2016 13:49:11 +0000

Hi Suresh, 

>https://datatracker.ietf.org/doc/draft-ietf-ospf-transition-to-ospfv3/

Agreed. We will add this - not sure how we missed it. Many IPv4 protocols
(including OSPFv2 as described in RFC 2328) exclude the pseudo-header from
the standard checksum calculation. Since we have it in OSPFv3 over IPv6
with the RFC 2460 pseudo header, I feel we should retain it here lest we
open up OSPFv3 to a documented OSPFv3 vulnerably when authentication is
not used. 

I propose we just use a variant of the UDP pseudo header as described in
RFC 768. 

For IPv4 transport, the pseudo-header used in the checksum calculation
will 
contain the IPv4 source and destination addresses, the OSPFv3 protocol ID,
and the OSPFv3 length from the OSPFv3 header (Appendix A.3.1 [RFC5340]).
The format is similar to the UDP pseudo-header as described in [RFC768].

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Source Address                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Destination Address                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     0         | Protocol (89) |     OSPFv3 Packet Length      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

>* (based on the above) Why doesn't this document update RFC5340?

It could. However, RFC 5340 solely describes OSPFv3 with IPv6 transport.
Whether or not an enhancement that doesn’t change an existing
specification but augments it has always been a debate. We usually err on
the side of updating. What is the IESG take on this?

No shim is necessary since both OSPFv2 and OSPFv3 will check the version
number in the first octet of the OSPF(v3) packet header. Commercial
implementations normally would normally drop the packet before this stage
unless one has both OSPFv2 and OSPFv3 running on the same interface.
However, I think this should be discussed in a “Management Considerations”
section. 

 5.0 Management Considerations
 
 5.1 Coexistence with OSPFv2

 Since OSPFv2 [RFC2328] and OSPFv3 over IPv4 as described herein use
 exactly the same protocol and IPv4 addresses, OSPFv2 packets may be
 delivered to the OSPFv3 process and vice versa. When this occurs, the
 mismatched protocol packets will be dropped due to validation of the
 version in the first octet of the OSPFv2/OSPFv3 protocol header. Note
 that this will not prevent the packets from being delivered to the
 correct protocol process as standard socket implementations will
 deliver a copy to each socket matching the selectors.

 Implementations of OSPFv3 over IPv4 transport SHOULD implement
 separate counters for a protocol mismatch and SHOULD provide
 means to suppress the ospfIfRxBadPacket and ospfVirtIfRxBadPacket
 SNMP notifications as described in [RFC4750] and the
 ospfv3IfRxBadPacket and ospv3VirtIfRxBadPacket SNMP notifications
 as described in [RFC5643] when an OSPFv2 packet is received by
 the OSPFv3 process or vice versa.

Thanks,
Acee

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 29 Jun 2016 15:10:16 +0000

Hi Acee,
   Thanks for the quick turanround. All your proposed changes look good to 
me. I will clear as soon as a new version posts. We can probably discuss the 
"Updates:" issue on the telechat but I do not have strong feelings about this 
one way or another.

Cheers
Suresh

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 29 Jun 2016 19:24:30 +0000

Hi Suresh, 

We’ve updated the draft.

Thanks,
Acee

On 6/29/16, 11:10 AM, "Suresh Krishnan" <[email-masked]>
wrote:

>>> Please refer to
>>>https://www.ietf.org/iesg/statement/discuss-criteria.html

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 29 Jun 2016 23:13:11 +0000

Thanks Acee. Looks good to me. I have cleared.

Regards
Suresh