[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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)
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.
From: Steven M. Bellovin [mailto:email@example.com]
Sent: dinsdag 22 april 2003 18:31
To: Dimitrios Pendarakis
Cc: 'Wijnen, Bert (Bert)'; Ccamp-wg (E-mail); firstname.lastname@example.org
Subject: Re: draft-ietf-ccamp-gmpls-architecture
ios Pendarakis writes:
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.
most carriers seem to consider control links that are not within
their control (intra-domain) less secure.
And delete the text about intra-domain versus inter-domain -- that's
not relevant here.
Proposed resolution: Add statement in the document stressing the
dependency on control link physical characteristics.
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
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.
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
elements will receive request and match them against the
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
in the architecture document can not claim to address
issues. I recall that there have been some individual
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
using profiles of existing IP security mechanisms in the
I can see benefits in terms of pursuing this further,
it would help alleviate one of the concerns that
deployment of GMPLS or similar solutions have.
From: Wijnen, Bert (Bert) [mailto:email@example.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
From: Steve Bellovin [mailto:firstname.lastname@example.org]
Sent: woensdag 16 april 2003 18:20
Nit: section 4 says
Re-using existing IP routing protocols allows for non-PSC
take advantages of all the valuable developments that took place
since years for IP routing,
which isn't grammatically correct.
The Security Considerations section hints at, but doesn't follow
through with, the difference between authentication and
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
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
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
E-mail : email@example.com
E-mail : firstname.lastname@example.org
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone : +32 3 240-8491