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

[Acee Lindem <[e-mail]>]

Hi Vishwas,

On Jan 24, 2008, at 2:28 PM, Vishwas Manral wrote:

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

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

>
> Thanks again,
> Vishwas
>
> On Jan 24, 2008 10:56 AM, Acee Lindem <[e-mail]> 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/ospf