Pekka Savola | 19 Mar 2006 15:16
Picon

NEA heads-up

FYI,

Some of you probably already know that there'll be an Internet area 
BoF on Network Endpoint Attachment (NEA).  It seems to address an 
important subset of the distsec problem space.  I'd recommend folks 
join the mailing list and go to BoF to see how it fits in our model 
(or our model in theirs).

Below is my short commentary on it.

---------- Forwarded message ----------
Date: Sun, 19 Mar 2006 16:13:55 +0200 (EET)
From: Pekka Savola <pekkas <at> netcore.fi>
To: nea <at> ietf.org
Subject: heads-up on distsec

Hi,

I just read the NEA problem statement and it looked rather sensible. What you 
didn't explain very extensively is your threat model.  You can be sure this 
will come up in the BoF from someone..

You already raise NEA Client self-integrity as an issue in Section 9.3.  But is 
NEA approach good enough here because the first thing a next-generation 
worm/virus/malware will do is trick the NEA client using one of various 
techniques, therefore making the real posture undetectable?

You may not be aware of the "distsec" effort (the lastest draft rewrite is 
draft-kaeo-distsec-framework-00.txt), which describes a superset problem.  I'd 
recommend taking a look for ideas how to refine the problem statement, threat 
(Continue reading)

Tschofenig, Hannes | 19 Feb 2006 01:29
Picon

review of draft-kaeo-distsec-framework-00.txt

hi all, 

i went throught the new draft and my impression is that the quality has
improved considerably. 

here are some minor comments:
http://www.tschofenig.com/TEMP/draft-kaeo-distsec-framework-00-hannes.tx
t

i am looking forward to discuss this work at the next ietf meeting. 

ciao
hannes
Pekka Savola | 2 Feb 2006 19:52
Picon

updated distsec framework & threat model

Hi,

Merike and myself have rewritten the threat model document, and now 
try to provide a both bare-bones, compact framework description and 
threat model in a single, short (10 pages) document.

It has been submitted for I-D publication, but in the meanwhile 
accessible at:

http://www.netcore.fi/pekkas/ietf/draft-kaeo-distsec-framework-00.txt

We'd *REALLY* quick feedback on this, especially from folks that 
thought the previous document structure or contents weren't good 
enough.

--

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Hannes Tschofenig | 16 Jan 2006 11:40
Picon

Review Comments

Hi all,

here is my impression after reading the two documents (framework & 
threats draft).

- the work needs to be refocused: what do you really want to develop?
i assume you want to
a) define (or select) a protocol to carry policies
b) define (or select) a language for writing these policies

that's all you want. you don't need to rehash the entire history of 
firewalls up and down.

additionally, you need to decide whether you want to focus on packet 
filter policies or for other policies as well. don't talk about virus 
filtering and intrusion detection if your main focus is on firewalls.

- incorporate the threats draft into the framework draft.
if you only focus on the above-described case then the protocol is 
pretty simple and the security threats should focus on the protocol you 
want to develop. you don't want to describe all the security threats 
that can happen in a network.

currently, i don't think that the threats document really contains 
relevant content for the topic you want you are interested in.

- make the framework document shorter. try to make it as short as possible.
make the long story short: "you want to configure policies at the end 
host to perform firewalling functionality." that's it. we don't need to 
give a tutorial about firewalls. it is a deployment choice whether you 
(Continue reading)

Elwyn Davies | 10 Jan 2006 12:51

Re: Do we want distsec BOF at IETF65?

These are the latest in the draft archive but Alvaro had more or less 
completed version 01 of the framework and sent it to this list on 
30/09/2005.  I had commented extensively on -00 and Alvaro had 
incorporated many of these comments and some other changes.

I have copied his file here for your convenience.

I am willing to continue working on this subject and will help with the 
drafts etc.

Regards,
Elwyn

Jordi Palet wrote:

>Hi Hannes,
>
>The latest versions are:
>
>draft-savola-distsec-threat-model-01.txt
>draft-vives-distsec-framework-00.txt
>
>Regards,
>Jordi
>

Alvaro Vives wrote (on 30/9/05):

> 
>Here is the framework draft txt.
(Continue reading)

Pekka Savola | 9 Jan 2006 13:48
Picon

Do we want distsec BOF at IETF65?

Folks,

Is there interest in having a distsec BOF at Dallas IETF next March?

But even if so, just interest isn't enough.  We'd need folks to 
actually do some work (edit drafts, etc.) if we wanted to make this 
happen.  So far, there has been no significant activity.

