RE: Palladium (TCP/MS)
On 10/22/02, Franck Martin wrote: >"Here is my preferred solution for Internet security. We >could implement a secure user identity system precisely >like telephone Caller ID. It would be essentially an >Internet ID. All Internet transactions could be based on >it. Anyone who sends me e-mail can be identified. Anything >I send can be traced to me. People wouldn't be forced to >participate, but if they remain anonymous, I might choose >to block them. I certainly wouldn't accept file >attachments from them. I know you hate this idea, but I >think the Internet needs a fingerprint. It does not have >to have personal information, but if you break the law it >can be traced to you. You can choose not to have a >fingerprint, but then your ability to communicate with >others may be limited -- a price many people may choose to >pay. " > > If posting this comment on this thread is supposed to imply that this is an alternative to Palladium, then I would strongly suggest actually going and reading some of the Palladium material. Palladium is ultimately about creating a lockbox for key data within a system. It really implies almost nothing about system to system interaction -- it has more to do with how a distributed application can avoid trusting the OS to store data and keys. Which is an admirable goal. I'll have to see the details. I have some skepticism about how you prevent the OS, which is the local traffic cop, from pulling off a man-in-the-middle attack. You can also make the obvious cheap jokes about Microsoft leading the way to solve problems of applications developers that do not trust the Operating System... But seriously, there are two types of Operating Systems that distributed applications should not trust: those where you cannot review the source code, and those where any attacker can modify the source code. A lot of this thread has struck me as an attempt to import the Bush/Cheney foreign policy to the IETF. Microsoft is evil, therefore everything Microsoft does is evil. Any statements they make are just part of their evil plan. We might as well launch the pre-emptive strike right now. It would make more sense to examine whether any aspect of this problem is a proper topic for the IETF, and where our concerns about interoperability would be. For example, Microsoft's position papers claim that alternate Nexus implementations will be legal. Will users be able to enable different Nexus implementations to interoperate and share keys for sealed storage? Caitlin Bestler http://asomi.com/CaitlinBestler/
Re: Re[2]: Last Call: Using XML-RPC in BEEP to Proposed Standard
On 10/11/02, Ward Harold wrote: > >As John says XML-RPC actually predates SOAP. It's also >simpler and thus easier to implement but SOAP has better >support for handling complex types. Ultimately you have to >choose the one that best meets your application >requirements. > > p.s. RFC 3288 describes how to use SOAP over BEEP For systems that have to support SOAP *anyway*, XML-RPC would be an additional feature to implement. If a developer already has a SOAP implementation available, are there any justifications for using XML-RPC? - Reduced code space? - Shorter messages to accomplish the same calls? - More robust handling of any conditions? I'm not throwing these out as rhetorical questions. These are just the types of justifications I would want for maintaining two options, rather than settling on one. A quick google scan for justifications mostly came up with arguments on why XML-RPC would be better *instead of* SOAP. Are there valid arguments on why it is a valuable tool *in addition to* SOAP? Caitlin Bestler http://asomi.com/CaitlinBestler/
Re: Datagram? Packet? (was : APEX)
On 9/26/02, Lloyd Wood wrote: >On Thu, 26 Sep 2002, Caitlin Bestler wrote: > >> >> So, as originally proposed an IP fragment is a fully >> self-routed L3 datagram. > >well, not self-routed; you need routing state. I don't >think the difference between routing table state and >circuit-switched state is all that great; anything beyond >hot-potato is fundamentally stateful. > Given the source interface, the *meaning* of an IP header is not supposed to be dependent on the routing tables. The routing tables merely implement that meaning. By contrast, the meaning of an ATM circuit is dependent on the context in which it was established. There is no expectation that there is any meaning to this circuit identifier beyond those imparted when the circuit was created. I would maintain that all the IP exceptions that leap to mind, such as NATs and load-balancing switches, do not actually violate this. The intended destination is merely a virtual host. In any event, regardless of similarities in execution, the difference in intended semantics is valid and fundamental. Caitlin Bestler http://asomi.com/CaitlinBestler/
Re: Datagram? Packet? (was : APEX)
On 9/26/02, Lloyd Wood wrote: >On Wed, 25 Sep 2002, Fred Baker wrote: > >> At 01:12 PM 9/25/2002 +0100, Lloyd Wood wrote: >> >A datagram is self-describing; full source and >> >destination. A fragment (IPv4 fragment) may not be. >> >> you sure? take a GOOD look at RFC 791... It is >> completely self-describing in terms of getting itself >> there and where it belongs in the reassembled datagram. >> If the other bits and pieces don't arrive, there is >> another matter, but it is at that point a host issue, >> not a forwarding issue. > >I'm not sure that following fragments relying on a bit in >another fragment saying 'following fragment' is truly >self-describing. > >(Not having port nos in following fragments would only be >a host issue if routers and firewalls never peeked at >ports en route.) > So, as originally proposed an IP fragment is a fully self-routed L3 datagram. However, in the de facto world of merged L3/L4 routing (with NATs, load balancers, etc.) it is dependent on state information and hence is not a datagram. However, the term was applied before L3/L4 "routing" came into existence. So the term 'datagram' was correct. And of course nobody would change the term ex post facto. This is why these terms are indeed fluid and nebulous.
Re: how to take minutes
On 7/23/02, Randy Presuhn wrote: > >While these "blow by blow" accounts give the appearance of >great detail, I think they are seldom sufficiently >accurate or complete enough to support using them to >discern "motivations and other nuances." YMMV. > >A few years ago the minute taker for one WG session >literally tape-recorded the meeting and transcribed it >verbatim. Valiant, but I'm not sure it was actually >helpful. Even with the transcript and having been there >in person, I'm still blissfully ignorant of the >motivations behind some of the positions taken. > >I'd be happy with accurate lists of topics/issues >discussed, agreements reached among those present, and >action items assigned. More isn't necessarily better. > I also tend to dislike "blow by blow" accounts, especially if they become virtual transcripts of the session. Recording someone's spontaneous wording in minutes that will be saved, and be searchable, for years to come strikes me as inappropriate. It will certainly chill spontaneous discussion. On the flip side, presenting only the conclusions is inadequate. The minutes should reflect all positions discussed. It is important that there be a record of alternatives that were considered, not just the option selected.
Re: ARPOP_REQUEST with spoofed IP address (joe, turn it off!)
On 7/23/02, Vernon Schryver wrote: >> From: Lars Eggert <[EMAIL PROTECTED]> > >> > How does one tell, in principle, that the source IP >> > address (ar$spa) in an ARP packet is in fact spoofed? >> >> Not without cryptographic authentication, in general. >> >> But for this particular issue, not updating the local >> cache based on snooped ARP exchanges (i.e. what Linux >> does) may make sense. Also, under this particular >> misconfiguration, there'll very likely be two ARP >> responses for a lookup of the IP address in question, so >> maybe could be used as an indicator that there's a >> problem. > >If you ignore gratuitous ARP, then what happens when a >station goes down and then comes back up with a different >MAC address? That happens when the station is given new >hardware or in some fail-over schemes. > There are some simple confidence counter techniques that would filter out most spoofs but still allow fail-overs. Basically, you use some simple counters and state variables to detect when an IP address is being repeatedly switched to one MAC address, and then back to the original value. When this is detected the original mac address could then be queried to confirm that it indeed thought it was the IP address in question (just in case this is some sort of migration feature and the flip-flopping was valid). You could probe the original MAC address on *any* change, but that could prove nasty on a large subnet. Having a designated ARP validator on a subnet might make sense if a network administrator was trying to prevent unauthorized use of IP addresses on their network. It's much easier to deal with spoofed source IP addresses on a network basis than from inside one host. At the network level the source IP address can be cross-checked against the physical link it arrived on. Even with automatic fail-over, the network administrator should know where an IP address *could* come from. This is especially true of the IP addresses most worth stealing.
Re: WG Review: Remote Direct Data Placement (rddp)
On 6/17/02, Timur Shemsedinov wrote: >SC> Remote Direct Data Placement (rddp) >SC>--- >SC> 1) A (transportindependent) protocol core to support >SC> direct data placement from the NIC into specified >SC> memory, usually application buffers. >SC> 2) A (transportindependent) protocol core layered on >SC> top of the direct data placement protocol that >SC> specifies control of RDMA. >SC> 3) A mapping of the direct data placement protocol >SC> and the RDMA control protocol to SCTP. >I have some questions. >Whether it is supposed what server module will be inside >the application (or in separate service)? This question >has arisen because processes in the majority of >operational systems have different address spaces. Direct Data Placement protocols typically support anonymous target buffers (essentially the same semantics as SCTP) as well as tagged buffers. Each placement specifies a tag and an address to be interpreted in the context of that tag. How tags are obtained is a local interface issue. How they are distributed is a ULP issue. However, the typical local interface is that the application registers a portion of its own address space, and thereby obtains tags that it can distribute to its peers. You can find examples of such interfaces with InfiniBand (http://www.infinibandta.org), the Virtual Interface Archtiecture (http://www.vidf.org) and the Direct Access Transport API (http://www.datcollaborative.org). InfiniBand is an excellent example of a specific solution. The DAT specifications present a technology neutral definition of Direct Data Placement capable transports. >So, application should use mechanisms of memory sharing >and cross-application interaction or RDMA module should be >included into each application. Typically, the local interface is indeed a user mode library. However, it is local interface, so it can be implemented many ways and not affect interoperability. The reason it will tend to be a user mode library is to avoid unnecessary user/kernel mode transitions. Typically kernel interactions will be done when memory is registered and endpoints are created. The goal is to leave the kernel out of the loop on a per data transfer basis to the greatest extent possible. Current local bus architectures, particularly how interrupts work, limit the degree to which that can be done. However things can still be minimized, and most features of the local interfaces are intended to keep user/kernel interactions as minimal as possible without creating security holes. >And how to understand "transport independent" in this case? > The meaning of a sucessfully delivered DDP or RDMA message is not dependent upon the underlying IP transport protocol that was used to deliver it. The goal is to define protocols that run over ubiquitous transports, not to define a new transport. Applications should not be restricted to SCTP, but free to choose other IP transports that are suitable to their needs. One example would be use of DCP for applications (such as streaming media) that prefer unreliable delivery because real-time delivery requirements severely limit the time window for retries. This is similar to many protocols above layer 4 that run over multiple transports, including RPC and SNMP. Caitlin Bestler Asomi Network Technologies
Re: Why IPv6 is a must?
> > > IPv6 needs to be justified on the number of nodes that truly need a > > globally accessible public address, not by insisting on counting devices > > that should remain anonymous or under limited (and controlled) visibility. > > you appear to be confusing visibility with accessibility. > No, that is exactly what I am not confusing. If a node only requires accessibility by a few specialized nodes (such as a water meter) then making it *visible* to more is just creating a security hole that has to be plugged. Yes, the hole can be plugged easily. I am merely pointing out that the opportunity to add more rules to an IPv6 firewall to plug a security hole that IPv6 created is *not* an argument for IPv6. Further, NAT boxes are very friendly to meter-type devices. They can receive their IPv4 address via DHCP (eliminating the need to administer addresses) and then they can contact the collection server. The upper-layer protocols will identify the meter, which they would have done for authentication reasons anyway. There are also a large number of solutions using L2 tunneling. My point remains, a globally meaningful address is something that should only be applied when it is useful for that endpoint to be globally addressable.
Re: Why IPv6 is a must?
> > 3) new devices that plug into residential networks (mostly new) > > > > What stops the new devices from having v4 with NAT to translate between the > > internet and the house. > > nothing stops them, but if you want to access the devices from outside the > house (and in many cases that's the point of such devices) then NAT gets > in the way. > > Keith > That's exactly why you want NAT/firewalling and other existing mechanisms. These are devices that do not require global addressability. In fact they SHOULD NOT be globally addressable. IPv6 needs to be justified on the number of nodes that truly need a globally accessible public address, not by insisting on counting devices that should remain anonymous or under limited (and controlled) visibility. At times I suspect an administrative standard for uniquely referring to a private IP address is a specific private IP network would have been the only required improvement in global addressing.
