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

From: [email-masked]
Date: Mon, 5 Jul 2004 14:19:25 -0500

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

---

From: Abhay Roy <[email-masked]>
Date: Mon, 5 Jul 2004 22:34:08 -0700

> we have to depend upon the IP version to separate OSPF and

Just FYI, we can run OSPFv3 using IPv4 transport (see section 9 of
draft-mirtorabi-ospfv3-af-alt-01.txt). In which case the demux
will be based on OSPF protocol version.

Regards,
-Roy-

---

From: Acee Lindem <[email-masked]>
Date: Tue, 6 Jul 2004 10:49:33 -0400

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: <[email-masked]>
To: <[email-masked]>
Sent: Monday, July 05, 2004 3:19 PM
Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt

Hi Vishwas,

with

regards
Mukesh

---

From: Erblichs <[email-masked]>
Date: Tue, 6 Jul 2004 17:12:59 -0700

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. Also, can a OSPF router sychronize
        or update its database with another router if a
        percentage of its packets are dropped?

        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?

        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.

        Mitchell Erblich
        -----------------

---

From: Acee Lindem <[email-masked]>
Date: Tue, 6 Jul 2004 22:50:25 -0400

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

>         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

It depends on the percentage.

>         a router and others are accepted?

It depends on which packets :^)

>         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.