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

[Acee Lindem <[e-mail]>]

Hi Mitchell,
See inline.
----- Original Message -----
From: "Erblichs" <[e-mail]>
To: <[e-mail]>
Sent: Tuesday, July 06, 2004 8:12 PM
Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt


> Ace, et al,
>
>         I realize that this is a late comment..
>
>         Section 3. Authentication
>
>                 But this really applies throughout
>                 this doc.
>
>       "OSPF packets recieved ... MUST be dropped ..."
>
>         Their is no mention that I have seen that identifies
>         an appropriate MISMATCH message that allows the
>         recv'r administrator to correct this or other bad
>         configurations.

I don't think we should try and standardise logging and/or
log throttling mechanisms. The OSPFv2 MIB does define an
ospfIfAuthFailure trap and I would imagine that when traps
are added to the OSPFv3 MIB, this one would be included.
It might be ok to say add a general statement saying that there
should be some type of local auth failure notification and that
it would be a good idea to throttle them.

>         Also, can a OSPF router sychronize
>         or update its database with another router if a
>         percentage of its packets are dropped?

It depends on the percentage.

>
>         I keep on thinking that dropped msgs of this type
>         need to be tracked and as much information should
>         be logged about the xmit'er of the MISMATCHED pkt.
>
>         What happens if some OSPF packets are dropped from
>         a router and others are accepted?

It depends on which packets :^)

>
>         Thus, I would think and this is a bit extreme, if
>         a OSPF packet is recieved that has a mismatch in
>         any encryption or authentication field(s) from the
>         xmit router, the adjacency or its 2-way link status
>         should be dropped. The router can not be a trusted
>         router if some of its packets are untrusted and/or
>         its contents are unknown. Can it?
>         Yes, this is assuming that the router-id is known.

I disagree. Authentication should be done on a packet by packet
basis without OSPF trying to maintain any state other than what is
maintained by IPSEC itself.


>
>         Mitchell Erblich
>         -----------------
>
>
>
> Acee Lindem wrote:
> >
> > Even though this has gone through WG last call it may
> > be a good to schedule some time at the San Deigo IETF
> > to discuss recent issues and how they are addressed
> > in the new draft. Comments?
> >
> > ----- Original Message -----
> > From: <[e-mail]>
> > To: <[e-mail]>
> > Sent: Monday, July 05, 2004 3:19 PM
> > Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt
> >
> > Hi Vishwas,
> >
> > Thanks for the comments.  Please see my comments inline..
> >
> > > 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.
> >
> > > 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.
> >
> > > 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 ?
> >
> > > 4. I think we may want to state that Authentication service must
> > > always be supported whenever we do encryption. Our primary aim is
> > > to have data integrity right(anyway encryption only service is a
> > > MAY for ESP)?
> >
> > Doesn't the sentence "Providing confidentiality to OSPFv3 in addition
> > to authentication is optional." imply that ?  Or would it better to
> > replace
> >
> > "ESP with non-null encryption in transport mode MUST be used
> > for providing the confidentiality to OSPFv3."
> >
> > with
> >
> > "ESP with non-null encryption and non-null authentication in transport
> > mode MUST be used for providing the confidentiality to OSPFv3."
> >
> > > 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 ?
> >
> > > 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.
> >
> > > 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 ?
> >
> > > 8. Would we want to refer to the newer drafts for ESP/AH drafts rather
> > > then the old RFC's itself?
> >
> > 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 ?
> >
> > The draft was reviewed by the IESG on June 26th and the comments can
> > be seen at https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=9745&rfc_flag=0
> > We will be working on addressing all the comments now and will publish
> > an updated version of the draft probably after the IETF 60th.
> >
> > regards
> > Mukesh