Subject: Re: [OSPF] New Version Notification for draft-acee-ospf-rfc6506bis-01.txt

From: Michael Barnes <[email-masked]>
Date: Thu, 06 Jun 2013 13:12:00 -0700

I agree these are good changes. Acee, please move forward with this draft.

Thanks,
Michael

On 05/09/2013 11:03 AM, Acee Lindem wrote:
> There have been a couple errata filed on RFC 6505 (authors copied). As a service to the
> OSPF community and in an effort to ensure interoperable OSPFv3 authentication
> trailer implementations, I have produced a BIS draft. The changes are listed in
> section 1.2:
>
> 1.2.  Summary of Changes from RFC 6506
>
>     This document includes the following changes from RFC 6506 [RFC6506]:
>
>     1.  Sections 2.2 and 4.2 explicitly state the Link-Local Signalling
>         (LLS) block checksum calculation is omitted when an OSPFv3
>         authentication is used.  The LLS block is included in the
>         authentication digest calculation and computation of a checksum
>         is unneccessary.  Clarification of this issue was raised in an
>         errata.
>
>     2.  Section 4.5 includes a correction to the key preparation to use
>         the protocol specific key (Ks) rather than the key (K) as the
>         initial key (Ko).  This problem was also raised in an errata.
>
>     3.  Section 4.5 also includes a discussion of the choice of key
>         length to be the hash length (L) rather than the block size (B).
>         The discussion of this choice was included to clarify an issue
>         raised in a rejected errata.
>
>     4.  Section 4.1 indicates that sequence number checking is dependent
>         on OSPFv3 packet type in order to account for packet
>         prioritization as specified in [RFC4222].  This was an omission
>         from RFC 6506.
>
>
> I would like to quickly move this to an OSPF WG document and begin the review process. I'm now soliciting feedback on OSPF WG adoption.
>
> Thanks,
> Acee
>
>
> On May 9, 2013, at 1:43 PM, <[email-masked]>
>   wrote:
>
>>
>> A new version of I-D, draft-acee-ospf-rfc6506bis-01.txt
>> has been successfully submitted by Manav Bhatia and posted to the
>> IETF repository.
>>
>> Filename:	 draft-acee-ospf-rfc6506bis
>> Revision:	 01
>> Title:		 Supporting Authentication Trailer for OSPFv3
>> Creation date:	 2013-05-09
>> Group:		 Individual Submission
>> Number of pages: 25
>> URL:             http://www.ietf.org/internet-drafts/draft-acee-ospf-rfc6506bis-01.txt
>> Status:          http://datatracker.ietf.org/doc/draft-acee-ospf-rfc6506bis
>> Htmlized:        http://tools.ietf.org/html/draft-acee-ospf-rfc6506bis-01
>> Diff:            http://www.ietf.org/rfcdiff?url2=draft-acee-ospf-rfc6506bis-01
>>
>> Abstract:
>>    Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism
>>    for authenticating protocol packets.  This behavior is different from
>>    authentication mechanisms present in other routing protocols (OSPFv2,
>>    Intermediate System to Intermediate System (IS-IS), RIP, and Routing
>>    Information Protocol Next Generation (RIPng)).  In some environments,
>>    it has been found that IPsec is difficult to configure and maintain
>>    and thus cannot be used.  This document defines an alternative
>>    mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does
>>    not only depend upon IPsec for authentication.  This document
>>    obsoletes RFC 6506.
>>
>>
>>
>>
>> The IETF Secretariat
>>
>
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf
>

---

From: Acee Lindem <[email-masked]>
Date: Tue, 11 Jun 2013 11:35:23 +0000

Thank Michael - Does anyone else support this work? I think it will help
ensure compatibility between implementations. I would have expected at
least those who submitted the corrected errata to support the draft.
Thanks,
Acee

On 6/6/13 1:12 PM, "Michael Barnes" <[email-masked]> wrote:

>> I would like to quickly move this to an OSPF WG document and begin the
>>review process. I'm now soliciting feedback on OSPF WG adoption.
>>
>> Thanks,
>> Acee
>>
>>
>>> URL:           
>>>http://www.ietf.org/internet-drafts/draft-acee-ospf-rfc6506bis-01.txt
>>> Status:        
>>>http://datatracker.ietf.org/doc/draft-acee-ospf-rfc6506bis
>>> Htmlized:      
>>>http://tools.ietf.org/html/draft-acee-ospf-rfc6506bis-01
>>> Diff:          
>>>http://www.ietf.org/rfcdiff?url2=draft-acee-ospf-rfc6506bis-01
>>>
>>> Abstract:

---

From: "Marek Karasek (mkarasek)" <[email-masked]>
Date: Tue, 11 Jun 2013 13:26:00 +0000

