[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: draft-ietf-ccamp-gmpls-architecture
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)
>
>