Subject: Re: framework draft v07 uploaded to IETF

From: "Yang, Lily L" <[email-masked]>
Date: Tue, 5 Aug 2003 09:30:25 -0700

Hi, Jamal --

I want to thank you for bringing up the discussion on security -- this
is THE one big change in the new revision and we had not heard much
comment about it until now. It always makes me nervous when a big chunk
of new text in a draft receives only silence -- it means only one of two
things to me -- either it is entirely useless, or, it is so wrong and
messed up that people don't even know how to start correcting it.

So I do want to encourage people on this list taking the time to go over
the security Section 7 and provide feedback.

To clarify a few things:
1) It was me who invited Ram Gopal to write the text on security section
for framework after receiving comments from the AD because of his
expertise and working experience in the security area with other WGs. It
was also me who was responsible for reviewing, editing and finalizing
the text with help from other co-authors (Todd and Ram Dantu). I can
testify that the protocol solution was never part of the discussion. As
a matter of fact, we made it very clear and explicit that it is not the
framework's business to pick and choose the transport and the protocol.
That is exactly why we have two recommendations (other than "no
security") on the table -- one (TLS) assumes reliable transport while
the other (IPSec) assumes IP only. You can argue there is still ground
that we didn't cover - for example, what if we don't even use IP at all?
Well, if people on the mailing list feel there are compelling reasons to
consider such case, we can discuss it. 

2) About multicast versus unicast: I went back my archive and looked
over my notes on the security revisions we've had between Ram and
myself. I realize that the original text Ram gave me did include some
discussion on the implication on multicast for both TLS and IPSec. I
took out those text based on the arguments that multicast is not a
"must-support" by requirement and security support for multicast is
problematic and shaky. But in hindsight, I realize it is a mistake not
discussing multicast in the framework. Like you said, it seems a very
natural thing to do between one CE and multiple FEs. But the unfortunate
situation in the state of the art in supporting secure multicast has
some important implication that is worth calling out explicitly. As Joel
pointed out, it is simply beyond the scope of this WG, let alone the
framework document itself, to devise a security scheme for multicast in
general. If you have some specific ideas how we can go about doing that,
we certainly welcome your input. Other than that, all we can do in the
framework is to document the current state of the art and implication to
ForCES and then make recommendation accordingly. 

I will send out another email soon with proposed change in text on
security. Meanwhile, we welcome any more suggestions and comments from
you and everybody else in the list. But please do so soon as we still
intend to get it to IESG review soon.

Thanks,
Lily

-----Original Message-----
From: Jamal Hadi Salim [mailto:[email-masked]] 
Sent: Monday, August 04, 2003 8:25 PM
To: [email-masked]
Subject: Re: framework draft v07 uploaded to IETF

Ram,

You clearly have semantics all over the document that indicate
unicast. Example:

-------
We recommend using ESP in transport mode for ForCES because message
confidentiality is required for ForCES and the communication between the
CE and FE is point-to-point.
-------

I dont think i should be nitpicking on the text because it is
a waste of time - We have had this struggle all along in the
requirements
document as well between you, Hormuzd and myself.

The primary objective is to build a protocol that does FE<->CE
communication, not build a security mechanism then wrap it with a
protocol that does CE<->FE communication.

Since we dont know what the final protocol is going to be
please stop putting restrictions. Example your text below.

On Mon, 4 Aug 2003, (Ram Gopal ) wrote:

>
> FYI with IPsec (refer RFC 2401), one can use with multicast for
> integrity and confidentiality with
> a compromise on rekeying and replay protection.
>

What next? "oh, btw you cant use TLS because you use Multicast".
Maybe you'll point to the requirements and say why multicast is not
allowed. Perhaps something i missed during the requirements collection.

Whether you think it is right or not, multicast is very appealing
for Forces: Single CE, multiple FEs (point to multipoint); HA,
redundancy etc. Please do not impose any restrictions which will rule
out
its use when we havent decided on the protocol.
BTW, your statement on IPSEC above is innacurate - and while that is
beside the point - it shows you are on one extreme.

You are making recomendations. The definition of the word is
pretty clear. You say TLS for example can "satisfy all requirements of
security" - YES, this is true provided you use a) unicast transport b)
which is TCP (any other thing working with TLS is obscure).

