Hi Rajesh, I don't think so. In this case it should just fail the authentication, or the basic parsing checks should fail and the packet should be rejected. I see no reason why this would lead to an exception.
Cheers, Manav > -----Original Message----- > From: RajeshShettyM 70520 [mailto:[email protected]] > Sent: Wednesday, January 26, 2011 3.40 PM > To: Bhatia, Manav (Manav) > Cc: [email protected] > Subject: Re: RE: [OSPF] AUTH TYPE > > Dear Manav, > > i think idea of breaking 16 bit reserved field into an 8 bit > reserved field and an 8 bit AuType field is better. > > About associating auth type with Key ID, this option seems to > be risky in case of misconfiguration (or transient > configuration condition).if sender sends with Key ID X > (Normal Cryptographic authentication) and in receiver KEY ID > X is configured for [crypto session with Session ID and > Nonce],then the packet processing might result into exception. > > > Thanks > Rajesh > > > > > > ************************************************************** > **************************** > This email and its attachments contain confidential > information from HUAWEI, which is intended only for the > person or entity whose address is listed above. Any use of > the information contained here in any way (including, but not > limited to, total or partial disclosure, reproduction, or > dissemination) by persons other than the intended > recipient(s) is prohibited. If you receive this email in > error, please notify the sender by phone or email immediately > and delete it! > > ************************************************************** > *************************** > > ----- Original Message ----- > From: "Bhatia, Manav (Manav)" <[email protected]> > Date: Tuesday, January 25, 2011 4:37 am > Subject: RE: [OSPF] AUTH TYPE > To: Rajesh Shetty <[email protected]>, "[email protected]" > <[email protected]> > > > Hi Rajesh, > > > > I agree that such a distinction is indeed required. However, cant > > the KeyID be used for such purposes? How about also associating the > > authentication type with the Key ID. Thus one knows that if the > > incoming packet is coming with KeyID X then its normal > > cryptographic authentication, and if its coming with Y, then its > > the crypto session with Session ID and Nonce. This would also > > dictate how this packet should be further parsed. > > > > I am btw also amenable to the idea of breaking the 16 bit reserved > > field into an 8 bit reserved field and an 8 bit AuType field. > > However, just want to make sure that we absolutely need this before > > doing it. > > > > Would also like to hear what others in WG think about this. > > > > Cheers, Manav > > > > ________________________________ > > From: [email protected] [mailto:[email protected]] On > > Behalf Of Rajesh Shetty > > Sent: Friday, January 21, 2011 7.32 AM > > To: [email protected] > > Subject: [OSPF] AUTH TYPE > > > > Hi Manav, > > > > Auth Type we might need to add in AT(Authentication Trailer) Header > > for extensibility. > > Currently itself we can see the usage of Auth Type. > > > > Auth Type = 0 = Cryptographic authentication > > Auth Type = 1 (May be) = Cryptographic authentication with Session > > ID/Nonce support (security extension for ospfv3 when using manual > > key management) > > > > So its better to replace Reserved filed with Auth Type. > > > > > > Thanks > > Rajesh. > > > _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
