Re: draft-ietf-ospf-ospfv3-auth-04.txt

[Vishwas Manral <[e-mail]>]

Hi Suresh,

I think I missed replying to this one.

Yes, if anti-replay is not enabled the sequence number wrap does not matter at all. From the ESP document: -

   If anti-replay is disabled (as noted above), the sender does not need
   to monitor or reset the counter, e.g., in the case of manual key
   management (see Section 5).  However, the sender still increments the
   counter and when it reaches the maximum value, the counter rolls over
   back to zero. (This behavior is recommended for multi-sender,
   multicast SAs, unless anti-replay mechanisms outside the scope of
   this standard are negotiated between the sender and receiver.)

Thanks,
Vishwas

-----Original Message-----
From: Mailing List [mailto:[e-mail]]On Behalf Of Suresh
Melam
Sent: Friday, July 09, 2004 11:18 PM
To: [e-mail]
Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt


Please see my comments inline,

thanks,
-suresh (Nagavenkata Suresh Melam)

>
>-----Original Message-----
>From: Mailing List [mailto:[e-mail]]On Behalf Of ext
>Vishwas Manral
>Sent: Monday, July 05, 2004 9:38 PM
>To: [e-mail]
>Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt
>
>
>Hi Mukesh,
>
>Just wanted to add from ESP
>
>"If anti-replay is enabled (the default), the transmitted Sequence Number must never be
>allowed to cycle." I think there is no consistent way a sender or receiver would work after
>rollover. The receiver could very well break the SA on rollover(I think).
>

As manual keying doesn't use anti-replay mechanisms, the Sequence numbers need not be considered in our discussion.

>Thanks,
>Vishwas
>-----Original Message-----
>From: Mailing List [mailto:[e-mail]]On Behalf Of
>Vishwas Manral
>Sent: Tuesday, July 06, 2004 10:03 AM
>To: [e-mail]
>Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt
>
>
>Hi Mukesh,
>
>>>1. I am not sure we should have a statement which says OSPFv3
>>>is only for IPv6.
>>>"As OSPFv2 is only for IPv4 and OSPFv3 is only for IPv6,
>>> the distinction between the packets can be easily made by
>>> IP version. "
>>Do you have a replacement statement that you would prefer ?
>>As the IP protocol type value for OSPF and OSPFv3 is same,
>>we have to depend upon the IP version to separate OSPF and
>>OSPFv3 packets.
>There is a distinction between running over and "only for"(which
>I assumed you meant the contents). It seems you mean running over.

Yes, our intention was to mention "running over". We will change
the sentence as follows.

"The distinction between the OSPFv2 and OSPFv3 is made based on the
IP version. If OSPFv3 runs on IPv4 protocol on a link for any reason,
then IPsec security cannot be enabled on this link."

>>>2. I think the value of next header field in the ESP header
>>>to indicate OSPFv3 should be specified, though it may seem
>>>a trivial question.
>>Why do you think it should be specified?  Whenever ESP is
>>applied to any IP packet, the IP Protocol Type field value
>>from the IP header is copied to the next header field of
>>ESP/AH.  There are no exceptions here.
>The whole draft is full of informational statements like: -
>
>   "AH in transport mode provides authentication to
>   higher layer protocols, selected portions of IPv6 header, selected
>   portions of extension headers and selected options.  ESP with NULL
>   encryption in transport mode will provide authentication to only
>   higher layer protocol data and not to the IPv6 header, extension
>   headers and options."
>
>I think putting what the value in the next header would be would be
>helpful.

We will add another informational statement as follows.

"IPsec copies the OSPF protocol value from the IPPROTO field of the
IP packet to the next header field of the ESP/AH header."


