RE: draft-ietf-ccamp-gmpls-architecture

[Dimitrios Pendarakis <DPendarakis@tellium.com>]

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.

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).

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 solely for the use of the individual or entity to whom they are addressed. Any review, retransmission or other use of this communication by any person or entity other than the intended recipient is prohibited. If you believe that you have received this email in error please notify the sender by return electronic mail and delete all copies of this communication.
**********************************************************************