netdev
[Top] [All Lists]

Re: [Design] skb->security and friends

To: Manon Goo <lists@xxxxxxxx>
Subject: Re: [Design] skb->security and friends
From: Michael Richardson <mcr@xxxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 26 Oct 2001 12:14:45 -0400
Cc: Martin Josefsson <gandalf@xxxxxxxxxxxxxx>, design@xxxxxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: Your message of "Fri, 26 Oct 2001 17:19:46 +0200." <5452570.1004116785@f190>
Sender: owner-netdev@xxxxxxxxxxx
-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Manon" == Manon Goo <lists@xxxxxxxx> writes:
    Manon> --On Freitag, 26. Oktober 2001 17:02 +0200 Martin Josefsson 
    Manon> <gandalf@xxxxxxxxxxxxxx> wrote:

    >> On Fri, 26 Oct 2001, Manon F. Goo wrote:
    >> 
    >>> 
    >>> >
    >>> >   Aha, RGB! a customer for the skb->{security,ipcb,fwmark} mechanism.
    >>> > Well maybe.
    >>> >       skb->security      (16-bit)
    >>> >       skb->nfmark        (much contention for this field)
    >>> 
    >>> is it planed to be able to set nfmark value per connecction for later
    >>> processing with iptables ?

    Manon> would it not be more convinient to define the netfilter mark for the 
ipsec 
    Manon> connection
    Manon> so when the connection is setup it is automaticly marked an can be 
procesed 
    Manon> in the
    Manon> fw rule set.

  There are three problems:
        1) allocation of nfmark bits. Is this a solved problem yet?
        2) IPsec needs more than 1 bit to indicate the tunnel number.
        3) it doesn't solve the problem of marking skb's that need to go into 
           a tunnel.

  Perhaps many people think that they can live with a bit field to say
"encrypted" or "not", but we generally find that to be a very poor mechanism.

  We eventually need to indicate at least four different results of policy:
     1) the packet arrived in the clear.
     2) the packet arrived authenticated, but in the clear.
     3) the packet arrived encrypted, via un/weakly authenticated opportunistic
        tunnel.
     4) the packet arrived encrypted with a strongly trusted tunnel.

  We would prefer to indicate more than 4.

  Inability to distinguish between #3 and #4 will prevent people from
deploying Opportunistic Encryption on the same machines which they currently
do configured tunnels.
  (We may also provide other mechanism to distinguish between #3/#4, but they
likely will have scaling challenges)

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@xxxxxxxxxxxxxxxxxxxxxx http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Finger me for keys

iQCVAwUBO9mL8IqHRg3pndX9AQHLPwQA25ljvkPr65Y1F6lcyaXMOkiMIhMNf1aK
vJhxJoZ0CSQ4mtB0yzLUt+QAn4Nzn1eLINtGbeWEj5O5HAkEScztGJ2DQD+se84r
4DBttWVuv5xUtC0R3CckAYMgKs/M1Atw4sIAIgc5XBIMmhugJi/AQorisJp+RN0k
YlBZzS13gGg=
=I8uE
-----END PGP SIGNATURE-----

<Prev in Thread] Current Thread [Next in Thread>