Hi Acee,

I support bis version as well.

I have one more suggestion though for this paragraph:

   In support of uninterrupted deployment, an OSPFv3 router implementing
   this specification MAY implement a transition mode where it includes
   the Authentication Trailer in transmitted packets but does not verify
   this information in received packets.  This is provided as a
   transition aid for networks in the process of migrating to the
   authentication mechanism described in this specification.

Can it be explicitly added how to work with checksums in the transition (or deployment) mode? I suggest adding:

- For OSPFv3 packets to be transmitted in deployment mode, the OSPFv3 header checksum and LLS data block checksum is computed and written in the packets.
- For packets received in deployment mode which include an OSPFv3 Authentication Trailer, OSPFv3 header checksum verification MUST be omitted.
- For packets received in deployment mode which do not include an OSPFv3 Authentication Trailer, OSPFv3 header checksum and LLS data block checksum are verified.

Thanks marek

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Acee Lindem
Sent: Tuesday, June 11, 2013 1:35 PM
To: Michael Barnes (mjbarnes); [email-masked]
Subject: Re: [OSPF] New Version Notification for draft-acee-ospf-rfc6506bis-01.txt

Thank Michael - Does anyone else support this work? I think it will help ensure compatibility between implementations. I would have expected at least those who submitted the corrected errata to support the draft.
Thanks,
Acee

On 6/6/13 1:12 PM, "Michael Barnes" <[email-masked]> wrote:

>> There have been a couple errata filed on RFC 6505 (authors copied). 
>>As a service to the  OSPF community and in an effort to ensure 
>>interoperable OSPFv3 authentication  trailer implementations, I have 
>>produced a BIS draft. The changes are listed in  section 1.2:
>>
>> I would like to quickly move this to an OSPF WG document and begin 
>>the review process. I'm now soliciting feedback on OSPF WG adoption.
>>
>> Thanks,
>> Acee
>>
>>
>>> A new version of I-D, draft-acee-ospf-rfc6506bis-01.txt has been 
>>> successfully submitted by Manav Bhatia and posted to the IETF 
>>> repository.
>>>

---

From: Acee Lindem <[email-masked]>
Date: Tue, 11 Jun 2013 13:43:34 +0000

Hi Marek, 
I've thought about it and this would be compatible with the rest of the draft. It would be useful if incremental deployment is a concern. I have no objection to adding this. Any other opinions? 

Thanks,
Acee

---

From: Anton Smirnov <[email-masked]>
Date: Tue, 11 Jun 2013 22:20:01 +0200

Hi Acee,
    I also support bis revision - couple of points not covered in the 
original document may negatively impact interoperability between 
different implementations.

    Regarding sequence numbers - if I understand wording in 'bis' 
revision correctly, sender is using single incrementing sequence number 
counter independent of packet type and receiver is using one sequence 
number per packet type, correct? I am asking because RFC 4222 recommends 
to sort packets into two classes (i.e. not as many classes as there are 
packet types), so mentioning it may be somewhat confusing.

Anton

---

From: Acee Lindem <[email-masked]>
Date: Tue, 11 Jun 2013 21:29:27 +0000

Hi Anton, 

I am glad you asked. 

On Jun 11, 2013, at 4:20 PM, Anton Smirnov wrote:

>   Hi Acee,
>   I also support bis revision - couple of points not covered in the original document may negatively impact interoperability between different implementations.
> 
>   Regarding sequence numbers - if I understand wording in 'bis' revision correctly, sender is using single incrementing sequence number counter independent of packet type and receiver is using one sequence number per packet type, correct? I am asking because RFC 4222 recommends to sort packets into two classes (i.e. not as many classes as there are packet types), so mentioning it may be somewhat confusing.

Excerpt from section 1.2:

   4.  Section 4.1 and 4.6 indicate that sequence number checking is
       dependent on OSPFv3 packet type in order to account for packet
       prioritization as specified in [RFC4222].  This was an omission
       from RFC 6506.

Thanks,
Acee

---

From: Acee Lindem <[email-masked]>
Date: Wed, 12 Jun 2013 20:59:15 +0000

Hi Marek,
I thought about this and I think we need to modify the behavior in
transition mode for this to provide a smooth transition. An OSPFv3 router
in transition mode needs to "be conservative in what it sends and liberal
in what it accepts". Hence, in transition mode, the router would accept
packet with and without an authentication trailer but would not include
the authentication trailer in this mode. If you don't do it this way,
you'll have a deployment window problem since routers in transition mode
will still be sending packets that won't be accepted by routers that have
not yet been converted - they'll be dropped due to checksum errors. If you
don't include the authentication header, you just need to:

       1. Convert all the nodes in the routing domain to OSPFv3