>>>3. ESP already states that "integrity-only (MUST be supported)"
>>>do we really need to put down "ESP with NULL encryption MUST be
>>>supported in transport mode".
>>>An implementation may support ESP/AH that conform to ESP/AH RFCs,
>>but the idea of putting this in this draft was to ensure that the
>>user is allowed to use the specified combinations for securing
>>the OSPF traffic.  So that 2 independent secured OSPF
>>implementations have at least one common combination to configure.
>>Do you see any harm in putting this text in the draft ?
>Not at all, but I am unable to see the point of
>"ESP with NULL encryption MUST be supported in transport mode". The
>point is we are saying a restriction on ESP MUST be there, where ESP
>already has said its a MUST in the protocol itself. I think we may
>also want to state other things then, like using ESN(if its supported),
>default authentication/encryption algorithm etc when using manual keying.

Our intention was to mention that

"Inorder to support OSPFv3 authentication, the underlying IPsec
implementation MUST support ESP with NULL encryption in transport mode."

The reason is that we strongly suggest the usage of "ESP with NULL encryption
in transport mode" for OSPFv3 authentication. We don't have any explicit
suggestions for algorithms. But atleast now we should add another line.

"While choosing algorithms for authentication/encryption, one should be
careful to choose the algorithms that are suitable for manual keying. For eg.,
some stream cipher algorithms like AES-CCM are not suitable for manual keys"


>>5. OSPF packets received in clear text or with incorrect AH
>>>Integrity Check Value (ICV) MUST be dropped when authentication is
>>>enabled.
>>> Do we mean only AH/ICV or do we need ESP ICV too? Besides do we
>>>need to state about combined mode algorithms like AES-CCM where
>>>ICV may not checked even when authentication is done.
>>It should be AH/ESP ICV.  I will replace "AH" with "AH/ESP" in the
>>next version.
>>The draft for AES-CCM says "it is inappropriate to use this CCM
>>with statically configured keys".  We are using staticaly configured
>>keys here.  So should we just NOT use AES-CCM ?
>AES-CCM is an example of a combined mode algorithm, there are other
>and can be further combined mode algorithms. We shouldn't put any
>restriction that is based on the algorithm we use.
>
>From ESP "For combined mode algorithms, the ICV that would normally
>appear at the end of the ESP packet (when integrity is selected) may
>be omitted. "

For the ICV term, we will add "if applicable".

"OSPF packets received in clear text or with incorrect AH
Integrity Check Value (ICV), if applicable,  MUST be dropped
when authentication is enabled."


>>>6. SA Granularity and Selectors section - I think you are referring
>>to parallel links we may want to state that too.
>>No I am not referring to parallel links (if you mean 2 links connecting
>>the same routers).  It should be possible to use the same SA for multiple
>>interfaces belonging to even different areas.
>May be text clarifying what you mean should be put. Also text to state
>whether in case of parallel links we need to have one SA or not can be
>clarified.

We will add another line:

"User can choose to use same SA or different for parallel links."

>>>7. Changing Keys may also be required in case of sequence number rollover.
>>How is the user going to know about the sequence number rollover ?
>>so that he/she can initiate the key change.  That brings an interesting
>>question.  If the user never changes the keys, what happens when the
>>sequence number rollovers ?
>There are a lot of ways to provide that, a simple way could be to poll at some
>interval, and when we are near rollover we change the keys.
>
>From ESP
>"Thus, the sender's counter and the receiver's counter MUST
> be reset (by establishing a new SA and thus a new key) prior to the
> transmission of the 2^32nd packet on an SA."
>
>This is in case of normal SN, when we use ESN that will change, I think.

In manual keying, sequence numbers are disabled. Hence there is no need for
this discussion in the draft.


>>That's a good idea but the problem is that if we put the new drafts
>>as normative references, this draft will not be published before those
>>drafts.  Do we want to block the draft waiting for those drafts ?
>
>I think that is the authors wish.

We will stick with the old RFCs.


>>We will be working on addressing all the comments now and will publish
>>an updated version of the draft probably after the IETF 60th.
>That would be great.
>
>Thanks,
>Vishwas