some level of generic network characteristics benefit for the user. one example could be that routing metric may need to be updated to align with various kind of access technologies.
-Hui 2009/4/17 Giyeong Son <g...@rim.com>: > Again as I mentioned, in order to prepare or build an efficient routing > policy and to select an efficient connection/interface, it would be > necessary to identify, classify and/or prioritize underlying network > characteristics or information of the attached networks. > > In addition, as many network characteristics which are essential to be > used for simultaneous use of multiple interfaces are not generic forms > (e.g. SSID only for 802.11), these network characteristics may require a > mechanism to make them be associated with generic (formed) elements used > for routing policy preparation and routing decision. Therefore, if MIF > can provide an efficient guideline or mechanism for associating, it > would be really amazing. > > I believe, the current IP network related protocols and standardized > technologies may not be enough to support that on multiple interface > network environment. > > I think each vendor, carrier, service provider and/or technology, which > utilizes or supports simultaneous use of multiple > connections/interfaces, may have their own proprietary mechanism in > terms of gathering of network characteristics of each interface/access > network technology (e.g. WiFi, GPRS, CDMA, Bluetooth, etc.), their > mapping mechanism with generic formed elements, routing policy and > decision mechanisms with different IP based service networks owned by > different service providers or different IP network enabling core > networks owned by different carriers. > > So, the problem Ted and Ralph are addressing seems to be just one of > issues (but only for WiFi network environments) in terms of network > characteristic that may be necessary to be considered during selection > of an efficient connection/interface from multiple candidates. > > Giyeong > > -----Original Message----- > From: Ralph Droms [mailto:rdr...@cisco.com] > Sent: April 16, 2009 1:32 PM > To: Ted Lemon > Cc: Giyeong Son; Hui Deng; dhc WG; gen-...@ietf.org; mif; ietf@ietf.org; > black_da...@emc.com > Subject: Re: [dhcwg] [mif] Gen-ART review of draft-ietf-dhc-container-00 > > Yup ... there is currently no way to provide authenticated, meaningful > identification of the network(s) to which a host is attached. Without > that identification, it's pretty hard to write any reasonable policies. > > - Ralph > > On Apr 16, 2009, at 1:26 PM 4/16/09, Ted Lemon wrote: > >> On 2009/4/13 Ralph Droms <rdr...@cisco.com> wrote: >>> For example, would a host process >>> information received from a Starbucks network over its 802.11 >>> interface differently from information received a home network over >>> the 802.11 interface? >> >> It's even more fun than that. How do we reliably know that we are >> at Starbucks, and not at home? The SSID? That's not an >> authenticated token. Currently Windows makes security decisions >> based on the SSID. You could call this the best answer they could >> come up with for a problem with no good answers. Or you could say >> that it instills the user with a false sense of security. Either >> way, it's not something I'd be comfortable seeing in a protocol spec, >> so if the client is in fact to make decisions as you've >> suggested, we'd need a secure way of doing this. I don't know >> enough about WPA Enterprise to know if there's a bidirectional >> authentication going on there - from the UI perspective it looks like >> it's one-way. >> > > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-public > information. Any use of this information by anyone other than the intended > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from your > system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be unlawful. > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