authentication transition mode. There will be no timing dependencies.
       2. Convert routers to send at the authentication trailer in any
order. 

Agree? 

Thanks,
Acee 

On 6/11/13 6:43 AM, "Acee Lindem" <[email-masked]> wrote:

>Hi Marek, 
>I've thought about it and this would be compatible with the rest of the
>draft. It would be useful if incremental deployment is a concern. I have
>no objection to adding this. Any other opinions?
>
>Thanks,
>Acee
>> - For OSPFv3 packets to be transmitted in deployment mode, the OSPFv3
>>header checksum and LLS data block checksum is computed and written in
>>the packets.
>> - For packets received in deployment mode which include an OSPFv3
>>Authentication Trailer, OSPFv3 header checksum verification MUST be
>>omitted.
>> - For packets received in deployment mode which do not include an
>>OSPFv3 Authentication Trailer, OSPFv3 header checksum and LLS data block
>>checksum are verified.
>> 
>> 
>> Thanks marek
>> 
>> 
>> Thank Michael - Does anyone else support this work? I think it will
>>help ensure compatibility between implementations. I would have expected
>>at least those who submitted the corrected errata to support the draft.
>> Thanks,
>> Acee
>>

---

From: "Marek Karasek (mkarasek)" <[email-masked]>
Date: Wed, 12 Jun 2013 21:23:25 +0000

Hi Acee,

Please see %MK in your lines:

-----Original Message-----
From: Acee Lindem [mailto:[email-masked]] 
Sent: Wednesday, June 12, 2013 10:59 PM
To: Marek Karasek (mkarasek)
Cc: [email-masked]
Subject: Re: [OSPF] New Version Notification for draft-acee-ospf-rfc6506bis-01.txt

Hi Marek,
I thought about this and I think we need to modify the behavior in transition mode for this to provide a smooth transition. An OSPFv3 router in transition mode needs to "be conservative in what it sends and liberal in what it accepts". Hence, in transition mode, the router would accept packet with and without an authentication trailer but would not include the authentication trailer in this mode. If you don't do it this way, you'll have a deployment window problem since routers in transition mode will still be sending packets that won't be accepted by routers that have not yet been converted - they'll be dropped due to checksum errors. 

>>header checksum and LLS data block checksum is computed and written in 

If you don't include the authentication header, you just need to:

       1. Convert all the nodes in the routing domain to OSPFv3 authentication transition mode. There will be no timing dependencies.
       2. Convert routers to send at the authentication trailer in any order. 

%MK what happens if router with AT receives packet without AT (from router doing transition)? I think it will be dropped. That's the issue.

My idea (already tested) was:
1) start deployment in "transition" mode.
Transitioning routers will add AT.
1a) Routers without AT will ignore AT and verify CRC as usual. Note CRC is computed so packet is OK for them. 
1b) Routers running AT transition or AT will verify AT. Router running AT transition will not drop if problem with AT, they will verify also CRC and if OK packet is accepted.
2) Say all or most of routers are in "transition" mode. There will be show command option to verify that AT works OK since AT is verified, but packet is not dropped if AT NOK or not present. AT incompatible neighbors may be pointed out and fixed.
3) If all looks OK, you can move routers to standard AT mode at any time. They will stop computed CRC, it's not needed anymore.

Thanks marek

Agree? 

Thanks,
Acee 

On 6/11/13 6:43 AM, "Acee Lindem" <[email-masked]> wrote:

>draft. It would be useful if incremental deployment is a concern. I 
>have no objection to adding this. Any other opinions?
>
>Thanks,
>Acee
>> Can it be explicitly added how to work with checksums in the 
>>transition (or deployment) mode? I suggest adding:
>> 
>>OSPFv3 Authentication Trailer, OSPFv3 header checksum and LLS data 
>>block checksum are verified.
>> 
>> 
>> Thanks marek
>> 
>> 
>>help ensure compatibility between implementations. I would have 
>>expected at least those who submitted the corrected errata to support the draft.
>> Thanks,
>> Acee
>> 
>>>> interoperable OSPFv3 authentication  trailer implementations, I 
>>>> have produced a BIS draft. The changes are listed in  section 1.2:
>>>>

---

From: Acee Lindem <[email-masked]>
Date: Wed, 12 Jun 2013 21:39:01 +0000

Hi Marek,

>>> header checksum and LLS data block checksum is computed and written in 

Ok - I thought of this alternative but missed that you included it. At first, I thought the above would be simpler since it only modified the receiving side. 

> %MK what happens if router with AT receives packet without AT (from router doing transition)? I think it will be dropped. That's the issue.

Yes - I can see how taking doing both authentication and checksums could be simpler on multi-access links. We can stay with this. 

Thanks,
Acee