[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: forward progress on IPSec AH

   Date: Tue, 05 May 1998 10:22:32 -0400
   From: Thomas Narten <narten@raleigh.ibm.com>

   > At 01:21 AM 5/5/98 -0400, Theodore Y. Ts'o wrote:
   > >
   > >Comments on the above approach for moving forward?  (Leave the
   > >mutability text alone, and harmonize with the RFC-1883 position which
   > >says that unknown extension headers cause an ICMP code 2 packet.)

   > Ted, I think you have covered it.

   Agreed.

I think we have a workable compromise which everyone is willing to live
with.  I've talked to Karen Seo regarding making these changes, and she
look into updating the draft and fixing these problems.

There were also a set of typographical/editorial changes identified by
Marc Hasson that she will also look at incorporating.  These are mostly
pure editorial changes (i.e., references to section 3.3.2 that really be
section 3.3.3, etc.) or other places where we made a change to one part
of the document, but forgot to make a similar change in another part of
the document, so there was a conflict.  (Changes which require making
any substantive change to the protocol are out of scope at this point;
we will only be making editorial changes.)

Last week we reached a compromise on changing the IANA considerations
text for the DOI text, and the document editor for the DOI should make
those changes and resubmit them as a new I-D.

With these changes, I believe the IPSEC documents should be done and
ready for publication as RFC's, with all issues raised by the IESG
settled.

Thanks to all of those who helped get us to this point.

						- Ted


-----------------------------------------------



Date: Thu, 30 Apr 1998 18:38:27 -0700
From: mark@mentat.com (Marc Hasson)
To: tytso@MIT.EDU, kseo@bbn.com, skent@bbn.com, clynn@bbn.com
Subject: Some minor IPSEC doc comments
X-Sun-Charset: US-ASCII

I fetched the ESP, AH, and architecture documents off of the MIT URL
this morning and have these, mostly minor editorial, comments:

esp-v2-05 (E-mail date at top: Thu, 23 Apr 98 4:44:15)

1)  section 3.4.3 (Sequence Number Verification), 2nd paragraph
    
    The reference to section 3.3.2 looks like it should have been 3.3.3.
    This was OK for the AH document.


2)  Conflict in what a receiver does with padding:
  
    in section 2.4 its says "... the receiver SHOULD inspect the Padding
    field.", presumably to enforce that sequence of integers instead of
    ignore them.  The beginning of this paragraph labels this "... the
    following default processing MUST be used".
    
    However, in section 3.4.5, step 2. we have "The default action is to
    remove/ignore any padding."  This definitely conflicts with the previous.

    I'm sure this is going to lead to more discussions of "tunables" and
    whether receivers should be checking the pad byte values or not....


arch-sec-05 (Email date at top: Thu, 23 Apr 98 4:22:01)

1) Section 4.4.2 (Selectors)

   Destination IP Address (IPv4 or IPv6): 

   How about making it "unicast, multicast, or broadcast (IPv4 only)" since
   IPv6 doesn't have broadcast addresses?


2) Section 4.4.2 (Selectors)

   Source IP Addresses:

   Can a source address really be a broadcast or multicast?  This seems like
   we're having IPSEC condone illegal IP[v6] packet behavior.... Perhaps if
   I saw the note asking for why src/dst should have the same language I'd
   understand this?


3) Appendix B.2 (Fragmentation), very last paragraph

   "Unlike Bump-in-the-stack implementations, security gateways may be able
   to look up the Source Address in the DNS to provide a System Name..."

   I'm not sure why this statement is here.  Having done both an IPSEC stack
   for Mentat as well as having worked on a BITS implementation
   (involving both user and kernel pieces) I don't see any reason why a
   BITS implementation can't do a DNS lookup for its System name just
   as well as a "pure" IPSEC host or SG.  In fact, part of the dynamic
   IP assignment (via DHCP perhaps) and DNS update may already have
   provided a BITS host with what it needs to do a DNS lookup.


Hope these comments help more than annoy.  I don't feel strongly about
any of them, except perhaps the padding one would be nice to make
consistent.  People discuss that too much as it is...

By the way, good work on all the editing.  I know this was a tough job,
its hard enough just to read these.  And I found the CHANGES
particularly useful since I didn't have time to read everything
line-by-line but was able to read everything covered by CHANGES plus
adjacent and related sections for context.

Thanks, things look a lot better to me.

                        
                         
   -- Marc --