A few items to work on right now might include:
  1) a rewrite of the threat model document (to include sufficient
     context etc.)
  2) revision of the framework document
  3) finding BOF chairs who have sufficient time to continually
     pursue this work, and make sure things keep progressing.
  4) going further with the analysis of what's currently out there.
  5) getting folks with already implementations signed up to the
     effort.

The threat model should have been revised around the end of December. 
As you see, it hasn't been.  So now would be the last minute to say:

"Hey, I want to help!  Can I do [foo] or could you tell what I should 
be doing?"

--

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Pekka Savola | 17 Nov 2005 12:10
Picon

summary of discussion with AD

Hi all,

A couple of folks had a lunch meeting with Sam Hartman on what should 
be the next steps to be able to have a distsec BOF at the next IETF in 
Dallas.

As you see, quite a bit of work needs to happen, particularly in 
focusig the threat model and the problem statement.

.....

Attendance:  Jordi Palet, Pekka Savola, Sam Hartman, Merike Kaeo

Sam wanted to know two specific things:
1. what problem is being solved
2. what is the threat model

Discussion:
===========

Specifically, what security issues are being addressed and is
it a reasonable solution?

  - Distributed policy for giving firewall configuration to network
    enforcement elements (no need to involve hosts)

  - If host should enforce policy while not on network

  - If host should enforce policy to enforce other hosts if other
    network elements cannot involve other mechanisms
(Continue reading)

Melinda Shore | 8 Nov 2005 13:49
Picon
Favicon

Bar bof?

If there is a bar confab, could someone take notes for those of us
who aren't able to be there?

Thanks,

Melinda
Ruri Hiromi | 8 Nov 2005 02:31
Favicon

Fwd: (secure6-wg 625) Fwd: distsec Digest, Vol 2, Issue 3

Pekka,

When do we have the unofficial bar-BOF?
If you fix the time and place, can you feed me the info, please?

(if I skipped something in distsec ml, sorry for that)

Regards,

>> Date: Fri, 7 Oct 2005 13:48:47 +0300 (EEST)
>> From: Pekka Savola <pekkas <at> netcore.fi>
>> Subject: [distsec] No official BOF in Vancouver
>>
>> Hi,
>>
>> The ADs felt that we weren't yet sufficiently far along to approve a
>> BOF for Vancouver IETF. (Personally, I understand that decision as I
>> had some doubts myself.)
>>
>> Let's continue the work so that we can have a very convincing case  
>> for
>> the next IETF.
>>
>> There might be some sort of unofficial bar-BOF or other kind of
>> get-together to get more face-to-face discussion on the approach.
>>
>> -- 
>> Pekka Savola                 "You each name yourselves king, yet the
>> Netcore Oy                    kingdom bleeds."
>> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
(Continue reading)

satoshi_kondo | 27 Oct 2005 12:23
Picon

Related issues discussion in past IETF meeting

Hi, 

I found the related discussion in EAP WG meeting report at 63th IETF.

http://www3.ietf.org/proceedings/05aug/eap.html

See, meeting report 6. Trusted Computing Group EAP Issues (20 min) --
John V.

TNC by Trusted Computing Group is very simlar model with our distributed
security framework.
In that discussing, they try to put their option or enhancement for EAP
to suppurt TNC architecture
 to be standarization process in EAP WG.

Does anyone known about detail of this discussion in this session and
conclusion ?

Satoshi Kondo
Trend Micro Inc.
Eric Gauthier | 12 Oct 2005 18:06

Internet2 Work on network Security/Policy enforcement

Hello,

I'm involved with a group called SALSA-Netauth
(http://security.internet2.edu/netauth/), which is a working group within
the US's Internet2 consortium, that has been looking at what we've called
"automated policy enforcement", something that we feel is very similar to an
architecture for distributed and layered security. 

Several of us are very interested in the work that you are planning to do.
Reading through the mailing list archives, there seems to be a focus here on
distributed firewalls, whereas our work has focused more on generalized
network techniques to protect hosts, with firewall rulesets being only one
component of this, so we were not sure if you would be generally interested
in the work we've been doing.

To date, we've generated two documents of our own, one is a "strategy"
document covering various solutions to network policy enforcement.  Though
its similar in concept to a threat model, because the problem-space among
the various educational institutions was fairly well known and understood,
the document is more of an overview of the various solutions
(http://security.internet2.edu/netauth/docs/internet2-salsa-netauth-policy-e
nforcement-200504.html).  

The other document represents an idealized architecture for implementing and
integrating various enforcement technologies
(http://security.internet2.edu/netauth/docs/draft-internet2-salsa-netauth-ar
chitecture-04.pdf).  Though targeted specifically at educational
institutions, we've always felt that our approaches were more generic and
applicable to a wide range of networking scenarios.

(Continue reading)


Gmane