Subject: [OSPF] draft-acee-ospf-multi-instance-00

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 24 Jan 2008 09:49:50 -0800

Hi Acee,

I wanted to know if this draft was backward compatible with current
implementation. If its not, I was also eager to know, if we have a way
for incremental deployment.

Thanks,
Vishwas

_______________________________________________
OSPF mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ospf

---

From: Acee Lindem <[email-masked]>
Date: Thu, 24 Jan 2008 13:56:01 -0500

Hi Vishwas,

 From a protocol standpoint, it is completely backward compatible.  
OSPF routers not supporting the draft but receiving a multicast OSPF  
packet with a non-zero instance ID will simply treat it as an unknown  
AuType and fail authentication.

With this respect, RFC 2328 simply states:

  8.2.  Receiving protocol packets
                          o
                          o
                          o
  o   The packet must be authenticated.  The authentication
        procedure is indicated by the setting of AuType (see
        Appendix D).  The authentication procedure may use one or
        more Authentication keys, which can be configured on a per-
         interface basis.  The authentication procedure may also
         verify the checksum field in the OSPF packet header (which,
         when used, is set to the standard IP 16-bit one's complement
         checksum of the OSPF packet's contents after excluding the
         64-bit authentication field).  If the authentication
         procedure fails, the packet should be discarded.

And:

     D.5 Message verification

         When an OSPF packet has been received on an interface, it must
         be authenticated. The authentication procedure is indicated by
         the setting of Autype in the standard OSPF packet header, which
         matches the setting of Autype for the receiving OSPF interface.

         If an OSPF protocol packet is accepted as authentic, processing
         of the packet continues as specified in Section 8.2. Packets
         which fail authentication are discarded.

Speaking as a draft author (not OSPF WG Co-chair):

Unfortunately, some well-deployed implementations make a bigger fuss  
than is necessary when an authentication failure occurs. IMHO, now  
would be a good time to rectify this to lesses the impact should this  
draft be accepted as a standards track document. Of course, there are  
manual ways of segregating the multi-access networks to avoid down- 
level routers from receiving multicast packets for non-zero  
instances. Perhaps, we should discuss these in the draft and dispense  
with the more radical discussions of requesting new multicast  
addresses or other IANA code points.

Thanks,
Acee

---

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 24 Jan 2008 11:28:09 -0800

Hi Acee,

Thanks a lot for the reply. The backward compatibility issue would
come unless there would be the case that the draft would not use
instance ID 0 (when working with a router not supporting the
functionality - where it would be treated as no instance - rather than
a particular instance). May be that could be clarified.

I understand what you mean - but would using LLS (which is now a part
of standards track now) be of any more help?

Thanks again,
Vishwas

On Jan 24, 2008 10:56 AM, Acee Lindem <[email-masked]> wrote:
>  Hi Vishwas,
>
> From a protocol standpoint, it is completely backward compatible. OSPF
> routers not supporting the draft but receiving a multicast OSPF packet with
> a non-zero instance ID will simply treat it as an unknown AuType and fail
> authentication.
>
> Unfortunately, some well-deployed implementations make a bigger fuss than is
> necessary when an authentication failure occurs. IMHO, now would be a good
> time to rectify this to lesses the impact should this draft be accepted as a
> standards track document. Of course, there are manual ways of segregating
> the multi-access networks to avoid down-level routers from receiving
> multicast packets for non-zero instances. Perhaps, we should discuss these
> in the draft and dispense with the more radical discussions of requesting
> new multicast addresses or other IANA code points.
>
> Thanks,
> Acee
>
>
>
>

---

From: Acee Lindem <[email-masked]>
Date: Thu, 24 Jan 2008 14:43:29 -0500

Hi Vishwas,

> of standards track now) be of any more help?

LLS is only for hello and DD packets. This is required for all OSPF  
packets. Also, I'd rather keep the solutions aligned with what we  
have today with OSPFv3. Furthermore, if there are implementations  
that gratuitously log authentication failures, there may be  
implementations that do the same for unrecognized LLS TLVs.

Thanks,
Acee

>> OSPF

---

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 24 Jan 2008 12:09:20 -0800

Hi Acee,

I agree. The behavior of what needs to be done if one supports
instances and the other does not - retry without the instance field
set or not have adjacencies at all in such a case.

Thanks,
Vishwas

---

From: "Sina Mirtorabi" <[email-masked]>
Date: Thu, 24 Jan 2008 15:44:02 -0800

