Subject: some concerns about last IKEv2 draft

From: Francis Dupont <[email-masked]>
Date: Wed, 10 Sep 2003 18:30:19 +0200

I have some concerns about the draft-ietf-ipsec-ikev2-10.txt document:

 - In section 2.23 NAT Traversal:

      There are cases where a NAT box decides to remove mappings that
      are still alive (for example, the keepalive interval is too long,
      or the NAT box is rebooted). To recover in these cases, hosts that
      are not behind a NAT SHOULD send all packets (including retried
      packets) to the IP address and port from the last valid
      authenticated packet from the other end. A host not behind a NAT
      SHOULD NOT do this because it opens a DoS attack possibility. Any
      authenticated IKE packet or any authenticated IKE encapsulated ESP
      packet can be used to detect that the IP address or the port has
      changed.

 => the SHOULD and the SHOULD NOT apply to the same case (host no behind
    a NAT). Obviously there is a typo, IMHO the right version is:
    "A host behind a NAT SHOULD NOT do this ...".
    BTW the "any authenticated IKE encapsulated ESP" wording is poor and
    should be removed, or replaced by something which takes into account
    the whole IPsec traffic (both for the detection of the address change
    and for the update of the endpoint behind NAT address).

 - just after this paragraph, there is:

      Note that similar but probably not identical actions will likely
      be needed to make IKE work with Mobile IP, but such processing is
      not addressed by this document.

 => the Mobile IP case can be symmetrical so an identical action can't
    work in all cases because it would open the door to the DoS attack.

 - in 3.6 Certificate Payload:

      Hash and URL of PKIX bundle (13) contains a 20 octet SHA-1 hash of
      a PKIX certificate bundle followed by a variable length URL the
      resolves to the BER encoded certificate bundle itself. The bundle
      is a BER encoded SEQUENCE of certificates and CRLs.

 => this is an underspecified ASN.1 type: some tagging is needed,
    for instance by adding:
    ", respectively with implicit tags 0 and 1".

 - there is nothing about the protection of peer addresses, so IKEv2 can
   be used to launch DoS attacks... I still believe the easiest fix is
   to make the peer addresses explicit parameters of the IKE SA.

[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 10 Sep 2003 23:09:48 +0300

>     "A host behind a NAT SHOULD NOT do this ...".

Yep, that seems to be typo. 

>     and for the update of the endpoint behind NAT address).

I think there was also typo, it should say:

"any authenticated UDP encapsulated ESP packet"

Note, that we do not need to care about AH, as they cannot be
encapsulated in the UDP (the current NAT-T does not have support for
AH). 

>     work in all cases because it would open the door to the DoS attack.

I think the current wording is ok, i.e it says we do not handle those
cases here. I do not understand what your actual concern is in that
paragraph?

>    to make the peer addresses explicit parameters of the IKE SA.

As described above the other mobility, multihoming, sctp, roaming etc
issues are left out from this document, and there will be another
document (from different wg) to take care of those later.

There is NO easy way we can make IKEv2 so that there is no possibility
to do launch DoS attacks. The attacker can always cause the other end
to send cookie request to the faked address, i.e causing a DoS. Only
way to protect against that would require the responder to somehow
authenticate the first packet sent by the initiator without sending
anything back, and that would propably need costly public key
operation, causing easy DoS against the responder.

In the current version attacker can cause packets to diver to
different address by modifying the packets on the fly, but only one by
one basis (i.e each packet needs to be diverted separately). If the
other end is behind NAT, then the host behind NAT can be diverted to
send packets to wrong host (DoS attack), but the situation will be
fixed immediately when the attacker stops modifying packets and first
packet from the real host behind NAT comes to the host behind NAT.

There is no way to protect against that without co-operating with the
NAT box, if we want to allow NAT boxes to be rebooted etc. That part
of the document is only SHOULD so if implementor can leave it out if
he does not care about the problem. I.e for example is willing to pay
the cost of couple of minutes of the packets dissappearing and
reauthentication after NAT changes the IP address. The problem with
reauthentication is that it might require new password/secur-id etc to
be requested from the user.
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: "Theodore Ts'o" <[email-masked]>
Date: Wed, 10 Sep 2003 16:51:20 -0400

