Dear Manav, PreCondition: 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].
Receiver side Packet Processing: On the Receiver Side i am not Fully convinced with idea of Mistreating authentication data as [Session ID and Nonce value] and probably dropping the packet. for some reason if we don't drop the packet then receiver would have already skipped 8 bytes of authentication Data interpreting that it is SESSION ID (4 bytes)and Nonce Value(4 bytes). From This offset if receiver reads authentication data as mentioned in Authentication Data Length field in AT Header then certain parsing problems can occur. Please check, if i am missing something let me Know. 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: Wednesday, January 26, 2011 4:05 pm Subject: RE: RE: [OSPF] AUTH TYPE To: RajeshShettyM 70520 <[email protected]> Cc: "[email protected]" <[email protected]> > 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
