Subject: WG Last Call on draft-ietf-ospf-ospfv3-auth-06.txt

From: Acee Lindem <[email-masked]>
Date: Sun, 2 Jan 2005 22:56:51 -0500

This the start of  the  Working Group Last Call for
draft-ietf-ospf-ospfv3-auth-06.txt - Authentication/Confidentiality
for OSPFv3. All comments must be sent to the OSPF list by 
12:00 AM EST on Wednesday, January 19th, 2005.

A URL for this Internet-draft is provided below:

http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-06.txt

Thanks,
Acee & Rohit

---

From: Suresh Melam <[email-masked]>
Date: Thu, 6 Jan 2005 18:33:24 -0800

Hi Vishwas, 

Comments inline, 

regards,
- suresh

> We wanted to keep the section general without making it 
> specific to ESP or AH.  So when we say "Null encryption with 
> MD5 authentication", it could be used either with ESP or 
> with AH.  Do we need to add more text to make it clearer? 
> Do you any have specific changes in mind ? 
VM> I do not agree when you say NULL encryption it can refer to AH, I
think it means only ESP. NULL Encryption can be treated equivalent to
any other encryption algorithm atleast that is what I know of. 

suresh> AH & ESP differ in the protection provided to different fields
of the packet.  In this section of the draft, we were interested in
comparing the difficulty of breaking the keys, but not really in the
attacks once the keying material is compromised. 
Do you see any difference in terms of difficulty in breaking the keys
for "NULL encryption with MD5 auth with ESP" and "MD5 authentication
with AH"? 

> Well, the draft does not recommend using DES either. We just 
> wanted to compare some non-null encryption schemes with null 
> encryption schemes and we chose des, 3des and AES.  The draft 
> mandates the usage of AES so it is inline with the other 
> IPsec drafts. 
VM> I do not think we should use examples of schemes, which have been 
mentioned as "SHOULD NOT" by the IETF/NIST. 

Suresh> We are not a fan of DES either for obvious reasons.  But as we
wanted to start with the weakest algorithm, we started with DES.  We
wouldn't have to mention DES at all, had IETF/NIST 
suggested DES as "MUST NOT".

> All the IPsec implementations that support AES for IPsec 
> MUST support 128 bit key size (RFC 3602).  So are we not 
> ok without mentioning the key sizes in this draft and just 
> referring to 3602? 
VM> Mukesh I am comming more from the point of view of 
draft-ietf-ipsec-esp-ah-algorithms-02.txt, which also seems 
to specify the key size. IT is the document for ESP/AH 
specifying mandatory protocols. 
>
> We had taken this approach in previous revs (04, I guess) 
> but Security ADs (Russ) wanted to have at least one algorithm 
> required by this draft just to make sure that the 
> implementations were interoperable.  We added AES/SHA1 
> as mandatory as suggested by Russ. 
VM> I guess I should have been clearer. I agree and infact had asked for
the same thing in my previous review. I am asking is that we have
another companion draft specifying the mandatory algorithms as is done
for IPSec/IKE etc. It helps becuase as and when we move forward and
algorithms change we just need to change that document rather then the
whole IPSec for OSPF document. 

Suresh> IMHO, a companion draft for just this will be an overkill.
Mukesh and I discussed this again and we agree that referring to
the IPsec algorithm draft should be the better way to go.  We also
looked at the 04 version and realized that the related text was not
clear in that version.  We will discuss this with Russ again and see if
we can come up with some text to satisfy us all :)

> "There are no known threats of replaying these type of packets."
> with 
> "There are no known threats of replaying these type of packets 
> except that the receiving router will have to spend some resources 
> to handle these packets." 
VM> I agree, however I think one more point we miss is that, when 
adjacencies are not full the link is not used for transit data traffic.
In the sense its a clear DoS attack where we can make the link unusable.
I have already told the OSPF Vulnerabilities draft authors about the
same. This also causes transient loops because of changing topologies. 

Suresh>
What about the following:
"Replaying these type of packets can make the router spend some
resources.  Also when the OSPF adjacency is not FULL, replaying 
database description packets can cause disruption in forming the
adjacency."

> Sorry ! I do not understand which default/supported values 
> you are talking about here :(  Could you please be a little 
> more specific? 
VM> As you stated that Russ specified(and I totally agree) some minimal
options for implementations to interoperate is necessary(and I think the
primary aim of this draft). We should specify if we are using options
Extended Sequence Numbers(ESN) or not at the minimum etc. The reason is
the same for DSCP, check the recent discussion on 
http://www1.ietf.org/mail-archive/web/ipsec/current/index.html I had
with Steve Kent and the changes being made to the IPSec security
architecture document because of that. 

Suresh>  We are using manual keys here so the sequence numbers will be
ignored.  So do we really need to worry about ESN ?

VM> Mukesh, I also noted that recommendation of changes for the MIB is
not made in the draft Would there be any changes to the MIB? 

Suresh>  Is it customary to add a "MIB recommendations" section? In any
case, we should work closely with the MIB draft authors to update the
MIB entries to include the security details.