Forum Home
Press F1
Thread ID: 24489	2002-09-12 07:07:00	ADSL online banking problems	Blako (1861)	Press F1

Post ID	Timestamp	Content	User
78851	2002-09-13 06:39:00	I think you're a bit tough on the banks, Juha . (You can be as nasty as you like about the mangerial mob, but the technical guys have to make a secure system work) . The MTU limit has to be kept down to a level where encrypted packets won't be fragmented if they hit routers which can't handle big packets . I know that all modern routers can, but there only have to be a few, and the security of the "secure" connections will be lost . I know a fast network connection makes you want to use big packets for minumum overhead . But there are still reasons why there need to be limits . What is the difference in length between working with the bank or not? It's about 50 or 60 octets, isn't it? In 1500 . What measurable difference in performance does that give you . If only 10% of your transactions cause protocol error messages, and resending of packets because they are too big for the path, you have lost that advantage anyway . Why not use a bit under the maximum and not add to the bus traffic with the errors and repeats? And be able to use the bank system .	Graham L (2)
78852	2002-09-14 03:32:00	> I think you're a bit tough on the banks, Juha . (You > can be as nasty as you like about the mangerial mob, > but the technical guys have to make a secure system > work) . No . . . unless by security you mean "limiting access as much as possible" . ;-) > The MTU limit has to be kept down to a level where > encrypted packets won't be fragmented if they hit > routers which can't handle big packets . I know that > all modern routers can, but there only have to be a > few, and the security of the "secure" connections > will be lost . Dunno about this . What exactly do you mean? All routers must be able to fragment packets . I'd be interested to learn more about how fragmentation nullifies security . > I know a fast network connection makes you want to > use big packets for minumum overhead . But there are > still reasons why there need to be limits . Well, the minimum MTU any router must accept is 576 bytes; PPP and Ethernet have a default MTU of 1,500 bytes . That's all the limits anyone should have to worry about . > What is the difference in length between working with > the bank or not? It's about 50 or 60 octets, isn't > it? In 1500 . What measurable difference in > performance does that give you . If only 10% of your > transactions cause protocol error messages, and > resending of packets because they are too big for the > path, you have lost that advantage anyway . Why not > use a bit under the maximum and not add to the bus > traffic with the errors and repeats? And be able to > use the bank system . That's the whole thing: why should the banks expect customers wanting to use their Web sites to fiddle with their computers' TCP/IP settings . This isn't a trivial fix we're talking about, after all, and it's something that negatively affects all other sites . Is Dr TCP/IP supported by the banks? What about Windows Registry hacks? If something goes wrong, will the banks send out someone to get the customer systems working again? How do you make the recommended changes on MacOS? On Linux? *BSD? Nah, the banks need fix their b0rken networks, instead of blaming innocent customers . Blocking all ICMP isn't a valid security measure anyway . -- Juha	juha (761)
78853	2002-09-14 08:18:00	Hi Guys, its very good of you both to take time out to explain all this and the debate between you is helping......I have to say that my current TCP setting is having an adverse affect on my using other sites..plus my emails are coming in duplicate?.....my query now is what should I set it to?....I also feel the banks ought be able to set things up so that they dont comprise either the security or their clients ablity to use it...after all many sites world wide operate very successfully without blocking all ICMP...dont they?	Blako (1861)
78854	2002-09-14 08:43:00	Here's a useful test site for optimising: dslreports.com (www.dslreports.com)	wuppo (41)
78855	2002-09-15 03:49:00	If your current TCP settings are causing a problem with other sites, the bank is right . You have too high a setting . The Internet is enormous, and some parts are older than others . If you have MTU=1500, try setting it to 1460, and try one of the non-bank sites . If there is still a problem, reduce it again until it does work with the Internet . When that happen, I bet you will be able to use the bank's site . Juha: I'm not a cryptography expert, but I wouldn't like to think that carefully encrypted packets in a critical (that is, money ) application were being manipulated in routers . I'd want them to go from end to end as sent . Similarly, in all computer security things, in a change from the early networking days when you gave as much information as possible (like FTP servers identified themselves, OSs said what they were, and what version) it has been found that this information helps people who are trying to break in . Usercode/password checking for logins: the Unix encryption for passwords slows down at each attempt, so that repeated tries become tedious . (Most actually have a limit of 3 attempts, and then just say "login failed" . . . they don't say "no such usercode" or "bad password" because this helps the baddies . I would say that in trying to have a secure site, you do not send error messages which will tell the crackers where they went wrong . Then you assume that those who are using the system legitimately have their network settings set appropriately to work in all cases; not set to give maximum speed (only when they work) .	Graham L (2)
78856	2002-09-15 04:01:00	thanks Graham,I did reset it to 1460 and below at various times ...I dont have a problem with any other sites including those that have high encryption.. are you saying I ought just keep reducing the MTU setting till it does work...if so by how much?..and what about the other settings..?	Blako (1861)
78857	2002-09-15 04:24:00	" . . . my current TCP setting is having an adverse affect . . . " led me to think that it was a problem on other sites . ;-) Try MTU=1000 (a biggish reduction . . . purely arbitrary) . If the bank site doesn't work at that, there could be another problem . If it does work, try stepping up 50 or so at a time . Other settings such as RWIN should not matter much . The 1500 is not a "default" value . It is a maximum . You will probably find that a lower MTU value does not actually slow you down . There are enough other things in the networks to reduce your throughput . And any theoretical optimum speed drops to zero when you can't communicate at all . The bank will have set their system up to work . It does work for most people . If you are one of a "small percentage" who have problems, the problem is most likely to be at your end . I think there was a thread here a while ago about exactly this problem, and I seem to remember that it wasn't a big difference to get it to work .	Graham L (2)
78858	2002-09-15 06:04:00	ok...i went thru the process starting at 1000..reached 1250 when the bank decided Id had too many login sessions and wont let me login again.(yes I did reboot each change) Up until that point there was no improvement... The bank did give me two different routes to try the one via Wgtn seems t be quicker but still wont load fully. I did find this article interesting www.dslreports.com . But Im not PC literate enough to go into the registry myself as the above item suggests is required...is it?.. What do you think the problems my end could be ?.. I have 3 PC,s networked (closed) running W2k and using a Dynalink RTA020 ADSL external modem..I can sometimes do transactions at the bank on one of the other PC,s altho since tweaking all the settings that doesnt happen now...all are the same..no go...probably coincidental? I,ll go back to logging in later,but I am begining to suspect it isnt going to work...what now?..what should I look for at my end?	Blako (1861)
78859	2002-09-16 01:48:00	> If your current TCP settings are causing a problem > with other sites, the bank is right . > You have too high a setting . The Internet is > enormous, and some parts are older than others . Graham, with all respect, you need to read up a bit on this . > If you have MTU=1500, try setting it to 1460, and try > one of the non-bank sites . If there is still a > problem, reduce it again until it does work > with the Internet . When that happen, I bet you will > be able to use the bank's site . > > Juha: I'm not a cryptography expert, but I wouldn't > like to think that carefully encrypted packets in a > critical (that is, money ) application were > being manipulated in routers . I'd want them to go > from end to end as sent . That's not how TCP/IP works, though . The encrypted packets go over the Internet, a public network, through x amount of routers . There will be packets lost, some will be fragmented if they're too big (and this is where the ICMP messages would be useful as they carry that vital piece of information), etc . How this would affect the encapsulated encrypted payload of packets, I still don't know . > Similarly, in all computer security things, in a > change from the early networking days when you gave > as much information as possible (like FTP servers > identified themselves, OSs said what they were, and > what version) it has been found that this information > helps people who are trying to break in . > Usercode/password checking for logins: the Unix > encryption for passwords slows down at each attempt, > so that repeated tries become tedious . (Most > actually have a limit of 3 attempts, and then just > say "login failed" . . . they don't say "no > such usercode" or "bad password" because this helps > the baddies . I would say that in trying to have a > secure site, you do not send error messages which > will tell the crackers where they went wrong . Then > you assume that those who are using the system > legitimately have their network settings set > appropriately to work in all cases; not set to give > maximum speed (only when they work) . It's nothing to do with "maximum speed" . It's to do with following standards or not . In this case, the banks are not following the standards . Do you really expect non-technical bank customers to sit down and tweak the Registry or equivalents, trying to guess which TCP/IP settings will work? Excuse me, but that's absurd . -- Juha	juha (761)
78860	2002-09-16 02:02:00	> The 1500 is not a "default" value . It is a > maximum . Yes, it is the default for PPP . Check RFC 1134 . What you're asking Blako to do is to reduce the default to a suboptimal value, causing more fragmentation of packets (I can guarantee you that all the routers on his Internet connection path use an MTU of 1500) and more traffic for him, leading to a degradation in service without any advantages . Completely pointless, and if he makes a mistake in editing the Registry, his connection will be stuffed . > The bank will have set their system up to work . It > does work for most people . If you are one of a "small > percentage" who have problems, the problem is most > likely to be at your end . The banks have not set up their system to work . They don't understand what ICMP does, because if they did, they wouldn't filter out all of it . -- Juha	juha (761)
1 2 3