>     and for the update of the endpoint behind NAT address).

Hmm.... good catch.  Thanks for pointing this out.

>     work in all cases because it would open the door to the DoS attack.

Given that the paragraph does say "probably not identical", do we need
to make any changes to this text?  I do not believe this to be the
case.

>     ", respectively with implicit tags 0 and 1".

While type-specific tagging might make life easier for the parser, it
is not strictly necessary since it is possible to distinguish between
certificates and CRL's by the ebedded ASN.1 type information.

>    to make the peer addresses explicit parameters of the IKE SA.

This is not a new issue, and the working group has decided that it is
not worth worrying about this particular attack.  I will note that the
attack requires that the attacker be on the network path between the
two communicating peers, and that an attacker in this position has the
ability to carry out a multitude of attacks that disrupt the
communication between the two peers, and indeed there are plenty of
denial of service attacks that do not require being on the network
path.

						- Ted

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 10 Sep 2003 13:54:49 -0700

>     ", respectively with implicit tags 0 and 1".

To be fair to the draft, it didn't claim that this is an ASN.1 type, it
just specifies the use of BER.

That said, there are at least to problems here: a) the first sentence of
the paragraph you quote is grammatically incorrect and b) it should use
DER or CER instead of BER (since there's multiple ways to encode an ASN.1
SEQUENCE in BER, but one should generally use a definite encoding to
encode inputs to hash functions).

Further, it would be preferable to give the ASN.1 syntax for this
SEQUENCE, which means getting the tagging right, as you point out.

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 10 Sep 2003 15:25:36 -0700

On Wed, Sep 10, 2003 at 06:15:21PM -0400, Theodore Ts'o wrote:
> The grammatical typo can easily be fixed, either now or during last
> call.
> 
> While you are right that the use of DER or CER is preferred for data
> structures which are digitally signed, as it simplifies certain
> implementations that may decide to decode and then re-encode a
> particular ASN.1 stream, it certainly isn't required.  In this
> particular case, I very much doubt it will cause any real problems to
> an implementation, since the simplest and easiest implementation
> strategy will be to verify the hash immediately after downloading the
> certificate bundle specified by the URL, and before separating it into
> its component certificates and CRL's.  
> 
> Note that certificates and CRL's are themselves self-verifying data,
> so the hash is really more of a sanity check to make sure the correct
> bundle was downloaded as opposed to being seriously needed for the
> security of the protocol.

Good.  I hadn't read the relevant text in the I-D to verify that a
definite encoding was not an issue.

> As I said earlier, no tagging is really needed.  Explicit tags are
> optional in ASN.1, unless they are needed to create a non-ambiguous
> encoding.  However, with either DER or BER, the types of the
> underlying definition of Certificate and CRL are not ambiguous, which
> means that this is perfectly legal ASN.1:
> 
> 	SEQUENCE OF CHOICE { X509-CERTIFICATE, X509-CRL };

Agreed.

Nico
--

---

From: "Theodore Ts'o" <[email-masked]>
Date: Wed, 10 Sep 2003 18:15:21 -0400

Perhaps some ASN.1 geeks would feel that this is clearer than the
current English that is there now, but personally, I'm not at all
convinced.

							- Ted

P.S.  This confusion over the use of ASN.1 simply reinforces my
personal bias that "friends shouldn't let friends use ASN.1", but it's
far too late in the process to be making changes that basically boil
down to arguments over preferred ("bits on the wire") packet formats.

---

From: Francis Dupont <[email-masked]>
Date: Thu, 11 Sep 2003 14:59:58 +0200

In your previous mail you wrote:

   
=> we agree.

   
   
