Subject: Re: Mutable fields and the Hop-by-Hop and Destination Options headers

From: Steve Deering <[email-masked]>
Date: Tue, 14 Nov 2000 21:40:38 -0800

At 9:10 PM -0800 11/14/00, Brian Zill wrote:
>Therefore, I'd like to propose that the spec is clarified to limit mutable
>options to where they make sense, i.e. in Hop-by-Hop and Destination Options
>headers that appear before the Routing Header.

Alternatively, we could specify that any mutable options that appear
after the AH header are treated as if they were immutable, i.e.,
included in the authentication computation.  Such options, though mutable,
would not undergo mutation, so could safely be treated as immutable by AH.

>P.S.  As an aside, it occurs to me that it might be clearer to define a new
>"Intermediate Destination Options" header to take the place of DO1.  Then it
>could be declared that this new header (if present) MUST appear before the
>Routing Header, and that mutable options (if present) MUST appear in either
>this new header or a Hop-by-Hop header.  Or to put it another way, mutable
>options wouldn't be allowed any more in a Destination Options header.  This
>would also make the spec cleaner - it could get rid of the special case
>notations explaining the difference between DO1 and DO2.

Sounds reasonable, but seems to me like a significant change for a small
benefit at this point.

Steve

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "Markku Savela" <[email-masked]>
Date: Wed, 15 Nov 2000 10:39:15 +0200

> From: EXT Steve Deering

> would not undergo mutation, so could safely be treated as

At least I definitely prefer this approach (this is the way I have it
implemented).

AH (nor any other extension header) should not care what follows after it,
it's just payload at that stage.

---

From: Francis Dupont <[email-masked]>
Date: Wed, 15 Nov 2000 10:31:35 +0100

=> Steve, I think we can avoid the change. The current DO1+DO2 stuff is
very hard to implement and there are many reasons to introduce a third
placement for destination options: we (IPng WG) should accept that
the destination option stuff must be rewritten, if possible for
the IPng meeting then:
 - write a draft before Friday
 - ask for a slot to explain the issue and proposed solution(s)

Thanks

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Wed, 15 Nov 2000 10:42:33 +0100

=> I have done the same thing then I should agree but:

=> this cannot deal with the case where there are more than one AH header
(I've seen some mails about this issue but I don't remember whether this
issue was solved and (more important) how). Of course the problem is
detected when the internal AH is processed...

Thanks

---

From: "Markku Savela" <[email-masked]>
Date: Wed, 15 Nov 2000 12:13:28 +0200

> -----Original Message-----
> From: EXT Francis Dupont

> detected when the internal AH is processed...

Works quite fine(?) if you adopt the logic that assumes incremental building
of multiple AH's. On receive, AH processing removes the outer AH header,
before proceeding to the next header. On send, one adds AH at time, from
inside-out, independently of each other (previous AH is just payload for the
new one).

This goes against "read-only" buffer on receive, but IPSEC ESP requires
modifiable buffer (or copy) anyway, so having AH to modify (at least
logically) the buffer, is not so bad.

I think this was discussed on IPSEC list while back (last year?). I prefer
the incremental, of course!

---

From: Jim Bound <[email-masked]>
Date: Thu, 16 Nov 2000 04:52:59 -0500

Steve,

Coudn't we do what Brian wants or with your suggestion with a BCP rather
than messing with 2460.?  

I would not hold up 2460 to IS for  this changed.

regards,
/jim