Re: notes from discussion of KARP design guidelines
Replacing a widely used term (on the wire) with term that folks will not understand does not seem to me personally to be a benefit. In terms of this document, I do not see a problem with the usage as it is. This is not a protocol document. The use of the current term in this context seems helpful rather than harmful. Yours, Joel On 7/12/2011 8:26 PM, Joe Touch wrote: On 7/12/2011 3:36 PM, Stewart Bryant wrote: On 12/07/2011 23:23, Joe Touch wrote: Hi, Joel (et al.), On 7/10/2011 7:10 AM, Joel Halpern wrote: Joe, THE KARP WG Chairs have reviewed your comments, in order to figure out what the best way to address them. We would appreciate it if you could engage in discussion of this proposal on the KARP working group email list. If you feel we are still not understanding your point, we would be happy to make some time avaialble for discussion at the WG session in Quebec City. (Comments from anyone else, particularly WG members, on the proposals being made by the WG chairs are appreciated as well.) Rather than a line by line response, we have tried to find the common themes and respond to them. If we have missed major issues, please let us know. You raised concern about the use of the term on-the-wire. Rather than replace the term, we would prefer to add descriptive text early in the document. This text would note that it is a widely used term in IETF documents, including many RFCs. It would also state for clarity that in this document it is used to refer to the message sent from one routing process to another. That's a great example of why this term should be removed. The message sent from one BGP to another is sent *inside* a TCP connection, and nobody would ever call the TCP bytestream payload the message on the wire. This term is simply sloppy, and just as the security community rightly raises issues with similarly poor use of its terms (e.g., random where pseudorandom or arbitrary are intended, or authenticated where integrity protection is intended), I consider this a *significant* transport issue. Joe Please can you suggest a suitable generic term that covers the set of cases that we need to deal with in routing - i.e. over the MAC, over IP, over UDP and over TCP, so that we can discuss inter routing entity message passing as an abstract operation. As Joel says when we get to the detailed design of each routing protocol we will discuss the details, but we want a high level discussion in this document. Note BTW that 186 RFCs use the term on the wire in this sort of situation. I counted nearly 210, when including over the wire too. There are similar misuses of, e.g., security terms, though, so let's not let past errors suggest continued use. That said, let's proceed: First, when you say on the wire do you mean: (A)- the routing protocol data units (RPDUs) (B)- way in which RPDUs are exchanged this includes message payloads, meta-info (header information), and any other info at other layers beyond RPDUs that the routing protocol uses or relies upon I'm presuming the term on the wire is intended to differentiate between (A) and (B). There's no good way to describe (B) as a single entity because it's not one. You basically are differentiating between the message and the means of its communication. The latter is often called a 'channel' in other contexts, so maybe that's the term you want - a way to protect the 'channel'. Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: notes from discussion of KARP design guidelines
Hi, Joel, On 7/13/2011 10:31 AM, Joel M. Halpern wrote: Replacing a widely used term (on the wire) with term that folks will not understand does not seem to me personally to be a benefit. The problem is that on the wire is ambiguous. Many people think they know what it means definitively, but their views vary widely. In terms of this document, I do not see a problem with the usage as it is. This is not a protocol document. The use of the current term in this context seems helpful rather than harmful. Since the whole point of this doc centers around protecting the way messages are exchanged, not the messages themselves (e.g., as would be the case with signed BGP routes), this is a crucial issue to make clear and precise in this doc. Joe On 7/12/2011 8:26 PM, Joe Touch wrote: On 7/12/2011 3:36 PM, Stewart Bryant wrote: On 12/07/2011 23:23, Joe Touch wrote: Hi, Joel (et al.), On 7/10/2011 7:10 AM, Joel Halpern wrote: Joe, THE KARP WG Chairs have reviewed your comments, in order to figure out what the best way to address them. We would appreciate it if you could engage in discussion of this proposal on the KARP working group email list. If you feel we are still not understanding your point, we would be happy to make some time avaialble for discussion at the WG session in Quebec City. (Comments from anyone else, particularly WG members, on the proposals being made by the WG chairs are appreciated as well.) Rather than a line by line response, we have tried to find the common themes and respond to them. If we have missed major issues, please let us know. You raised concern about the use of the term on-the-wire. Rather than replace the term, we would prefer to add descriptive text early in the document. This text would note that it is a widely used term in IETF documents, including many RFCs. It would also state for clarity that in this document it is used to refer to the message sent from one routing process to another. That's a great example of why this term should be removed. The message sent from one BGP to another is sent *inside* a TCP connection, and nobody would ever call the TCP bytestream payload the message on the wire. This term is simply sloppy, and just as the security community rightly raises issues with similarly poor use of its terms (e.g., random where pseudorandom or arbitrary are intended, or authenticated where integrity protection is intended), I consider this a *significant* transport issue. Joe Please can you suggest a suitable generic term that covers the set of cases that we need to deal with in routing - i.e. over the MAC, over IP, over UDP and over TCP, so that we can discuss inter routing entity message passing as an abstract operation. As Joel says when we get to the detailed design of each routing protocol we will discuss the details, but we want a high level discussion in this document. Note BTW that 186 RFCs use the term on the wire in this sort of situation. I counted nearly 210, when including over the wire too. There are similar misuses of, e.g., security terms, though, so let's not let past errors suggest continued use. That said, let's proceed: First, when you say on the wire do you mean: (A)- the routing protocol data units (RPDUs) (B)- way in which RPDUs are exchanged this includes message payloads, meta-info (header information), and any other info at other layers beyond RPDUs that the routing protocol uses or relies upon I'm presuming the term on the wire is intended to differentiate between (A) and (B). There's no good way to describe (B) as a single entity because it's not one. You basically are differentiating between the message and the means of its communication. The latter is often called a 'channel' in other contexts, so maybe that's the term you want - a way to protect the 'channel'. Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: notes from discussion of KARP design guidelines
On 7/13/2011 1:31 PM, Joel M. Halpern wrote: Replacing a widely used term (on the wire) with term that folks will not understand does not seem to me personally to be a benefit. I think Joe's point is that it's widely used as a concept, but what it means specifically in this document is not clear. A sentence to clarify up-front what the definition is in this document might be enough. In terms of this document, I do not see a problem with the usage as it is. This is not a protocol document. The use of the current term in this context seems helpful rather than harmful. It might be reasonable to add a sentence that says, In this document, 'on the wire' refers to (A) the routing protocol data itself, as well as (B) the way in which routing protocol data is exchanged using underlying protocols, including the headers and other meta-data used by those underlying protocols, or something like that? To me, that's a lot more useful than saying this term is commonly used without defining in what sense(s) you mean it in the present document. I think it's important because the protections possible are potentially a lot different, and if you want people to think about only one or both, it should be made explicit. On a lighter note, I once generated a lot of confusion using this term with people working on satellite networks, who were wondering what wires I could possibly be talking about since all of our links were microwave. I guess if KARP covered MANET protocols we'd have to protect them on the wireless. -- Wes Eddy MTI Systems ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: notes from discussion of KARP design guidelines
As I said in my earlier note proposing responses to Joe, we would be happy to some text in the front clarifying the usage. Quoting from my earlier email: This text would note that it is a widely used term in IETF documents, including many RFCs. It would also state for clarity that in this document it is used to refer to the message sent from one routing process to another. Apparently, this does not address Joe's concern. Yours, Joel On 7/13/2011 2:24 PM, Wesley Eddy wrote: On 7/13/2011 1:31 PM, Joel M. Halpern wrote: Replacing a widely used term (on the wire) with term that folks will not understand does not seem to me personally to be a benefit. I think Joe's point is that it's widely used as a concept, but what it means specifically in this document is not clear. A sentence to clarify up-front what the definition is in this document might be enough. ... ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: notes from discussion of KARP design guidelines
On 7/13/2011 2:34 PM, Joel M. Halpern wrote: As I said in my earlier note proposing responses to Joe, we would be happy to some text in the front clarifying the usage. Quoting from my earlier email: This text would note that it is a widely used term in IETF documents, including many RFCs. It would also state for clarity that in this document it is used to refer to the message sent from one routing process to another. Apparently, this does not address Joe's concern. message sent from one routing process to another doesn't seem to be right to me either since it sounds like the first definition that covers routing protocol data only, and not underlying protocols, so I wouldn't expect that proposal to address Joe's concern. -- Wes Eddy MTI Systems ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: notes from discussion of KARP design guidelines
On 7/13/2011 11:34 AM, Joel M. Halpern wrote: As I said in my earlier note proposing responses to Joe, we would be happy to some text in the front clarifying the usage. Quoting from my earlier email: This text would note that it is a widely used term in IETF documents, including many RFCs. It would also state for clarity that in this document it is used to refer to the message sent from one routing process to another. Here's why this is a problem: 1- does this refer to signing a BGP path? 2- does this refer to protecting the channel over which BGP paths are exchanged? From the intro: Four main steps were identified for that tightening: o More secure mechanisms and practices for operating routers. ... o Cleaning up the Internet Routing Registry repository [IRR], ... o Specifications for cryptographic validation of routing message content. ... o Securing the routing protocols' packets on the wire This document addresses the last bullet, securing the packets on the wire of the routing protocol exchanges. So this document is clearly NOT about the message from one routing process to another (that would be 'routing message content', IMO). I.e., this doc focuses on securing the transfer mechanism NOT the message. Thus this is the key to the entirety of the doc. This doc needs to be very clear about what this is, at which point it can certainly also then refer back to the original RFC (e.g., this is referred to in RFC 4948 as 'on the wire'). Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: notes from discussion of KARP design guidelines
Sorry, I apparently missed part of your earlier note. Would text like: This document uses the term on-the-wire to talk about the information used by routing systems. This term is widely used in IETF RFCs,but is used in several different ways. In this document, it is used to refer both to information exchanged between routing protocol instances, and to underlying protocols that may also need to be protected in specific circumstances. Individual protocol analysis documents will need to be more specific in their usage. work to address the issue? Yours, Joel On 7/13/2011 2:47 PM, Wesley Eddy wrote: On 7/13/2011 2:34 PM, Joel M. Halpern wrote: As I said in my earlier note proposing responses to Joe, we would be happy to some text in the front clarifying the usage. Quoting from my earlier email: This text would note that it is a widely used term in IETF documents, including many RFCs. It would also state for clarity that in this document it is used to refer to the message sent from one routing process to another. Apparently, this does not address Joe's concern. message sent from one routing process to another doesn't seem to be right to me either since it sounds like the first definition that covers routing protocol data only, and not underlying protocols, so I wouldn't expect that proposal to address Joe's concern. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: notes from discussion of KARP design guidelines
I don't understand your description of the problem. As you quote, the document clearly states its scope. So, when we then define the term on-the-wire, I don't think we need to restate the scope definition. It woudl seem coutner-productive. Yours, Joel On 7/13/2011 2:58 PM, Joe Touch wrote: On 7/13/2011 11:34 AM, Joel M. Halpern wrote: As I said in my earlier note proposing responses to Joe, we would be happy to some text in the front clarifying the usage. Quoting from my earlier email: This text would note that it is a widely used term in IETF documents, including many RFCs. It would also state for clarity that in this document it is used to refer to the message sent from one routing process to another. Here's why this is a problem: 1- does this refer to signing a BGP path? 2- does this refer to protecting the channel over which BGP paths are exchanged? From the intro: Four main steps were identified for that tightening: o More secure mechanisms and practices for operating routers. ... o Cleaning up the Internet Routing Registry repository [IRR], ... o Specifications for cryptographic validation of routing message content. ... o Securing the routing protocols' packets on the wire This document addresses the last bullet, securing the packets on the wire of the routing protocol exchanges. So this document is clearly NOT about the message from one routing process to another (that would be 'routing message content', IMO). I.e., this doc focuses on securing the transfer mechanism NOT the message. Thus this is the key to the entirety of the doc. This doc needs to be very clear about what this is, at which point it can certainly also then refer back to the original RFC (e.g., this is referred to in RFC 4948 as 'on the wire'). Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: notes from discussion of KARP design guidelines
Hi, Joel, On 7/13/2011 1:44 PM, Joel M. Halpern wrote: Sorry, I apparently missed part of your earlier note. Would text like: This document uses the term on-the-wire to talk about the information used by routing systems. This term is widely used in IETF RFCs,but is used in several different ways. In this document, it is used to refer both to information exchanged between routing protocol instances, and to underlying protocols that may also need to be protected in specific circumstances. I think that is in direct contrast to the current text in the intro, that appears to differentiate between the two and focus on the latter. Joe Individual protocol analysis documents will need to be more specific in their usage. work to address the issue? Yours, Joel On 7/13/2011 2:47 PM, Wesley Eddy wrote: On 7/13/2011 2:34 PM, Joel M. Halpern wrote: As I said in my earlier note proposing responses to Joe, we would be happy to some text in the front clarifying the usage. Quoting from my earlier email: This text would note that it is a widely used term in IETF documents, including many RFCs. It would also state for clarity that in this document it is used to refer to the message sent from one routing process to another. Apparently, this does not address Joe's concern. message sent from one routing process to another doesn't seem to be right to me either since it sounds like the first definition that covers routing protocol data only, and not underlying protocols, so I wouldn't expect that proposal to address Joe's concern. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: notes from discussion of KARP design guidelines
Hi, Joel, On 7/13/2011 1:58 PM, Joel M. Halpern wrote: I don't understand your description of the problem. As you quote, the document clearly states its scope. So, when we then define the term on-the-wire, I don't think we need to restate the scope definition. It woudl seem coutner-productive. The current scope is clear from the bullet list only by the assumption that (a) the bullets are mutually exclusive, and (b) since the routing message content is clear, it cannot be part of on the wire. I.e., it requires the reader interpret scope by a matter of deduction and exclusion, rather than stating it clearly and explicitly. Joe Yours, Joel On 7/13/2011 2:58 PM, Joe Touch wrote: On 7/13/2011 11:34 AM, Joel M. Halpern wrote: As I said in my earlier note proposing responses to Joe, we would be happy to some text in the front clarifying the usage. Quoting from my earlier email: This text would note that it is a widely used term in IETF documents, including many RFCs. It would also state for clarity that in this document it is used to refer to the message sent from one routing process to another. Here's why this is a problem: 1- does this refer to signing a BGP path? 2- does this refer to protecting the channel over which BGP paths are exchanged? From the intro: Four main steps were identified for that tightening: o More secure mechanisms and practices for operating routers. ... o Cleaning up the Internet Routing Registry repository [IRR], ... o Specifications for cryptographic validation of routing message content. ... o Securing the routing protocols' packets on the wire This document addresses the last bullet, securing the packets on the wire of the routing protocol exchanges. So this document is clearly NOT about the message from one routing process to another (that would be 'routing message content', IMO). I.e., this doc focuses on securing the transfer mechanism NOT the message. Thus this is the key to the entirety of the doc. This doc needs to be very clear about what this is, at which point it can certainly also then refer back to the original RFC (e.g., this is referred to in RFC 4948 as 'on the wire'). Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: notes from discussion of KARP design guidelines
You wording seems to induce confusion. Of course the routing message content is part of the message on-the-wire. It is the content of the message. It is in fact a significant part of what is being protected. What is NOT part of the scope, and which the text says is not part of the scope, is the validation of that information. KARP is not assuring that the information is valid. it is responsible to ensure that the message is not modified between the two peers. Yes, this means that there is an overlap in protection between validation information and packet authentication information. So? The scope is very clear as to whose problem is whose. (This is merely a statement of fact. If we have path signing and TCP-AO, there are two sets of mechanisms preventing modification of some of the BGP information.) The text after the bullet list explicitly says what part is in scope. it does not require any assumption or inference. If there is specific wording you would like to suggest to improve the introductory scoping material, I would be happy to look at it. Yours, Joel On 7/13/2011 5:08 PM, Joe Touch wrote: Hi, Joel, On 7/13/2011 1:58 PM, Joel M. Halpern wrote: I don't understand your description of the problem. As you quote, the document clearly states its scope. So, when we then define the term on-the-wire, I don't think we need to restate the scope definition. It woudl seem coutner-productive. The current scope is clear from the bullet list only by the assumption that (a) the bullets are mutually exclusive, and (b) since the routing message content is clear, it cannot be part of on the wire. I.e., it requires the reader interpret scope by a matter of deduction and exclusion, rather than stating it clearly and explicitly. Joe Yours, Joel On 7/13/2011 2:58 PM, Joe Touch wrote: On 7/13/2011 11:34 AM, Joel M. Halpern wrote: As I said in my earlier note proposing responses to Joe, we would be happy to some text in the front clarifying the usage. Quoting from my earlier email: This text would note that it is a widely used term in IETF documents, including many RFCs. It would also state for clarity that in this document it is used to refer to the message sent from one routing process to another. Here's why this is a problem: 1- does this refer to signing a BGP path? 2- does this refer to protecting the channel over which BGP paths are exchanged? From the intro: Four main steps were identified for that tightening: o More secure mechanisms and practices for operating routers. ... o Cleaning up the Internet Routing Registry repository [IRR], ... o Specifications for cryptographic validation of routing message content. ... o Securing the routing protocols' packets on the wire This document addresses the last bullet, securing the packets on the wire of the routing protocol exchanges. So this document is clearly NOT about the message from one routing process to another (that would be 'routing message content', IMO). I.e., this doc focuses on securing the transfer mechanism NOT the message. Thus this is the key to the entirety of the doc. This doc needs to be very clear about what this is, at which point it can certainly also then refer back to the original RFC (e.g., this is referred to in RFC 4948 as 'on the wire'). Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: notes from discussion of KARP design guidelines
Hi, Joel, On 7/13/2011 2:26 PM, Joel M. Halpern wrote: You wording seems to induce confusion. Of course the routing message content is part of the message on-the-wire. It is the content of the message. It is in fact a significant part of what is being protected. What is NOT part of the scope, and which the text says is not part of the scope, is the validation of that information. KARP is not assuring that the information is valid. it is responsible to ensure that the message is not modified between the two peers. Yes, this means that there is an overlap in protection between validation information and packet authentication information.So? The scope is very clear as to whose problem is whose. That makes absolutely no sense. If there's overlap, then it's obviously unclear as to whose problem is whose. (This is merely a statement of fact. If we have path signing and TCP-AO, there are two sets of mechanisms preventing modification of some of the BGP information.) I appreciate that different layers can include redundant protections. However, I'm trying to understand what is *expected* from each layer. The text after the bullet list explicitly says what part is in scope. it does not require any assumption or inference. If there is specific wording you would like to suggest to improve the introductory scoping material, I would be happy to look at it. Glad to, with a bit more context. Can you please define what is being validated in the third bullet that is NOT protected by the last one or vice versa? AFAICT, it would be: #3 is entirely responsible for ensuring that a source has permission to advertise a particular route #3 or #4 could confirm the identity of the source of a piece of information (#3 is required if transitive, #4 works only if directly communicated). #3 or #4 could confirm the integrity of such information #4 is required to protect the properties of lower layers insofar as they are used as such information to the routing protocol (e.g., BGP tossing out routes because TCP connections fail). If this is the case, then I understand 4 as protecting the *channel* over which routing messages are exchanged (which ends up protecting the messages too), and 3 as focusing on the routing layer messages themselves. Is that the case? Joe On 7/13/2011 5:08 PM, Joe Touch wrote: Hi, Joel, On 7/13/2011 1:58 PM, Joel M. Halpern wrote: I don't understand your description of the problem. As you quote, the document clearly states its scope. So, when we then define the term on-the-wire, I don't think we need to restate the scope definition. It woudl seem coutner-productive. The current scope is clear from the bullet list only by the assumption that (a) the bullets are mutually exclusive, and (b) since the routing message content is clear, it cannot be part of on the wire. I.e., it requires the reader interpret scope by a matter of deduction and exclusion, rather than stating it clearly and explicitly. Joe Yours, Joel On 7/13/2011 2:58 PM, Joe Touch wrote: On 7/13/2011 11:34 AM, Joel M. Halpern wrote: As I said in my earlier note proposing responses to Joe, we would be happy to some text in the front clarifying the usage. Quoting from my earlier email: This text would note that it is a widely used term in IETF documents, including many RFCs. It would also state for clarity that in this document it is used to refer to the message sent from one routing process to another. Here's why this is a problem: 1- does this refer to signing a BGP path? 2- does this refer to protecting the channel over which BGP paths are exchanged? From the intro: Four main steps were identified for that tightening: o More secure mechanisms and practices for operating routers. ... o Cleaning up the Internet Routing Registry repository [IRR], ... o Specifications for cryptographic validation of routing message content. ... o Securing the routing protocols' packets on the wire This document addresses the last bullet, securing the packets on the wire of the routing protocol exchanges. So this document is clearly NOT about the message from one routing process to another (that would be 'routing message content', IMO). I.e., this doc focuses on securing the transfer mechanism NOT the message. Thus this is the key to the entirety of the doc. This doc needs to be very clear about what this is, at which point it can certainly also then refer back to the original RFC (e.g., this is referred to in RFC 4948 as 'on the wire'). Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: notes from discussion of KARP design guidelines
I am not sure what you are asking. KARP is never concerned with whether the party is authorized to send the information it is sending. KARP is concerned with assuring that the information received is either the information sent, or recognizably NOT the information sent (so it can be discarded.) (I would have said that more simply, but I have been beat up by security folks for descriing what authentication does too simply.) It is also concerned that the receiver be able to correctly tell who sent the message, or discard the message. (Which layer those determinations are made at varies across the protocols, and is something we were trying not to get detailed about in the design guidelines document.) Sent and received refer to inforamtion being exchanged between directly communicating IP routers. (Of course, directly depends upon the protocol and configuration, as both targetted LDP and remote BGP the two parties are directly communicating through other routers.) This document is NOT supposed to be the framework document for the KARP work. The working group did not have enough energy to produce that, and I would therefore not want to turn this into a full-blown framework document. With that understanding, if there is an extra paragraph that will help the introduction be clear about this, please send text. Yours, Joel On 7/13/2011 7:02 PM, Joe Touch wrote: Hi, Joel, On 7/13/2011 2:26 PM, Joel M. Halpern wrote: You wording seems to induce confusion. Of course the routing message content is part of the message on-the-wire. It is the content of the message. It is in fact a significant part of what is being protected. What is NOT part of the scope, and which the text says is not part of the scope, is the validation of that information. KARP is not assuring that the information is valid. it is responsible to ensure that the message is not modified between the two peers. Yes, this means that there is an overlap in protection between validation information and packet authentication information.So? The scope is very clear as to whose problem is whose. That makes absolutely no sense. If there's overlap, then it's obviously unclear as to whose problem is whose. (This is merely a statement of fact. If we have path signing and TCP-AO, there are two sets of mechanisms preventing modification of some of the BGP information.) I appreciate that different layers can include redundant protections. However, I'm trying to understand what is *expected* from each layer. The text after the bullet list explicitly says what part is in scope. it does not require any assumption or inference. If there is specific wording you would like to suggest to improve the introductory scoping material, I would be happy to look at it. Glad to, with a bit more context. Can you please define what is being validated in the third bullet that is NOT protected by the last one or vice versa? AFAICT, it would be: #3 is entirely responsible for ensuring that a source has permission to advertise a particular route #3 or #4 could confirm the identity of the source of a piece of information (#3 is required if transitive, #4 works only if directly communicated). #3 or #4 could confirm the integrity of such information #4 is required to protect the properties of lower layers insofar as they are used as such information to the routing protocol (e.g., BGP tossing out routes because TCP connections fail). If this is the case, then I understand 4 as protecting the *channel* over which routing messages are exchanged (which ends up protecting the messages too), and 3 as focusing on the routing layer messages themselves. Is that the case? Joe On 7/13/2011 5:08 PM, Joe Touch wrote: Hi, Joel, On 7/13/2011 1:58 PM, Joel M. Halpern wrote: I don't understand your description of the problem. As you quote, the document clearly states its scope. So, when we then define the term on-the-wire, I don't think we need to restate the scope definition. It woudl seem coutner-productive. The current scope is clear from the bullet list only by the assumption that (a) the bullets are mutually exclusive, and (b) since the routing message content is clear, it cannot be part of on the wire. I.e., it requires the reader interpret scope by a matter of deduction and exclusion, rather than stating it clearly and explicitly. Joe Yours, Joel On 7/13/2011 2:58 PM, Joe Touch wrote: On 7/13/2011 11:34 AM, Joel M. Halpern wrote: As I said in my earlier note proposing responses to Joe, we would be happy to some text in the front clarifying the usage. Quoting from my earlier email: This text would note that it is a widely used term in IETF documents, including many RFCs. It would also state for clarity that in this document it is used to refer to the message sent from one routing process to another. Here's why this is a problem: 1- does this refer to signing a BGP path? 2- does this refer to protecting the channel over which
Re: notes from discussion of KARP design guidelines
Hi, Joel, On 7/13/2011 4:24 PM, Joel M. Halpern wrote: I am not sure what you are asking. KARP is never concerned with whether the party is authorized to send the information it is sending. Right - that's bullet 3. KARP is concerned with assuring that the information received is either the information sent, or recognizably NOT the information sent (so it can be discarded.) (I would have said that more simply, but I have been beat up by security folks for describing what authentication does too simply.) It is also concerned that the receiver be able to correctly tell who sent the message, or discard the message. (Which layer those determinations are made at varies across the protocols, and is something we were trying not to get detailed about in the design guidelines document.) Sent and received refer to inforamtion being exchanged between directly communicating IP routers. (Of course, directly depends upon the protocol and configuration, as both targetted LDP and remote BGP the two parties are directly communicating through other routers.) OK - so that's protecting the information exchanged between two routers. I would argue that it also presumes protecting such information whether it's explicit at the routing layer (e.g., BGP path messages), other headers (e.g., src/dst addrs, TTLs, and the like, if relied upon by the routing protocol), and the semantics of other layers of protocols (e.g., whether a connection remains up, as with TCP or PPTP). This document is NOT supposed to be the framework document for the KARP work. The working group did not have enough energy to produce that, and I would therefore not want to turn this into a full-blown framework document. With that understanding, if there is an extra paragraph that will help the introduction be clear about this, please send text. If we agree on the above, then I can proceed to document suggested changes and the paragraph. Joe Yours, Joel On 7/13/2011 7:02 PM, Joe Touch wrote: Hi, Joel, On 7/13/2011 2:26 PM, Joel M. Halpern wrote: You wording seems to induce confusion. Of course the routing message content is part of the message on-the-wire. It is the content of the message. It is in fact a significant part of what is being protected. What is NOT part of the scope, and which the text says is not part of the scope, is the validation of that information. KARP is not assuring that the information is valid. it is responsible to ensure that the message is not modified between the two peers. Yes, this means that there is an overlap in protection between validation information and packet authentication information.So? The scope is very clear as to whose problem is whose. That makes absolutely no sense. If there's overlap, then it's obviously unclear as to whose problem is whose. (This is merely a statement of fact. If we have path signing and TCP-AO, there are two sets of mechanisms preventing modification of some of the BGP information.) I appreciate that different layers can include redundant protections. However, I'm trying to understand what is *expected* from each layer. The text after the bullet list explicitly says what part is in scope. it does not require any assumption or inference. If there is specific wording you would like to suggest to improve the introductory scoping material, I would be happy to look at it. Glad to, with a bit more context. Can you please define what is being validated in the third bullet that is NOT protected by the last one or vice versa? AFAICT, it would be: #3 is entirely responsible for ensuring that a source has permission to advertise a particular route #3 or #4 could confirm the identity of the source of a piece of information (#3 is required if transitive, #4 works only if directly communicated). #3 or #4 could confirm the integrity of such information #4 is required to protect the properties of lower layers insofar as they are used as such information to the routing protocol (e.g., BGP tossing out routes because TCP connections fail). If this is the case, then I understand 4 as protecting the *channel* over which routing messages are exchanged (which ends up protecting the messages too), and 3 as focusing on the routing layer messages themselves. Is that the case? Joe On 7/13/2011 5:08 PM, Joe Touch wrote: Hi, Joel, On 7/13/2011 1:58 PM, Joel M. Halpern wrote: I don't understand your description of the problem. As you quote, the document clearly states its scope. So, when we then define the term on-the-wire, I don't think we need to restate the scope definition. It woudl seem coutner-productive. The current scope is clear from the bullet list only by the assumption that (a) the bullets are mutually exclusive, and (b) since the routing message content is clear, it cannot be part of on the wire. I.e., it requires the reader interpret scope by a matter of deduction and exclusion, rather than stating it clearly and explicitly. Joe Yours, Joel On
Re: notes from discussion of KARP design guidelines
I am not sure we are in sync, but it looks clsoe enough that proposed introductory text would be veyr helpful at this point. Yours, Joel On 7/13/2011 7:59 PM, Joe Touch wrote: Hi, Joel, On 7/13/2011 4:24 PM, Joel M. Halpern wrote: I am not sure what you are asking. KARP is never concerned with whether the party is authorized to send the information it is sending. Right - that's bullet 3. KARP is concerned with assuring that the information received is either the information sent, or recognizably NOT the information sent (so it can be discarded.) (I would have said that more simply, but I have been beat up by security folks for describing what authentication does too simply.) It is also concerned that the receiver be able to correctly tell who sent the message, or discard the message. (Which layer those determinations are made at varies across the protocols, and is something we were trying not to get detailed about in the design guidelines document.) Sent and received refer to inforamtion being exchanged between directly communicating IP routers. (Of course, directly depends upon the protocol and configuration, as both targetted LDP and remote BGP the two parties are directly communicating through other routers.) OK - so that's protecting the information exchanged between two routers. I would argue that it also presumes protecting such information whether it's explicit at the routing layer (e.g., BGP path messages), other headers (e.g., src/dst addrs, TTLs, and the like, if relied upon by the routing protocol), and the semantics of other layers of protocols (e.g., whether a connection remains up, as with TCP or PPTP). This document is NOT supposed to be the framework document for the KARP work. The working group did not have enough energy to produce that, and I would therefore not want to turn this into a full-blown framework document. With that understanding, if there is an extra paragraph that will help the introduction be clear about this, please send text. If we agree on the above, then I can proceed to document suggested changes and the paragraph. Joe Yours, Joel On 7/13/2011 7:02 PM, Joe Touch wrote: Hi, Joel, On 7/13/2011 2:26 PM, Joel M. Halpern wrote: You wording seems to induce confusion. Of course the routing message content is part of the message on-the-wire. It is the content of the message. It is in fact a significant part of what is being protected. What is NOT part of the scope, and which the text says is not part of the scope, is the validation of that information. KARP is not assuring that the information is valid. it is responsible to ensure that the message is not modified between the two peers. Yes, this means that there is an overlap in protection between validation information and packet authentication information.So? The scope is very clear as to whose problem is whose. That makes absolutely no sense. If there's overlap, then it's obviously unclear as to whose problem is whose. (This is merely a statement of fact. If we have path signing and TCP-AO, there are two sets of mechanisms preventing modification of some of the BGP information.) I appreciate that different layers can include redundant protections. However, I'm trying to understand what is *expected* from each layer. The text after the bullet list explicitly says what part is in scope. it does not require any assumption or inference. If there is specific wording you would like to suggest to improve the introductory scoping material, I would be happy to look at it. Glad to, with a bit more context. Can you please define what is being validated in the third bullet that is NOT protected by the last one or vice versa? AFAICT, it would be: #3 is entirely responsible for ensuring that a source has permission to advertise a particular route #3 or #4 could confirm the identity of the source of a piece of information (#3 is required if transitive, #4 works only if directly communicated). #3 or #4 could confirm the integrity of such information #4 is required to protect the properties of lower layers insofar as they are used as such information to the routing protocol (e.g., BGP tossing out routes because TCP connections fail). If this is the case, then I understand 4 as protecting the *channel* over which routing messages are exchanged (which ends up protecting the messages too), and 3 as focusing on the routing layer messages themselves. Is that the case? Joe On 7/13/2011 5:08 PM, Joe Touch wrote: Hi, Joel, On 7/13/2011 1:58 PM, Joel M. Halpern wrote: I don't understand your description of the problem. As you quote, the document clearly states its scope. So, when we then define the term on-the-wire, I don't think we need to restate the scope definition. It woudl seem coutner-productive. The current scope is clear from the bullet list only by the assumption that (a) the bullets are mutually exclusive, and (b) since the routing message content is clear, it cannot be part of on
Re: notes from discussion of KARP design guidelines
Hi, Joel (et al.), On 7/10/2011 7:10 AM, Joel Halpern wrote: Joe, THE KARP WG Chairs have reviewed your comments, in order to figure out what the best way to address them. We would appreciate it if you could engage in discussion of this proposal on the KARP working group email list. If you feel we are still not understanding your point, we would be happy to make some time avaialble for discussion at the WG session in Quebec City. (Comments from anyone else, particularly WG members, on the proposals being made by the WG chairs are appreciated as well.) Rather than a line by line response, we have tried to find the common themes and respond to them. If we have missed major issues, please let us know. You raised concern about the use of the term on-the-wire. Rather than replace the term, we would prefer to add descriptive text early in the document. This text would note that it is a widely used term in IETF documents, including many RFCs. It would also state for clarity that in this document it is used to refer to the message sent from one routing process to another. That's a great example of why this term should be removed. The message sent from one BGP to another is sent *inside* a TCP connection, and nobody would ever call the TCP bytestream payload the message on the wire. This term is simply sloppy, and just as the security community rightly raises issues with similarly poor use of its terms (e.g., random where pseudorandom or arbitrary are intended, or authenticated where integrity protection is intended), I consider this a *significant* transport issue. With regard to your comment about identifiers, we can add in the description of protocol reviews indications that such reviews should be clear about what IDs the review considers need protecting, as that is important context for the protocol review. OK. As noted in other exchanges, the document abstract needs a complete rewrite. It should be just an abstract, with the rest of the context either removed or moved to the introduction. In doing so, we will add text describing briefly the general concept of the routing protocol transport. OK. In general however, protocol specific behaviors are to be left to the protocol analysis documents. Equally, descriptions of detailed threats will be left either to the threat document or to the individual protocol analysis document as appropriate. My goal is to make some transport properties as notable and discussed in as much (or as little) detail as, e.g., multicast and unicast already are in the current document. There are several items in your comments indicating that you would like to see more discussion in the design guidelines of the protocol layering. That does not seem to be a useful addition to this document. Again, individual protocol analysis documents will deal with that where it is appropriate, and avoid it where it is a distraction. We do not see useful general statements of guidance that can be put into this document. As noted above, this is already in the document w.r.t. multicast/unicast; I'm suggesting that it's equally appropriate to include similar discussion of the issues of other layers on routing protocol security. Adding some general text in the discussion of communication modes elaborating on the difference between the communication as seen by the routing and security components, and the actual communication (e.g. that what is seen as multicast may be delivered as broadcast or multiple uni-cast) does seem a helpful addition to the document, and we will do that. I'm not sure if this is basically all I'm asking for; see above. The intent was to add discussion of some known transport issues that are as relevant as the multicast/unicast difference already discussed, in similar detail. Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: notes from discussion of KARP design guidelines
On 12/07/2011 23:23, Joe Touch wrote: Hi, Joel (et al.), On 7/10/2011 7:10 AM, Joel Halpern wrote: Joe, THE KARP WG Chairs have reviewed your comments, in order to figure out what the best way to address them. We would appreciate it if you could engage in discussion of this proposal on the KARP working group email list. If you feel we are still not understanding your point, we would be happy to make some time avaialble for discussion at the WG session in Quebec City. (Comments from anyone else, particularly WG members, on the proposals being made by the WG chairs are appreciated as well.) Rather than a line by line response, we have tried to find the common themes and respond to them. If we have missed major issues, please let us know. You raised concern about the use of the term on-the-wire. Rather than replace the term, we would prefer to add descriptive text early in the document. This text would note that it is a widely used term in IETF documents, including many RFCs. It would also state for clarity that in this document it is used to refer to the message sent from one routing process to another. That's a great example of why this term should be removed. The message sent from one BGP to another is sent *inside* a TCP connection, and nobody would ever call the TCP bytestream payload the message on the wire. This term is simply sloppy, and just as the security community rightly raises issues with similarly poor use of its terms (e.g., random where pseudorandom or arbitrary are intended, or authenticated where integrity protection is intended), I consider this a *significant* transport issue. Joe Please can you suggest a suitable generic term that covers the set of cases that we need to deal with in routing - i.e. over the MAC, over IP, over UDP and over TCP, so that we can discuss inter routing entity message passing as an abstract operation. As Joel says when we get to the detailed design of each routing protocol we will discuss the details, but we want a high level discussion in this document. Note BTW that 186 RFCs use the term on the wire in this sort of situation. - Stewart With regard to your comment about identifiers, we can add in the description of protocol reviews indications that such reviews should be clear about what IDs the review considers need protecting, as that is important context for the protocol review. OK. As noted in other exchanges, the document abstract needs a complete rewrite. It should be just an abstract, with the rest of the context either removed or moved to the introduction. In doing so, we will add text describing briefly the general concept of the routing protocol transport. OK. In general however, protocol specific behaviors are to be left to the protocol analysis documents. Equally, descriptions of detailed threats will be left either to the threat document or to the individual protocol analysis document as appropriate. My goal is to make some transport properties as notable and discussed in as much (or as little) detail as, e.g., multicast and unicast already are in the current document. There are several items in your comments indicating that you would like to see more discussion in the design guidelines of the protocol layering. That does not seem to be a useful addition to this document. Again, individual protocol analysis documents will deal with that where it is appropriate, and avoid it where it is a distraction. We do not see useful general statements of guidance that can be put into this document. As noted above, this is already in the document w.r.t. multicast/unicast; I'm suggesting that it's equally appropriate to include similar discussion of the issues of other layers on routing protocol security. Adding some general text in the discussion of communication modes elaborating on the difference between the communication as seen by the routing and security components, and the actual communication (e.g. that what is seen as multicast may be delivered as broadcast or multiple uni-cast) does seem a helpful addition to the document, and we will do that. I'm not sure if this is basically all I'm asking for; see above. The intent was to add discussion of some known transport issues that are as relevant as the multicast/unicast difference already discussed, in similar detail. Joe -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: notes from discussion of KARP design guidelines
On 7/12/2011 3:36 PM, Stewart Bryant wrote: On 12/07/2011 23:23, Joe Touch wrote: Hi, Joel (et al.), On 7/10/2011 7:10 AM, Joel Halpern wrote: Joe, THE KARP WG Chairs have reviewed your comments, in order to figure out what the best way to address them. We would appreciate it if you could engage in discussion of this proposal on the KARP working group email list. If you feel we are still not understanding your point, we would be happy to make some time avaialble for discussion at the WG session in Quebec City. (Comments from anyone else, particularly WG members, on the proposals being made by the WG chairs are appreciated as well.) Rather than a line by line response, we have tried to find the common themes and respond to them. If we have missed major issues, please let us know. You raised concern about the use of the term on-the-wire. Rather than replace the term, we would prefer to add descriptive text early in the document. This text would note that it is a widely used term in IETF documents, including many RFCs. It would also state for clarity that in this document it is used to refer to the message sent from one routing process to another. That's a great example of why this term should be removed. The message sent from one BGP to another is sent *inside* a TCP connection, and nobody would ever call the TCP bytestream payload the message on the wire. This term is simply sloppy, and just as the security community rightly raises issues with similarly poor use of its terms (e.g., random where pseudorandom or arbitrary are intended, or authenticated where integrity protection is intended), I consider this a *significant* transport issue. Joe Please can you suggest a suitable generic term that covers the set of cases that we need to deal with in routing - i.e. over the MAC, over IP, over UDP and over TCP, so that we can discuss inter routing entity message passing as an abstract operation. As Joel says when we get to the detailed design of each routing protocol we will discuss the details, but we want a high level discussion in this document. Note BTW that 186 RFCs use the term on the wire in this sort of situation. I counted nearly 210, when including over the wire too. There are similar misuses of, e.g., security terms, though, so let's not let past errors suggest continued use. That said, let's proceed: First, when you say on the wire do you mean: (A)- the routing protocol data units (RPDUs) (B)- way in which RPDUs are exchanged this includes message payloads, meta-info (header information), and any other info at other layers beyond RPDUs that the routing protocol uses or relies upon I'm presuming the term on the wire is intended to differentiate between (A) and (B). There's no good way to describe (B) as a single entity because it's not one. You basically are differentiating between the message and the means of its communication. The latter is often called a 'channel' in other contexts, so maybe that's the term you want - a way to protect the 'channel'. Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: notes from discussion of KARP design guidelines
Joe, THE KARP WG Chairs have reviewed your comments, in order to figure out what the best way to address them. We would appreciate it if you could engage in discussion of this proposal on the KARP working group email list. If you feel we are still not understanding your point, we would be happy to make some time avaialble for discussion at the WG session in Quebec City. (Comments from anyone else, particularly WG members, on the proposals being made by the WG chairs are appreciated as well.) Rather than a line by line response, we have tried to find the common themes and respond to them. If we have missed major issues, please let us know. You raised concern about the use of the term on-the-wire. Rather than replace the term, we would prefer to add descriptive text early in the document. This text would note that it is a widely used term in IETF documents, including many RFCs. It would also state for clarity that in this document it is used to refer to the message sent from one routing process to another. With regard to your comment about identifiers, we can add in the description of protocol reviews indications that such reviews should be clear about what IDs the review considers need protecting, as that is important context for the protocol review. As noted in other exchanges, the document abstract needs a complete rewrite. It should be just an abstract, with the rest of the context either removed or moved to the introduction. In doing so, we will add text describing briefly the general concept of the routing protocol transport. In general however, protocol specific behaviors are to be left to the protocol analysis documents. Equally, descriptions of detailed threats will be left either to the threat document or to the individual protocol analysis document as appropriate. There are several items in your comments indicating that you would like to see more discussion in the design guidelines of the protocol layering. That does not seem to be a useful addition to this document. Again, individual protocol analysis documents will deal with that where it is appropriate, and avoid it where it is a distraction. We do not see useful general statements of guidance that can be put into this document. Adding some general text in the discussion of communication modes elaborating on the difference between the communication as seen by the routing and security components, and the actual communication (e.g. that what is seen as multicast may be delivered as broadcast or multiple uni-cast) does seem a helpful addition to the document, and we will do that. Yours, Joel and Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