=> this is fine but doesn't take into account that these packets too
should be sent to the IP address and port from the last valid...
I.e., the "implicit peer address mechanism" for the peer behind a NAT
should be applied to all the UDP 4500 IKE and ESP packets, not only
to IKE packets. This is both more resilient (as explain at the beginning
of the mentioned paragraph) but also more secure (a pseudo-NAT attacker
has to stay on the path). BTW IMHO it is easier to implement too (only
one state of the UDP 4500 stuff per peer).

=> I agree: only ESP in tunnel mode support is really useful here.

   
=> in fact I don't propose to change the current text: it is not really
wrong, it is only clearly a bit too optimitist: this is more a remark
than a real concern.

   
=> the issue about the (lack of) protection of peer addresses is not
part of mobility, multihoming, sctp, etc, issues: these issues just
stress it.

=> my purpose is not to make IKEv2 100% DoS attack resilient but
to fix to recognized way to use IKEv2 to launch DoS attack.
And if it is easy I can't explain why it is not done.

   In the current version attacker can cause packets to diver to
   different address by modifying the packets on the fly, but only one by
   one basis (i.e each packet needs to be diverted separately).

=> unfortunately this is true only for IKE itself, not for the IPsec
traffic managed with IKE.

   If the
   
=> I agree: in the NAT traversal case, the explicit peer address
update mechanism is a good defense (so it should be completely
specified, and its support encouraged (SHOULD). Cf, the beginning
of messages).

=> my purpose is to fix the issue in the case there is no NAT or for
the peer which is not behind a NAT. Today an attacker who modifies
only one IKE message in a CREATE_CHILD_SA can divert the IPsec
traffic of the new SA. And my proposed fix is very simple: I'd like
to verify that the peer addresses are IKE SA parameters. As there are
many defenses against an en-route modification of them in the initial
exchanges (NAT detection, cookie, check against ID or CERT, etc), it
is enough to use the IKE SA peer addresses for new IPsec SA endpoint
addresses than the addresses in the last message. And IMHO a SHOULD
is enough, it makes people who take the issue as serious (like mobility
people, please read RFC 3519 Security Considerations) happy, and people
who like unbound but justified use of "address agility" too.

Thanks

PS: so what I'd like is a clarification in 2.11 Address and Port Agility, in:
   IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and
   AH associations for the same IP addresses it runs over.

This is no a real definition of what are the IP addresses IKE runs over,
i.e., if different addresses are used which one should be used: this
opens an implementation issue and a flexibility/security trade-off,
solved only in the NAT traversal case for the peer behind a NAT.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 11 Sep 2003 16:15:34 +0300

> one state of the UDP 4500 stuff per peer).

I think the current draft does say that. It says that host not behind
NAT SHOULD send all packets to the last valid authenticated source
address seen from the peer. And then it says that both IKE packets and
UDP encapsulated ESP packets can be used to get that last
authenticated source address. 

> traffic managed with IKE.

IPsec traffic does not change addresses at all unless there is NAT
between. The current draft explictly says that the IPsec SA is created
implictly between the ip address used for the IKE SA. I.e unless there
is NAT-T the ESP packets will always same source and destination IP
pair that what was used when they were negotiated.

There will be new wg/document describing how to change the address of
the already exising SAs later, but in the current document it is
simply said that it cannot be done yet.
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Francis Dupont <[email-masked]>
Date: Thu, 11 Sep 2003 15:08:28 +0200

=> hum, BER and SEQUENCE are ASN.1 words... Do you argue the document
should specify ASN.1?

   That said, there are at least to problems here: a) the first sentence of
   the paragraph you quote is grammatically incorrect

=> a) not my fault, b) please propose a better one.

   and b) it should use
   
=> no, I believed the same thing but DER is not needed at all.
Of course, as DER is a subset of BER, IMHO we'll always get DER...

=> IMHO we should reduce the ASN.1 specifications in the document to
the minimum. My concern is we are (were!) below this minimum.

Thanks

---

From: Francis Dupont <[email-masked]>
Date: Thu, 11 Sep 2003 15:21:23 +0200

