Re: [OPSEC] minutes part 2

["Vishwas Manral" <[e-mail]>]

Hi Ran,

This is a more precise mail. Thanks a lot for the effort.

> Can we please get answers to these questions -- which in fact
> are entirely on topic for the OPsec WG, since they are all
> operational security matters ?
>
> (Single quotes are from me; double-quotes are from Vishwas'
> earlier emails.)
>
> 1:  OSPF with Digital Signatures
>>
>> OSPF with Digital Signatures is an existing mechanism (RFC-2154).
>> Is it discussed at the same level of detail as other mechanisms ?
No, it is not discussed in the document. The RFC you mention is an
Experimental RFC. The draft talks about "Issues with Existing
Cryptographic Mechanisms with Routing Protocols". We can discuss the
same however (though I would feel it may not exactly fit the draft).

> 2:  Filtering of IGP packets
>>>
>>> I have mentioned cases where they may not be able to be filtered.
>>
>> Which specific cases ? Please provide a URL for your note to the OPsec
>> list where you detailed those cases. I have looked, and I can't find
>> that note in the OPsec list web archives, terribly sorry.
>
> This is an immediate operational security issue, if true.
> I'm sure I'm not the only person who'd like to understand
> the claim more precisely.
I have mentioned it in the mail earlier and will mention it again.
When an IGP packet is in an ESP packet (even if it is ESP NULL), a
middlebox cannot filter the packet, because the middlebox does not
know if the packet has been encrypted or not.

http://www.ietf.org/mail-archive/web/ipsec/current/thrd5.html is a
link to the first page of the discussion. The discussion is a long
discussion and
http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-visibility-00 is
a document trying to address the same.

>
> 3: User interest in SHA mechanisms for IGP authentication
>>
>> Do you know of anyone other than US DoD that wants this ?
>> (US DoD are the only ones that I can identify, and they are
>> saying their interest is only for "policy reasons".)
>>
>> If so, which users ? which RFPs ?
We have customers who have asked for the crypto algorithms. I do not
think this group is to discuss about particular RFP's.

Again let me state it. If you think there are issues with supporting
SHA algorithm for IGP's, please mention the issues in the WG where the
drafts belongs. Like I have mentioned multiple times, you have been
added as an author of one such document youself.

> 4:  Availability of SHA mechanisms for IGP authentication
>>
>> Further, there are no known shipping implementations of
>> SHA authentication for any IETF-specified IGP.
>> (I don't know of any that are even "in progress".)
>>>
>>> We know of a few including a big router vendor. :))
>
> Which ?  How many ?  When ?
> Are they shipping now or in progress now ?
We are implementing this and so is Cisco (this has been brought to
your notice in private mails earlier but you still bring the issue).
The OSPF WG chair(Acee) knows about the other implementaions of the
draft by vendors. If we have an implementation report we will get more
details then, as I do not have information of all vendors.

It sounds interesting that you want to know vendors implementing some
solutions because we are writing an issues document with already
existing mechanisms.

> 5:  Claims made by existing IGP authentication documents
>>>
>>> However if you see most drafts "security considerations" section,
>>> they state that using cryptographic authentication is a panicia for all
>>> evils.
>
> I can't find even one RFC or I-D that says anything similar
> to "using cryptographic authentication is a panacea for all evils".
>
> I checked a bunch of documents, which I enumerated in an earlier
> email; none contained any such language.
>
> Which specific document does this ?  and on which page ?
Please check the drafts in this page
http://www.ietf.org/html.charters/ospf-charter.html .
As an example see the first draft in the list it states
http://www.ietf.org/internet-drafts/draft-ietf-ospf-lls-05.txt

Security Considerations

   The described technique provides the same level of security as OSPFv2
   protocol by allowing LLS data to be authenticated using the same
   cryptographic authentication that OSPFv2 uses (see Section 2.5 for
   more details).

   OSPFv3 utilizes IPSec for authentication and encryption [OSPFV3AUTH].
   With IPsec, the AH (Authentication Header), ESP (Encapsulating
   Security Payload), or both are applied to the entire OSPFv3 payload
   including the LLS block.

Our aim is to bring forward the issues with the cryptographic
mechanisms. The issues with the cryptographic mechanisms are not
stated in the base RFC either and I have mentioned this to you
clearly. Because most RFC's draft seem to state something similar to
the above.

Thanks,
Vishwas

> Thanks,
> Ran
>
> _______________________________________________
> OPSEC mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/opsec
>
_______________________________________________
OPSEC mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/opsec