Subject: draft-gupta-ospf-ospfv3-auth.00-txt : editorial comments

From: Erblichs <[email-masked]>
Date: Mon, 1 Jul 2002 16:54:25 -0700

Sorry, I did some work with IPv6 years ago...

        Simple items first:

                On my text printed copy:
                        1) There are unusual characters being printed. I believe
                        the first time they show up is in section 3. The first
                        prints as a box before the word "ESP", and the second
                        backward "P" character appears after the word "encryption"
                        of the first line in the second paragraph.

                        This pairing of unusual characters appears numerous times.

                4 Somewhat major comments...

                        1) Does't this document actually refer to IPSec?

                        2) IPSec can be supported on IPv4 and IPv6. IPSec is a must
                           for IPv6. IKE, I believe is only supported in IPv4. Thus,
                           v6-v4 tunnels allow v6 pkts/datagrams to be inserted/encap
                           within v4 packets.

                           I believe your document implies something else.. At least to me..
                           Or are you stating that Nokia only supports IPSec with v6?

                        3) 3. Authentication..
                           I expected something about support of HMAC-MD5 and HMAC-SHA-1.

                        4) 3. Authentication..
                           Tunnels : What is inside the IPSec headers is protected, but
                           but the outer IP header is unprotected..

                Other than this, I have no comments on the contents of this Draft
RFC..

                Mitchell Erblich
                -=================

---

From: Mukesh Gupta <[email-masked]>
Date: Tue, 2 Jul 2002 00:13:31 -0700

Thanks for the comments. Please see my comments inline.

>                         This pairing of unusual characters appears numerous times.

I used the word template and crlf.exe to create this :-( I will try to fix them in the next
update. Thanks for pointing this out..

>                         1) Does't this document actually refer to IPSec?

I am not sure about what exactly do you mean here. If you mean that this document should belong
to IPsec instead of OSPF then here is the explaination. IPsec is a generic way to provide
security to any higher layer IP protocol. As OSPF has specific needs for affording the security
provided by IPsec and the document provides appropriate means/mechanisms to fulfill those
specific security needs, I think, this document should belong to OSPF.

>                            Or are you stating that Nokia only supports IPSec with v6?

Nokia supports IPsec for IPv4 and will be releasing IPsec for IPv6 soon (or it may already be
released). Nokia will also support IKE for IPv6 IPsec. I am not sure how correct you are in
saying that IKE is only supported in IPv4. Kame and FreeSwan also support IPv6 IPsec with IKE.

>                            I expected something about support of HMAC-MD5 and HMAC-SHA-1.

You are right. HMAC-MD5 and HMAC-SHA1 will be used as the authentication algorithms while
calculating the ICV for AH header.

>                            but the outer IP header is unprotected..

I am sorry but I am not clear about what you are trying to say here. Tunnels encapsulate the
entire IP packet inside another IP header. So, the original IP packet is completely protected.

regards
Mukesh

---

From: Erblichs <[email-masked]>
Date: Tue, 2 Jul 2002 10:49:59 -0700

We will try inline comments...

Mitchell Erblich
=====================
=================

> specific security needs, I think, this document should belong to OSPF.

        I agree with this last statement.

> saying that IKE is only supported in IPv4. Kame and FreeSwan also support IPv6 IPsec with IKE.

        I will check out my pre-inclination issues with IKE later.. (have a
short 4th trip)

        No, in my opinion, you give the impression that these items are IPv6
specific
        in this doc.
        Where did you state that what items apply to IPv4 here?
        They are IPSec items and IPSec can also be used with IPv4.. I would
expect at
        least a statement in the intro that your sections also apply to IPv4.
        And thus could also effect OSPFv2..

> entire IP packet inside another IP header. So, the original IP packet is completely protected.
        This is a rough "tunnel mode" description.
        Maybe something clearer would be.

        Tunnel mode is when the datagram is protected by the IPSec headers, but
the outer
        IP header is unprotected... This is normally used in ESP. The outer IP
header will
        normally have different src and dst addresses than the inner IP header.

        Maybe I should also suggest a short description of "transport mode"?

        Just trying to fill in some of my percieved holes within your doc.
However,
        if this was a FS doc and you were discussing sparse files, then holes
would
        be expected. :-)

        Add: ESP is a header, thus I would add the word "header" after "(ESP)"
in your
        1. Introduction.

---

From: Mukesh Gupta <[email-masked]>
Date: Tue, 2 Jul 2002 11:03:27 -0700

>         And thus could also effect OSPFv2..

OSPFv2 (for IPv4) has its own authentication mechanisms inbuilt in OSPFv2 protocol headers. RFC 2740
(OSPFv3 for IPv6) suggests using IPv6 ESP/AH extension headers for providing security to OSPFv3
(just v3 and *not* v2). So you are getting the right impression that we are just talking about IPv6
IPsec here.

Nothing in the draft relates to IPv4 IPsec or OSPFv2. That's why we are not talking about IPv4 IPsec
in the draft.

>         Add: ESP is a header, thus I would add the word "header" after "(ESP)"

If everyone wants I can add more description about tunnel/transport mode and ESP/AH headers but I am
assuming that people have read about them from the specified references and the assumption is
clearly stated in the introduction.

regards
Mukesh

--
******************************************************************
The only gracious way to accept an insult is to ignore it; if you can't ignore it, top it; if you can't top it, laugh at it; if you can't laugh at it, it's probably deserved
******************************************************************
Mukesh Gupta
Phone: (650) 625-2264
Cell : (650) 868-9111
http://www.iprg.nokia.com/~mgupta
******************************************************************