=> I disagree: certificates and CRLs are SEQUENCEs so tagging is mandatory
(cf ITU-T REC X.680 200207 aka ISO/IEC IS 8824-1 2003, 28.3:
"The Types defined in the "AlternativeTypeList" productions in an
 "AlternativeTypeLists" shall have distinct tags")

   This is not a new issue, and the working group has decided that it is
   not worth worrying about this particular attack.

=> s/has decided/has not shown enough interest/?
And the question is not "has the IETF decided that it is not worth
worrying about this particular attack?" It seems an IETF last call
will be done one day about the IKEv2 document, doesn't it?

   I will note that the
   
=> yes, this is not a drastic issue. But this means that IKEv1 should not
be backpatched, not that IKEv2 should be deployed with this flaw.
I am still surprised by the different handling of the same issue by
the mobility (cf. RFC 3519) and IPsec guys...

Thanks

---

From: Francis Dupont <[email-masked]>
Date: Thu, 11 Sep 2003 15:51:48 +0200

I think the current draft does say that.

=> I don't think so, or at least it is unclear.

   It says that host not behind
   
=> we agree about what to do. The text says:

       authenticated packet from the other end.

The context suggests IKE packets, so we should agree about a clarification,
for instance by adding ESP packets to the "(including retried".

   IPsec traffic does not change addresses at all unless there is NAT
   between. The current draft explictly says that the IPsec SA is created
   implictly between the ip address used for the IKE SA.

=> no, this is not explicit. My proposal is to make this clearly explicit,
and it seems you agree with me.

   I.e unless there
   
=> this "when they were negotiated" has to be clarified. And I prefer
(for security reasons, with a SHOULD) to use the IKE SA addresses
than the addresses in the CREATE_CHILD_SA message (in this context,
i.e., no NAT-T or not for the peer behind a NAT).

=> agree.

Thanks

---

From: Francis Dupont <[email-masked]>
Date: Thu, 11 Sep 2003 15:35:58 +0200

=> please help the poor (:-) editor: propose a new wording asap!

   
=> I agree: DER will be common but we have not to mandate it.

   > SEQUENCE, which means getting the tagging right, as you point out.
   
   As I said earlier, no tagging is really needed.

=> tagging IS needed.

   Explicit tags are
   encoding.

=> tags (of any kind) are needed when the encoding is ambiguous,
and it is the case here (a CHOICE between two SEQUENCEs).

   However, with either DER or BER, the types of the
   underlying definition of Certificate and CRL are not ambiguous,

=> there are not ambiguous but they are the SAME.

   which means that this is perfectly legal ASN.1:

=> this is legal ASN.1 only when automatic tagging is selected.
As it is not the case (automatic tagging is not the default),
some kind of tagging (explicit, implicit or automatic) is needed.

=> I can send to you *privately* the last ASN.1 documents (my telecom
engineer school is a member of the ITU, I even have a minitel on my
desk :-). But the current document is just a bit underspecified
and we have to fix it. My proposal is designed to be as small as
possible: ", respectively with implicit tags 0 and 1".
   
   P.S.  This confusion over the use of ASN.1 simply reinforces my
   personal bias that "friends shouldn't let friends use ASN.1",

=> so you should share my idea to introduce as little as possible ASN.1 (:-)!
For instance I implicitly translate the English word "and" into the ASN.1
CHOICE.

   but it's

Thanks

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 11 Sep 2003 17:43:54 +0300

> => I don't think so, or at least it is unclear.

I still do not think this is unclear. 

> for instance by adding ESP packets to the "(including retried".

Note, that after that, at the end of paragraph it describes what it
means by the "authenticated packet":

----------------------------------------------------------------------
      Any authenticated IKE packet or any authenticated UDP
      encapsulated ESP packet can be used to detect that the IP
      address or the port has changed.
----------------------------------------------------------------------

(I fixed the "IKE encapsulated ESP packet" to the correct "UDP
encapsulated ESP packet"). 

> and it seems you agree with me.

I think this is quite explicit:
----------------------------------------------------------------------
   IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and
   AH associations for the same IP addresses it runs over. 
----------------------------------------------------------------------

What is the problem with current text, and what should be added to
there to make it more clear?

> i.e., no NAT-T or not for the peer behind a NAT).

Ok, now I do understand. Yes, I do agree that we SHOULD use the
addresses of the initial IKE SA creation, not the CREATE_CHILD_SA
messages.
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 11 Sep 2003 08:55:24 -0700

>    As I said earlier, no tagging is really needed.

Actually, Francis is right (but see below) - I had not noticed that
Theodore said "SEQUENCE OF CHOICE."  The I-D says:

"
"

which implies a SEQUENCE OF SEQUENCE, not SEQUENCE OF CHOICE;
this is because of the "and" in the last sentence.  I.e.,

Cert-Bundle ::= SEQUENCE OF SEQUENCE {
    cert    <some ASN.1 type for certificate - the I-D should be specific>,
    CRL	    <same other ASN.1 type for CRL - again, please specify>
}

Regardless of whether the I-D meant "SEQUENCE OF SEQUENCE" or "SEQUENCE
OF CHOICE" it is clear now to me that the I-D has to be a lot more
specific - it should even name the ASN.1 types (_and_ the OIDs for the
modules whence they are to be IMPORTed) for certificates and CRLs, even
if we're all supposed to know what they are (future readers may not).

Friends don't let friends underspecify.

> and it is the case here (a CHOICE between two SEQUENCEs).

Definitely, unless those sequences are explicitly tagged with, say, some
application tag (but I see that "Certificate" is NOT so tagged, for
example, even in PKIX1Explicit93

But the I-D wording suggests SEQUENCE OF SEQUENCE (without OPTIONAL
fields, I presume [see? a possibly bad assumption]), in which case
there's no ambiguity.

[...]
> possible: ", respectively with implicit tags 0 and 1".

Er, the ASN.1 specs are OPEN and can be retrieved from the ITU-T site as
PDF documents.

> For instance I implicitly translate the English word "and" into the ASN.1

I myself do not.  Evidently the "certificate bundle" is structured data
whose encoding ought be specified, and ASN.1 is a perfectly appropriate
syntax for the purpose (and one of several).

I don't mean to say that you MUST use ASN.1, but that a well specified
encoding for the "certificate bundle" is needed.

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 11 Sep 2003 09:03:24 -0700

>  "AlternativeTypeLists" shall have distinct tags")

Specifically they are SEQUENCEs that are either both not tagged or are
not tagged with different tags.

"CHOICE { foo, bar }" is ok, provided that foo and bar have distinct
outer tags.

Cheers,

Nico
--

---

From: Francis Dupont <[email-masked]>
Date: Thu, 11 Sep 2003 18:35:19 +0200

=> I am afraid this is the kind of game where the guy who says it is not
clear shall always win (:-).

   
   
=> yes, the detection part is right (after your fix). My concern is
about the applicability part which can be interpreted as to be applied
only to IKE packets. But this can be fixed (i.e., clarified) in a few
words.

   
=> the expression "the IP addresses it runs over" is not enough
accurate. But I agree we have just to improve a bit the wording.

=> if suddenly a CREATE_CHILD_SA message "runs" over a new source address,
should be the IPsec SAs set up for the new address or for the old address
used for all previous IKE messages? The current wording doesn't help to
do the choice, an improved wording will give a SHOULD for the second
choice (use the old address). IMHO the best way is to explain that the
peer addresses are IKE SA parameters and IKE SHOULD set up IPsec SAs
for them.

=> we agree: we have only to find the good wording.

Thanks

---

From: Francis Dupont <[email-masked]>
Date: Thu, 11 Sep 2003 19:24:51 +0200

"

=> I have a private message from the author where he confirmed he means
a CHOICE (I can develop type theory arguments explaining why but
this is not the place. Note that as soon as we reach a common understanding
in the list we ne more need to ultraclarify the point in the document).

=> from RFC 3280: cert = Certificate and CRL = CertificateList

   }
   
=> I strongly disagree with the SEQUENCE OF SEQUENCE interpretation,
the text is "SEQUENCE of certificates and CRLs", not "SEQUENCE of
certificate and CRL pairs". I.e., the each element of the SEQUENCE is
a certificate (PKIX certificates and CRLs are well defined, perhaps
a reference to RFC 3280 is missing in the paragraph) or a CRL.

=> no, too much ASN.1 is not a good idea.

=> the only real issue is in fact the type of tagging.

   
=> no PKIX or X.509 stuff uses application tags.

=> if the fields are not optional then they are mandatory so they comes
by pairs of a certificate and a CRL. If they are optional then at least
a tag is needed and the difference with a CHOICE is limited...

=> freely retrieved? I know there are freely available somewhere but
not at the ITU-T site (note that I'd like to be wrong :-).

   
=> There is not several ways to put certificates and CRLs in a SEQUENCE:
 - SEQUENCE of CHOICEs (SEQUENCE OF CHOICE { cert, CRL })
 - SEQUENCE of SEQUENCEs (SEQUENCE { SEQUENCE OF cert, SEQUENCE OF CRL})
I know that it is the first one because when I asked why not use a SET
of CHOICEs, Paul Hoffman confirmed it and gave an argument (reordering
issue with SETs for people whose encoder always does DER) against SETs.

=> if you really believe the CHOICE interpretation is not so clear,
what about ", respectively with implicit tags 0 and 1 in CHOICEs"?

Thanks

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 11 Sep 2003 10:43:42 -0700

> in the list we ne more need to ultraclarify the point in the document).

Good, now let's clarify.

> => from RFC 3280: cert = Certificate and CRL = CertificateList

The I-D MUST state so.

> a reference to RFC 3280 is missing in the paragraph) or a CRL.

