Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt

From: [email-masked]
Date: Tue, 18 Dec 2001 17:17:47 -0000

Well, you can't authenticate it because RFC2402 defines the flow label as
mutable end-to-end. I think this draft probably needs to address this
discrepancy if it is going to define the flow label as immutable end-to-end.

Mat.

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: 18 December 2001 16:43
> To: Michael Thomas
> Cc: Craig Dunk; 'James Kempf'; Margaret Wasserman;
> [email-masked]
> Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt
> 
> 
> I agree; I meant that even at the receiving end you can't 
> authenticate it,
> let alone the intermediate hops.
> 
>    Brian
> 
> Michael Thomas wrote:
> > 
> > Brian E Carpenter writes:
> >  > Yes, the flow label is explicitly excluded from AH. So 
> it could be modified
> >  > en route and you can't authenticate its value. Assuming 
> we decide to use
> >  > it as an end2end value, that could be viewed as a bug.
> > 
> >    That would be a pretty funny view. The only
> >    way to make it immutable would be to share a
> >    security association with each participating
> >    router along the way. I don't think we want
> >    to even vaguely contemplate going there.
> > 
> >            Mike
> 
> -- 
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Brian E Carpenter 
> Distinguished Engineer, Internet Standards & Technology, IBM 
> On assignment at the IBM Zurich Laboratory, Switzerland
> Board Chairman, Internet Society http://www.isoc.org
> --------------------------------------------------------------------
> 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]
> --------------------------------------------------------------------
> 
--------------------------------------------------------------------
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: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Dec 2001 11:37:55 +0100

We can note the discrepancy, but I doubt if we can change
IPSEC at this point in time.

   Brian

---

From: Robert Elz <[email-masked]>
Date: Wed, 19 Dec 2001 18:25:08 +0700

Date:        Wed, 19 Dec 2001 11:37:55 +0100
    From:        Brian E Carpenter <[email-masked]>
    Message-ID:  <[email-masked]>

  | We can note the discrepancy, but I doubt if we can change
  | IPSEC at this point in time.

We wouldn't want to anyway.   The draft doesn't make the field immutable,
it just makes it usually immutable.   If it was 0 at the source, then it is
mutable, and if the host has told some router(s) that it is OK to alter it,
it is mutable as well.

Attempting to have IPSec deal with that would be silly.

So, it is possible for routers to alter it, undetectably to the receiver.
(Or unless  copy of what it should be has been sent via other methods,
which it very well might be if there's been some flow setup done - the
receiver might even have told the senders what value to use if this a
multicast session set up via sd or similar).

That it is possible however doesn't mean that we can't tell them they
must not - just as well tell them they must not increment the hop limit.
If they do, there's no way for the receiver to know, so a router could.
But it must not - it must decrement it instead.

kre