Hi Vishwas 

->-----Original Message-----
->From: Vishwas Manral [mailto:[email-masked]] 
->Sent: Thursday, January 24, 2008 11:28 AM
->To: Acee Lindem
->Cc: OSPF List
->Subject: [OSPF] Re: draft-acee-ospf-multi-instance-00
->
->Hi Acee,
->
->Thanks a lot for the reply. The backward compatibility issue 
->would come unless there would be the case that the draft 
->would not use instance ID 0 (when working with a router not 
->supporting the functionality - where it would be treated as 
->no instance - rather than a particular instance). May be that 
->could be clarified.

The instance 0 is simply a reserved instance to interact with legacy
routers. Note that the reception of the OSPF packet with instance ID
field set to 0, cannot (and need not) imply if the remote router is /
'is not' Instance capable. If such a capability discovery is a
requirement, the Instance ID can be carried in Hello using LLS..

Thanks
Sina

->
->I understand what you mean - but would using LLS (which is 
->now a part of standards track now) be of any more help?
->
->Thanks again,
->Vishwas
->
->On Jan 24, 2008 10:56 AM, Acee Lindem <[email-masked]> wrote:
->>  Hi Vishwas,
->>
->> From a protocol standpoint, it is completely backward 
->compatible. OSPF 
->> routers not supporting the draft but receiving a multicast 
->OSPF packet 
->> with a non-zero instance ID will simply treat it as an 
->unknown AuType 
->> and fail authentication.
->>
->> With this respect, RFC 2328 simply states:
->>
->>
->>  8.2.  Receiving protocol packets
->>                          o
->>                          o
->>                          o
->>  o   The packet must be authenticated.  The authentication
->>        procedure is indicated by the setting of AuType (see
->>        Appendix D).  The authentication procedure may use one or
->>        more Authentication keys, which can be configured on a per-
->>         interface basis.  The authentication procedure may also
->>         verify the checksum field in the OSPF packet header (which,
->>         when used, is set to the standard IP 16-bit one's complement
->>         checksum of the OSPF packet's contents after excluding the
->>         64-bit authentication field).  If the authentication
->>         procedure fails, the packet should be discarded.
->>
->>
->> And:
->>
->>
->>     D.5 Message verification
->>
->>         When an OSPF packet has been received on an 
->interface, it must
->>         be authenticated. The authentication procedure is 
->indicated by
->>         the setting of Autype in the standard OSPF packet 
->header, which
->>         matches the setting of Autype for the receiving 
->OSPF interface.
->>
->>         If an OSPF protocol packet is accepted as 
->authentic, processing
->>         of the packet continues as specified in Section 8.2. Packets
->>         which fail authentication are discarded.
->>
->> Speaking as a draft author (not OSPF WG Co-chair):
->>
->> Unfortunately, some well-deployed implementations make a 
->bigger fuss 
->> than is necessary when an authentication failure occurs. IMHO, now 
->> would be a good time to rectify this to lesses the impact 
->should this 
->> draft be accepted as a standards track document. Of course, 
->there are 
->> manual ways of segregating the multi-access networks to avoid 
->> down-level routers from receiving multicast packets for non-zero 
->> instances. Perhaps, we should discuss these in the draft 
->and dispense 
->> with the more radical discussions of requesting new 
->multicast addresses or other IANA code points.
->>
->> Thanks,
->> Acee
->>
->>
->>
->>
->> On Jan 24, 2008, at 12:49 PM, Vishwas Manral wrote:
->>
->> Hi Acee,
->>
->> I wanted to know if this draft was backward compatible with current 
->> implementation. If its not, I was also eager to know, if we 
->have a way 
->> for incremental deployment.
->>
->> Thanks,
->> Vishwas
->>
->
->_______________________________________________
->OSPF mailing list
->[email-masked]
->https://www1.ietf.org/mailman/listinfo/ospf
->

---

From: Acee Lindem <[email-masked]>
Date: Thu, 24 Jan 2008 20:36:22 -0500

Hi Vishwas,

I hope the draft isn't this confusing. We don't want routers that  
don't support the draft to do anything. They just happen to get OSPF  
packets multicast on broadcast interfaces sent to  
224.0.0.5/224.0.0.6. These OSPF router will still be able to use the  
standard instance (i.e., 0). For non-zero instances, these routers  
will drop the packets due to authentication failures. Unfortunately,  
some routers will also fill their logs with errors.

Thanks,
Acee