Fwd: Re: IPsec ESP-bis -- Last Call revisions

[Karen Seo <kseo@bbn.com>]

Title: Fwd: Re: IPsec ESP-bis -- Last Call revisions

> X-Sender: kseo@po2.bbn.com
> Date: Wed, 16 Jul 2003 11:20:44 -0400
> To: "Angelos D. Keromytis"
> <angelos@cs.columbia.edu>
> From: Karen Seo <kseo@bbn.com>
> Subject: Re: IPsec ESP-bis -- Last Call revisions
> Cc: Barbara Fraser <byfraser@cisco.com>, tytso@mit.edu,
> skent@bbn.com,
>    clynn@bbn.com, kseo@bbn.com
> X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com /
> mimedefang)
> Status:  
> Angelos,
>
> Russ Housley just approved items 13, 14
> (see below)
>
> Should I submit the draft to the
> IETF?
>
> Karen
>
>
> ===============================================================================
>

Commenter:      Russ Housley

Date:           6/16/03 and 7/15/03

Status:         approved by Russ on 7/16

> > 13. I am confused by "DISCUSSION"
> > in section 3.4.4.1.
>

        We asked for clarification on 7/4/03 and received the feedback

        below:

> > It says:
> >
> >                DISCUSSION:
> >
> >                Begin by removing and saving the ICV field.
> > Next check the
> >                overall length of the ESP packet minus the
> > ICV field. If
> >                implicit padding is required, based on the
> > blocksize of the
> >                integrity algorithm, append zero-filled
> > bytes to the end of
> >                the ESP packet directly after the Next
> > Header
> >                field. Perform the ICV computation and
> > compare the result
> >                with the saved value, using the comparison
> > rules defined by
> >                the algorithm specification.
> >
> > My issue is that there is no context provided.
> > I think this would be better structured as an Implementation Note. 
> > Like:
> >
> >         Implementation Note: 
> > Implementations can use any set of steps
> >         that results in the same
> > result as the following set of steps.  Begin
> >        
> > by ...
>
>    Changed to:
>

        Implementation Note:

    Implementations can use any set of steps that results in the
    same result as the following set of steps.  Begin by removing
   and saving the ICV field. Next check the overall length of the
  ESP packet minus the ICV field. If implicit padding is
        required, based on the blocksize of the integrity algorithm,
      append zero-filled bytes to the end of the ESP packet directly
  after the Next Header field. Perform the ICV computation and
    compare the result with the saved value, using the comparison
   rules defined by the algorithm specification.

>
> ===============================================================================
>

Commenter:      Russ Housley

Date:           6/17/03

Status:         approved by Russ on 7/16

> > 14.  The references need to be
> > divided in to normative and informative.
>

        We changed the References to:

>
>   
> References
>
>   
> Normative

        [Bra97] Bradner, S., "Key words for use in RFCs to

        Indicate Requirement Level", BCP 14, RFC 2119, March

        1997.

>

        [KA98] Kent, S., and R. Atkinson, "Security

        Architecture for the Internet Protocol", RFC 2401,

        November 1998.

>     Informative

        [Bel96] Steven M. Bellovin, "Problem Areas for the IP

        Security Protocols", Proceedings of the Sixth Usenix

        Unix Security Symposium, July, 1996.

        [HC03]  Holbrook, H., and Cain, B., "Source Specific

        Multicast for IP", Internet Draft,

        draft-ietf-ssm-arch-01.txt, November 3, 2002.

>

        [HC98] Harkins, D., and D. Carrel, "The Internet Key

        Exchange (IKE)", RFC 2409, November 1998.

        [Ken03] Kent, S., "IP Authentication Header", RFC ???,

        ??? 2003.

>

        [Kra01] Krawczyk, H., "The Order of Encryption and

        Authentication for Protecting Communications (Or: How

        Secure Is SSL?)", CRYPTO' 2001.

> ===============================================================================