Subject: Security considerations about the flow label

From: [email-masked]
Date: Wed, 22 Nov 2000 15:43:55 +0200

Dear list,

sorry to stir the hornet's nest about end-to-end flow labels, but I think
there are some security problems in them.

First, the labels are excluded from the IPSec AH, which means they cannot be
trusted. I wouldn't build a service that is based on them, unless there is
some other way to make them trustworthy. Like keeping the server and the
client within the same administrative domain.

Another problem is a covert channel. If a client can set the flow label
bits, it can communicate with the outside world without anybody noticing. I
don't mean just transmitting payload without paying for it. There are spy
programs, too.

Don't-care bits should not cross a security perimeter. All header fields
that are not protected by the IPSec AH should be overwritten by edge
routers. Either by something neutral (like zeroes for flow label) or values
that have been agreed with the peering domain (DiffServ Code Points).

I vote for edge-to-edge flow labels, not end-to-end.

-- Lassi

--------------------------------------------------------------------
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 Zill <[email-masked]>
Date: Wed, 22 Nov 2000 12:35:04 -0800

I don't follow your logic here.  You say you want edge-to-edge flow labels,
not end-to-end, yet complain that flow labels are not secure since they are
not covered by AH IPsec.  If they were covered by AH ipsec, then they would
be secure end-to-end, not edge-to-edge.  We have no mechanism to secure
things edge-to-edge (unless you're counting on all edges being security
gateways with all "inside" traffic existing in IPsec tunnels).

I also don't understand your concerns regarding a covert channel.  Since
IPsec is secure end-to-end, the trust is in the end hosts.  Of course they
can send whatever data they want encrypted and hide it from things in the
middle.  This is a feature.  If the worry is that routers along the way can
piggy-back a covert channel, there are many other ways to do that.  They can
play games with the Hop Count, for one.  Or in packets that contain at least
one Hop-by-Hop or Destination Option, they can add another one of their own
invention with the upper bits set to 001 so it will be skipped over by
routers that don't understand it and treated as mutable by AH.

--Brian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, 22 November, 2000 05:44
> To: [email-masked]
> Subject: Security considerations about the flow label
> 
> 
> Dear list,
> 
> sorry to stir the hornet's nest about end-to-end flow
> labels, but I think there are some security problems
> in them.
> 
> First, the labels are excluded from the IPSec AH,
> which means they cannot be trusted. I wouldn't build
> a service that is based on them, unless there is some
> other way to make them trustworthy. Like keeping the 
> server and the client within the same administrative
> domain.
> 
> Another problem is a covert channel. If a client can
> set the flow label bits, it can communicate with the
> outside world without anybody noticing. I don't mean
> just transmitting payload without paying for it. 
> There are spy programs, too.
> 
> Don't-care bits should not cross a security perimeter.
> All header fields that are not protected by the IPSec
> AH should be overwritten by edge routers. Either by
> something neutral (like zeroes for flow label) or
> values that have been agreed with the peering domain
> (DiffServ Code Points).
>

---

From: Kais Belgaied <[email-masked]>
Date: Wed, 22 Nov 2000 15:54:45 -0800 (PST)

>routers that don't understand it and treated as mutable by AH.
I think the tiny covert channel meant is that one of the end hosts leaking out
(intentionally or being exploited by a malicious insider)  
information using a field not covered by IPSec's protection, and tries to do so
without being noticed. The recipient of
the leaked info is not necessary the other end host (trusted).
Messing with the hop count may work, but, due to non predictible re-routes,
it is not reliable for the spy who cares about the integrity of the data being
leaked.
Mutable h-b-h or dest1 options could also be exploited, but, again, they are
mutable, and may mean something to routers in between and get altered.

	Kais.

---

From: Brian Zill <[email-masked]>
Date: Fri, 24 Nov 2000 10:58:13 -0800

> I think the tiny covert channel meant is that one of
> the end hosts leaking out (intentionally or being
> exploited by a malicious insider) information using
> a field not covered by IPSec's protection, and tries
> to do so without being noticed.  The recipient of the
> leaked info is not necessary the other end host (trusted).

Okay, I can understand this concern.  Unfortunately, malicious insiders are
very hard to protect against.  Those end nodes essentially become untrusted.
Untrusted nodes can do all sorts of unsavory things.  I don't think this
covert channel issue is something we need to worry about when debating how
to define the flow label.

[The rest of this message is just an academic exercise]

> Messing with the hop count may work, but, due to
> non predictible re-routes, it is not reliable for the spy
> who cares about the integrity of the data being leaked.

I suspect you would find that in practice the upper two or three bits of the
hop count never change over the life of most connections.  With a little bit
of error correction, you could probably get a decent (albeit low bit rate)
data channel over that.

> Mutable h-b-h or dest1 options could also be exploited,
> but, again, they are mutable, and may mean something to
> routers in between and get altered.

Ah, you missed my point about setting the option type bits appropriately.
You could invent your own option with a new type code (so no intervening
routers will mess with it) and set the upper bits to 00, causing nodes that
don't understand this type to just skip over the option instead of dropping
the packet or flagging an error.  I thought of a different flaw with this
scheme after sending that, however.  While AH can be told to treat this new
option as mutable, it still includes the option in the ICV calculation (as
all zeroes).  So if it is added after the ICV calculation on the sending
side, then the receiving covert entity on/near the other end would have to
strip out this option before it made it to it the intended receiver.  But if
the malicious insider can add the option before the ICV is calculated (and
marks it mutable), then the covert receiver could just read it (and wipe the
bits if it cared to) before the intended receiver saw the packet.

--Brian