RE: draft-bonica-tunneltrace-02

[Shahram Davari <Shahram_Davari@pmc-sierra.com>]

Eric,

> -----Original Message-----
> From: Eric Rosen [mailto:erosen@cisco.com]
> Sent: Thursday, February 28, 2002 9:59 AM
> To: Shahram Davari
> Cc: 'Randy Bush'; Cuevas, Enrique G, ALASO; ccamp@ops.ietf.org
> Subject: Re: draft-bonica-tunneltrace-02 
> 
> 
> 
> Shahram> It  has serious  security, complexity,  backward  
> compatibility and
> Shahram> layer violation issues.
> 
> Tom> Can you elaborate on what you think these are? 
> 
> Shahram> Please refer to previous emails by me and David 
> Allan. Most of them
> Shahram> are listed there.  
> 
> I'm sorry, but  as far as I  can tell, those previous mails  
> simply say that
> (a)  the  proposed  solution doesn't  do  some  things  that 
> you  think  are
> valuable,  and (b)  the proposed  solution doesn't  fit well  
> into  some ITU
> architecture.

These issues were raised by Neil, not me and Dave. And they mostly apply to
the GTTP not the requirement draft under discussion. 

> 
> The  second  of  these  points  is  completely  irrelevant.

Why? Simply because it is produced by ITU is not a logical way to dismiss it. Do you think the ITU architecture is wrong and if so why? and what architecture (if any!) do you suggest that the requirements and solutions should fit in to?
   
> The  first  is
> irrelevant too, unless there is a reasonable alternative 
> proposed which does
> more,  or if the  current proposal  doe so  little that  SPs 
> don't  think it
> worthwhile.

Many SPs have this view.

> The MPLS OAM  stuff you've  been pushing  is 
> not  a reasonable
> alternative of  this sort  because (a)  it is MPLS-specific,

This shows that you haven't read the MPLS OAM documents. It has been written with generality in mind and could be applied to any network such as ATM, FR, Ethernet, etc. The reason that it is initially focused on MPLS, is due to immediate need for an OAM tool for MPLS networks. 

  
> and (b)  it is
> already crystal  clear that it will not  be accepted in the  
> IETF.

Thanks to excellent technical justification and no politics!

> And it's
> pretty clear  that a number of SPs  do think that what  the 
> current proposal
> does is worthwhile.

It was also pretty clear that a number of SPs (much larger than the number you are referring to) did think that MPLS OAM proposal is worthwhile. Was it enough to accept it in IETF?

> 
> If  you can actually  cite specific  security issues  with 
> the  proposal, it
> would be valuable to know about them.

Extracted from Dave's emails:

"1) I think a broader discussion of some of the security issues needs to be raised. First by whatever means a trace request needs to be able to be instantiated at a tunnel end 
point. Second, as a result of initiating a trace, any node in the network may be required to generate a response to the tracing application. Therefore the tracing application is required to promiscuously accept responses. A mechanism is required to authoritatively associate responses with requests and discard spurious messages. Further such a mechanism should not be able to be leveraged for denial of service attacks (e.g. spurious trace responses forcing lots of cryptography, defense against replay attacks etc.)."

"Actually the problem breaks down into about 4 things: 

- any host can inject trace requests into the network. 
- if you do not want to share trace information on your network, the only mechanism is to block replies. 
- if you are able to block replies, you are screening initiators (who can be anyone). This implies authentication and replay protection.

- any host can send malicious replies to a tracing agent. 
- you don't want unauthorized folks instructing other network elements to do things, but that is more an requirement of the system design, and not necessarily that of the protocol. "


> 
> Suggestions for reducing complexity would  also be valuable, 
> if you have any
> specific suggestions in that area.
> 
> I don't understand what the backwards compatibility issue is, 
> as there is no
> previous version to be compatible with.

It is not compatible with RFC792 and RFC1122. 

1) RFC792 says: 

"If the gateway processing a datagram finds the time to live field is zero it must discard the datagram"

GTTP draft says:

On TTL expiration forward the GTTP messages to a local GTTP module.

2) RFC1122 says:

"An incoming Time Exceeded message MUST be passed to the transport layer."

GTTP draft says:

"The error-processing module sends an ICMP Time Expired Message to D1. D1 discards this ICMP message."


> 
> If you think there  are layer violation issues, then what you 
>  need to do is
> exhibit the particular set of  specific problems that will 
> arise in practice
> as a result of those violations.

One of the main reasons for avoiding layer violations is to make a protocol future proof. Satisfying or not satisfying current practices is irrelevant.

>If you cannot do this 
> without referencing
> some arcane ITU  architecture document, then the natural  
> conclusion is that
> the  problem  is with  that  architecture's  layering  model, 
> not  with  the
> proposal.

If it is arcane for you, then I guess I can't discuss it with you.

-Shahram

> 
> 
> 
>