This merely proves that it's easier to disagree about the meaning of
English language text than it is to disagree about the meaning of a
specification written in a formal language.

> => no, too much ASN.1 is not a good idea.

This is not too much - and we've seen the confusion and incorrect
specification that results from too little.

DEFINITION EXPLICIT TAGS ::=
BEGIN

IMPORTS Certificate, CertificateList FROM PKIX1Explicit93
-- or from PKIX1Explicit88, which is what's in rfc3280

CertificateOrCRL ::= CHOICE {
    cert [0] Certificate,
    crl  [1] CertificateList
}
CertificateBundle ::= SEQUENCE OF CertificateOrCRL

END

Now how is this too much ASN.1?

> => the only real issue is in fact the type of tagging.

No, I misundertood the English language description of "certificate
bundle" but would not have misunderstood the above ASN.1 module.

> => no PKIX or X.509 stuff uses application tags.

Sure, but by not specifying what the CHOICE alternatives' types are or
where they come from one cannot know for sure if the CHOICE is
ambiguous, which is why it's proper for the I-D to be explicit.

> not at the ITU-T site (note that I'd like to be wrong :-).

I to am glad that you're wrong on this:

http://www.itu.int/ITU-T/studygroups/com17/languages/

> what about ", respectively with implicit tags 0 and 1 in CHOICEs"?

I think the ASN.1 module given above is quite simple, easy to read and
clear, clearer than English language text.

If you insist on an English language description of the encoding of
"certificate bundle" then let me suggest:

   The bundle is encoded as the BER [X.690] encoding of an ASN.1 [X.680]
   SEQUENCE OF CHOICE where the choices are the Certificate and
   CertificateList types from PKIX1Explicit93 [or 88] explicitly tagged
   with context tags 0 and 1, respectively.

Please ensure the presence of _normative_ references to X.680 (ASN.1)
and X.690 (BER).

Cheers,

Nico
--

---

From: Francis Dupont <[email-masked]>
Date: Fri, 12 Sep 2003 13:50:24 +0200

The I-D MUST state so.
   
=> the I-D says PKIX certificates and CRLs. There is no ambiguity
at all, mainly because of the "PKIX" word.

=> the problem is a formal language can be very boring.
Two other remarks:
 - we don't need the abstract syntax, only the concrete data layout.
 - most of the other CERT types are very underspecified, for instance
   the DNS Signed Key...

   

=> I prefer IMPLICIT tagging (which gives shorter encoding).

   BEGIN

=> we have the choice between PKIX{Explicit,Implicit}88 if we use
only the RFC 3280.

=> the names of the field (cert and crl) are examples of overspecification:
they are not needed for interoperability, only by ASN.1.

   END

=> I have no trouble with ASN.1, let the WG decide how much of ASN.1
it can eat.

=> very fine!

   

=> thanks

---

From: Karen Seo <[email-masked]>
Date: Thu, 25 Sep 2003 09:03:09 -0400

Francis,

Thank you for catching these problems.  We've submitted a revised 
draft to the IETF secretariat with the changes listed below.  These 
have been approved by Russ Housley with the observation that "... 
this puts a normative reference on 2401bis, so it will not be 
published as an RFC until 2401bis is published."

Thanks again,
Karen

>  - in 2.6  Integrity Check Value (ICV):
>
>    This is a variable-length field that contains the Integrity Check
>    Value (ICV) for this packet.  The field must be an integral multiple
>    of 32 bits (IPv4) or 64 bits (IPv6) in length.
>
>  => the wording is very misleading: one can interpret it as an ICV length
>     of 96 bits is illegal for IPv6 (when this is the currently used length
>     for IPv4 and IPv6 AH and 3.3.3.2.1  ICV Padding gives this for example).
>     IMHO the constraint is for the whole extension, the ICV has only to
>     be on a multiple of 32 bits.

	The text noted above has been changed to:

	"This is a variable-length field that contains the Integrity
	Check Value (ICV) for this packet.  The field must be an
	integral multiple of 32 bits (IPv4 or IPv6) in length.

	The paragraph also already says:

	"This field may include explicit padding, if required to
	ensure that the length of the AH header is an integral
	multiple of 32 bits (IPv4) or 64 bits (IPv6)."

>  - 3.1.2 Tunnel Mode: this section doesn't suggest the outer header can
>    use IPvX when the inner is IPvY with X != Y. IMHO we have only to confirm
>    that IPv6 over IPv4 and IPv4 over IPv6 are legal in tunnel mode.
>    I notice this because the lack of "crossed" IP versions in tunnel mode
>    comes just after the spuirous check of the outer source address in interop
>    issues in common implementations...

	To avoid delays and consolidate info that's common between AH and
	ESP, we will note in 2401bis that one can mix and match v4 and v6
	in constructing inner and outer tunnel headers.

>  - 3.1.2 Tunnel Mode: the legend:
>            * = construction of outer IP hdr/extensions and modification
>                of inner IP hdr/extensions is discussed below.
>
>    refers to a discussion which is not convincing:
>
>    In tunnel mode, the outer and inner IP header/extensions can be
>    inter-related in a variety of ways.  The construction of the outer IP
>    header/extensions during the encapsulation process is described in
>    the Security Architecture document.
>
>  => I suggest to use the same legend than in ESP-v3:
>
>             * = if present, construction of outer IP hdr/extensions and
>                 modification of inner IP hdr/extensions is discussed in
>                 the Security Architecture document.

	Done.

>- 3.2  Integrity Algorithms: there is a missing closing parenthesis.

	Changed second sentence from:

	For point-to-point communication, suitable integrity
	algorithms include keyed Message Authentication Codes (MACs)
	based on symmetric encryption algorithms (e.g., AES [AES] or
	on one-way hash functions (e.g., MD5, SHA-1, SHA-256, etc.).

	To:

	For point-to-point communication, suitable integrity
	algorithms include keyed Message Authentication Codes (MACs)
	based on symmetric encryption algorithms (e.g., AES [AES]) or
	on one-way hash functions (e.g., MD5, SHA-1, SHA-256, etc.).