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

Acee Lindem <acee@REDBACK.COM> Wed, 07 July 2004 02:51 UTC

Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15388 for <ospf-archive@LISTS.IETF.ORG>; Tue, 6 Jul 2004 22:51:55 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00E08D30@cherry.ease.lsoft.com>; Tue, 6 Jul 2004 22:51:55 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 24788004 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 6 Jul 2004 22:51:54 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 6 Jul 2004 22:51:54 -0400
Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 8E63172997E for <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 6 Jul 2004 19:50:37 -0700 (PDT)
Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23745-09 for <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 6 Jul 2004 19:50:37 -0700 (PDT)
Received: from aceeinspiron (unknown [172.31.253.23]) by prattle.redback.com (Postfix) with SMTP id 2A66672998A for <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 6 Jul 2004 19:50:36 -0700 (PDT)
References: <8D260779A766FB4A9C1739A476F84FA401F79A87@daebe009.americas.nokia.com> <014b01c46368$743bc800$0202a8c0@aceeinspiron> <40EB400B.69801942@earthlink.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Virus-Scanned: by amavisd-new at redback.com
Message-ID: <03e501c463cd$27b22b90$0202a8c0@aceeinspiron>
Date: Tue, 6 Jul 2004 22:50:25 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Hi Mitchell,
See inline.
----- Original Message -----
From: "Erblichs" <erblichs@EARTHLINK.NET>;
To: <OSPF@PEACH.EASE.LSOFT.COM>;
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: <Mukesh.Gupta@NOKIA.COM>;
> > To: <OSPF@PEACH.EASE.LSOFT.COM>;
> > 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