Lets have someone else - not you, not Hormuzd, not me (we are all
biased) - to write this text with objectivity in mind, not based on a
solution of any form.

Another alternative is to delay this document until we select a
protocol.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 5 Aug 2003 16:47:10 -0400

Lilly,

Let me jump to your email and skip the others - hopefully address both
Joel and Ram at the same time.

> comment about it until now. It always makes me nervous when a big chunk

I actually find it hard to reread the whole draft again everytime a new
one comes out - so normally i just skim through it.If you notice i first
sent an OK for the draft noticed that text.

> messed up that people don't even know how to start correcting it.

Or nobody read the draft - which is a lot more dangerous.

> framework's business to pick and choose the transport and the protocol.

yes, but then, when you say ...

> security") on the table -- one (TLS) assumes reliable transport while

which clearly assumes characteristics of a transport.
TLS: Assumes unicast, reliable, connection oriented protocol. Infact, to
be precise: TLS means run TCP. Very precise what the transport protocol
is. So you are implicitily making suggestions for one of N transports
that could be used - which is fine.
I am actually indifferent on TLS. If you use multicast you dont have to
use it.

Note: you guys may be right that unicast and TCP is the way to go, but
making a judgement call right now is wrong. Theres a possibility that
you will find out later that you are wrong in assuming that multicast is
not the right sex - therefore ruling it out at this point is a mistake.
I am biased: I believe that whatever solution that comes out will
eventually end up pretending/emulating multicast even if we did unicast.
Why not use multicast as is?

> the other (IPSec) assumes IP only.

Doesnt assume anything about the sex. Ram makes a point about what you
will miss if you use Multicast with ipsec - lets leave that to the
protocol discussion.

> You can argue there is still ground

I am indifferent whether we do say Forces runs directly over ethernet or
not. Arguements i have seen seem to suggest IETF does IP.I think it
would be more valuable to run directly in addition, YMMV.
Hopefully other people will comment.

> discussion on the implication on multicast for both TLS and IPSec. I

Let me guess. Probably showed why it was bad to use multicast with any
of the above. I am glad i never saw the text.

> "must-support" by requirement

I am not sure whether broadcast, multicast or unicast would have made
sense to list in the requirements - so not sure what "must support"
means in this context. These are solution spaces - I am against
exclusionary approach.

>  and security support for multicast is
> general.

Lets see:
RFC2401bis is supposed to resolve multicast issues.
MSEC working group which just shut down just addressed multicast
security issues (ESP, keying etc).I think they are waiting for RFC
status on a lot of their drafts before shutting down completely.
I read Joel to be saying that multicast security is still work in
progress i.e IPSEC initially deployed when multicast was not that widely
used; RFCs - not that many that are published on this topic, and some
areas may still need addressing etc. If the meaning was it was research
as in active networks - then i need to be enlightned.
I am sure that the MSEC folks wouldnt think that their work is
"problematic and shaky" or "research".

Just to be clear:
1) I never questioned the need for security
2) I never recommended for the framework to cover a whole array on all
sorts of secure multicast generalizations. To reiterate: I am against
exlusivity on solution space.

> If you have some specific ideas how we can go about doing that,

I think once you start getting into framework and architecture you are
treading into solution space. So "curent state of the art" is definetely
tainted.

> intend to get it to IESG review soon.

Please do. If you are using Rams text as a base, please review very
closely for objectivity. I think weaknesses on protocols addressing
certain security or scalability issues etc should be left to protocol
discussion time. If theres dependencies here - i suggest we delay this
doc until a protocol is chosen.

cheers,
jamal

---

From: Alex Audu <[email-masked]>
Date: Wed, 6 Aug 2003 09:27:21 -0500

Hi Jamal, Ram and Lily,

I have been following this interesting exchange and I have decided to make
some comments. I can understand Jamal's concern on the implication of
recommending TLS (which sort of implies TCP). I am not sure if TCP is
the best way to go.  What about SCTP?  One could establish a one-to-many
association between a CE and "n" FEs using "n"  SCTP streams. And I believe
TLS is usable with SCTP.

Regards,
Alex.