[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: draft-ietf-ccamp-gmpls-architecture

ccamp'ers,

after the received iesg comments, a respin of the gmpls
architecture i-d is under submission, the following
changes have been provided:
- grammatical and other editorial changes
- new short paragraph on lmp development (randy's comment)
  as previously proposed on this list
- revisited security section (i'd like to thank here,
  steve and dimitrios for their precious help)

thanks,
- dimitri.

Wijnen, Bert (Bert) wrote:
Steve thanks for the input/review.

Dimitrios and Dimitri, if the two of you could respind the
draft (by Thursday at the latest) to try and address Steves (and other, as posted to the list) comments, then I can
put it back on IESG agenda for next week.

Thanks,
Bert

-----Original Message-----
From: Steven M. Bellovin [mailto:smb@research.att.com]
Sent: dinsdag 22 april 2003 18:31
To: Dimitrios Pendarakis
Cc: 'Wijnen, Bert (Bert)'; Ccamp-wg (E-mail); zinin@psg.com
Subject: Re: draft-ietf-ccamp-gmpls-architecture

In message <05707214338CD5119BFF0040A5B170D30347EEDB@mail3.tellium.com>, Dimitr
ios Pendarakis writes:

Bert,

Comments on the issues brought up by Steve:
i) The risk of attackers being able to inject and/or snoop on (control) traffic depends on both the physical characteristics of the control link and whether the interface is an inter- or intra-domain one. For example, an in-band, in-fiber control channel over SONET/SDH overhead bytes is, in general, considered
less vulnerable than an out-of-band IP network. 
Similarly, however,
most carriers seem to consider control links that are not within their control (intra-domain) less secure.

Proposed resolution: Add statement in the document stressing the
dependency on control link physical characteristics.
And delete the text about intra-domain versus inter-domain -- that's not relevant here.


ii) Difference between authentication and authorization. I believe authorization falls in the category of what is commonly called "policy control". Steve is right about pointing this out, as well
as the implications of appropriate policy controls to increase security and limit the impact of attacks.

Proposed resolution: Expand on the difference, add
references for
policy control (rap WG?) and Steve's comment. I can provide some updated text for this, as well as (i).
I don't think that that's right. The issue is who has the right to, say, allocate or reallocate lambdas between given pairs of switches. Note that there are two very different questions here: how to represent, on the wire, the resources that are available to a given party, and how to make more complex decisions, such as a limit on the total bandwidth available to some party in the presence of contention for certain resources. Simple policies -- "party A, identified by the following mechanism, may request N megabits/sec" are simple. But what about requests for enough different lambdas that a given waveband of the desired capacity is not available?

You can't solve this broader problem here; that's the sort of thing I would like in some follow-on document. But this document needs to sketch the problem in enough detail that implementors are aware of it. (In some sense, the solution doesn't require interoperability. Control elements will receive request and match them against the local security policy. My goal for this document is that the requirement be spelled out clearly enough that people will understand the need.

iii) Need for a (broader) security architecture. Clearly, a 
small section
in the architecture document can not claim to address
all security
issues. I recall that there have been some individual 
draft submissions
in the past regarding security requirements. 
Additionally, other bodies
such as the OIF have carried more work on securing intra-domain interfaces for transport networks; some of that work
could hopefully be
useful in this discussion. While much of the additional 
work involves
using profiles of existing IP security mechanisms in the 
ccamp context,
I can see benefits in terms of pursuing this further,
especially since
it would help alleviate one of the concerns that
carriers considering
deployment of GMPLS or similar solutions have.

Thanks,
Dimitris


-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Wednesday, April 16, 2003 12:38 PM
To: Ccamp-wg (E-mail)
Cc: Steve Bellovin (E-mail)
Subject: FW: draft-ietf-ccamp-gmpls-architecture


Comments on the document from IESG. I think we need an answer
to the serious comment made by Steve

-----Original Message-----
From: Steve Bellovin [mailto:smb@research.att.com]
Sent: woensdag 16 april 2003 18:20
To: iesg-secretary@ietf.org
Cc: iesg@ietf.org
Subject: draft-ietf-ccamp-gmpls-architecture


Nit: section 4 says

Re-using existing IP routing protocols allows for non-PSC 
layers to
take advantages of all the valuable developments that took place
since years for IP routing,

which isn't grammatically correct.

Serious issue:

The Security Considerations section hints at, but doesn't follow
through with, the difference between authentication and 
authorization.
The requirement for cryptographic authentication or encryption
depends on the risk of attackers being able to inject and/or snoop
on traffic. This may or may not be correlated with intra-domain vs.
inter-domain GMPLS. The physical characteristics and exposure of the
link matter more; there may be additional exposure since it 
appears that
the control plane link may be more than one hop long.

The authorization question is what resources a given node may request
of another. This may indeed be differ for inter-domain and 
intra-domain
GMPLS. On the other hand, imposing such limits even internally helps
guard against spreading break-ins, and has useful effects with regard
to configuration errors.

The more important question raised by this latter point is whether or
not a security architecture is needed that specifies what sorts of
restrictions can be applied. I don't know the answer to 
that one; clearly,


though, implementors are going to have to decide.


*************************************************************

*********
This email and any files transmitted with it are 
confidential and intended sol
ely for the use of the individual or entity to whom they are 
addressed. Any re
view, retransmission or other use of this communication by 
any person or entit
y other than the intended recipient is prohibited. If you 
believe that you hav
e received this email in error please notify the sender by 
return electronic m


ail and delete all copies of this communication.
*************************************************************
*********


--Steve Bellovin, http://www.research.att.com/~smb (me)
http://www.wilyhacker.com (2nd edition of "Firewalls" book)





--
Papadimitriou Dimitri
E-mail : dimitri.papadimitriou@alcatel.be
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : dpapadimitriou@psg.com
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491