アカウント名:
パスワード:
代替策はどういうのがあるんでしょうか?・MACアドレス・端末固有番号・SIMのシリアル番号詳しくないので漏れや不都合があったらぶら下げてください
・SPモードを廃止する
だめ？
これってiモードのときはどうしてたの？
#2070782 でも書きましたが、将来的な汎用性を持たせたキャリアサービス、のためにSPモード(not iモード)から設備自体が変化していると思います(あくまでも想像)。
※ 一般にAPN設定によりその辺を変更させることができます。
既存のiモードのような「SIMが刺さってる前提」なら、それこそ電話番号(というかMSISDN)一本槍でかまいません。ショートメール時代には本当にそれが前提というか必須でしたし。
今後の話としては将来のiモード端末も(今で言う)SPモードの設備に収容されていくでしょうが、今のところは「SPモードの設備を使うiモード端末というのは存在していなかった」くらいでしょう。
廃止して土管屋になれば可能
iモードの資産を有効活用しようとして、スケーラブルでないシステムを無理矢理導入したのが原因きっと無茶な要求を受けて、その場しのぎの対応したんだろうけど・・・
増強しても、同じような問題は今後も起こるでしょう。増強しすぎると無駄だし、かといってアクセスは増えるし・・・
いいんじゃない。WiFi使わないとネットに繋がらない、けどスマートフォンとして販売される電話つきミニタブレットが見たければ。
電話番号でいいだろ
>電話番号でいいだろ
電話番号「だけ」でやろうとすると、電話番号を持たないデバイスからの利用が不可能になります。
これは、たとえばLTE以降のアーキテクチャのひとつの主眼である「自社SIMを挿入したプロパー端末”以外”での利用」(3GPP/3GPP2規格での他方式経由の場合もあれば、WIFIなど完全に他インフラ経由の場合もあり)を見越した場合には大きな制約ですので、キャリアがこれを取り払いたいと意識するのは前向きと思います。
また、仮にダミーの電話番号を都度発行して接続させるとすると、利用者電話番号の現在ステータスを登録するDBに電話番号でない架空の値をぶち込んでしまえ、なんてことになり現実的ではありません(さすがにこれはキャリアは絶対やりません)し、またそれでもズレが発生しうるということに変わりはありません。
その先では、「将来的な汎用性を取るか、取らせないか」を織り込まないと有意義な話は進まないでしょうね。
「IPアドレスと電話番号の関連付けに不整合が生じたのだという。」という件とは何の関係のないオフトピックな下らない話をされても、全然言い訳にならないぜ。
spモードはデータ通信専用プランでも使えるようになってるんだよ、音声通話をサポートしないタブレット端末などのためにな。
データ専用プランでも電話番号は割当てられますよ。ドコモがやってるプランなら、その番号でSMS受信も可能です。イオンの980円SIMですら割当てだけはされています（こちらはSMSも不可なので、電話番号を利用可能なシーンはありません）。
「バカと言ってる奴がバカ」のひどい実例を見た。データ専用プランでも電話番号があることを知らないとか…。
データ専用端末でも回線的にはあくまで「携帯電話」ですからね。
ちなみに規格上「携帯電話」ではないWiMAXの場合電話番号はありませんしユニバーサル使用料も払う必要がありません。
>「IPアドレスと電話番号の関連付けに不整合が生じたのだという。」>という件とは何の関係のないオフトピックな下らない話をされても、全然言い訳にならないぜ。
「電話番号一発でやったら？」という解決案に対しての反論ですよ。言い訳とかそういうものではないのですが。
あなたの思考が「ドコモを叩く。叩くのに都合が悪いのは全部言い訳に決まってる」に凝り固まりすぎてるだけじゃないですかね。
>IPアドレスとメアドを結びつけるなんて、どんだけ腐った設計なのか [sonorilo.net]
他の方も触れていることですが、IPアドレスと加入者情報を紐付けるのはLTE/SAE世代での普通の設計です(というかそれ以前からも普通の設計です)。たとえばPCRF/PCEFとか言われて即座にその仕組みを理解できますか？できないならまずあなたに必要なのは勉強です。
その上で、これまた触れられていることとして「腐っているんだ」というなら、LTE/SAE世代のアーキテクチャそのものを、全世界の関連業界・業者に向けてでどうぞ。それなら別に止めはしませんよ。
通りすがりですけどあなたの認識がかなり変にしか見えませんけど。
元ACはLTE/SAE世代のアーキテクチャつまり次世代の話をしているのであってLTE全体の話をしているのではないと思いますけど。
つまり元ACは「これからは加入者情報とIPアドレスを紐付ける事が常識になる」という話をしているわけですからそれに対して「LTEではなく3Gのユーザーでも今回の障害に巻き込まれているし」という反論は筋違いも甚だしいと思いますけど。
サーバー側で動いているプログラムは、自分に接続してきている端末の電話番号をどうやって知るのですか？
端末側のアプリから送られてきた電話番号を信用して認証するということでしたら、電話番号を知られると、送信者詐称や他人のメールを受け取ることが可能になるという問題が発生します(これは端末固有番号など他の情報を使っていても同じ)。
その問題を避けたければ、TCP/IPコネクションと電話番号を対応付けるシステムが必要ということになり、結局、IPアドレス(+ポート番号)から、電話番号を引いてくることになってしまいます。今回の障害はその電話番号を引くところの問題なので、解決になりません。
Xi(LTE）に関して言えば、通話ももはやVoIPなんで、紐付けはできていますよ。
>Xi(LTE）に関して言えば、通話ももはやVoIPなんで、
基地局設備側がオールIP化はされていますが、VoIPという観点(=端末～無線区間まで完全にIP化。つまり端末からすでにIP電話化)は行われていません。今のところ、音声通話に関しては端末は回線交換で行っています。データ通信(=完全IP化済)とのやりくりは、たとえばCSフォールバックなどで対処しています。
完全なVoIP通話になるのはまだまだ先ですね。
> Xi(LTE）に関して言えば、通話ももはやVoIPなんで、
なってません。現在のXi音声通話は、FOMA音声網を利用する仕様です。
> 自分に接続してきている端末の電話番号をどうやって知るのですか？Simカードから送られてくる情報で識別します。
> 電話番号を知られると、送信者詐称や他人のメールを受け取ることが可能になるという問題が発生します(これは端末固有番号など他の情報を使っていても同じ)。すげぇデマだな。Simカードのセキュリティの仕組みについて、勉強した方がいいよ。
すげぇデマだな。
デマではないですね。「端末側のアプリから送られてきた電話番号を信用して認証する」という仮定が成立したら、送信者詐称や他人のメールを受け取ることが可能になるのは本当でしょう。もちろん、アプリが電話番号やSimカードの情報を送るような実装はしないので、そういう問題は発生しないわけですが。
で、Simカードの情報はアプリが送るわけではなく、「このコネクションを張ってきた端末はこれ」という対応関係をキャリアが保証するからわかるわけです。今回の障害はその対応関係の保証が崩壊したのが問題なので、Simカードから送られてくる情報で識別することは解決になりません。
> Simカードから送られてくる情報で識別することは解決になりません。
じゃ、ドコモが発表した回避策「電源のOFF/ONという再起動で回避できる」という話は嘘なのか？お前がでたらめ言っているのか、それともドコモが嘘をついているのか、どっちが正しいのかね？
それは「他人が送信者に設定されてしまう人は、一回切断して再起動すれば正しい対応関係が設定できる状況になった」と言っているだけ。ドコモの発表で、プロトコルの改善はこれから取り組むと言っていることからわかるとおり、障害の原因はまだ取り除かれていません。再起動で正常化するのは、現在輻輳が発生していないからうまくいくだけです。プロトコルの改善が完了する前に同じ状況が再度発生すれば、同じ障害が発生します。
お前がでたらめ言っているのか、それともドコモが嘘をついているのか、どっちが正しいのかね？
正解は、「両方正しい。あなたが技術を理解していないだけ」でしょう。
代替策はありません。MSISDN(=今回電話番号と表現されているもの)で管理するのは3GPPの規格ですので、やるとしたら「同じことが起きないよう設備増強や冗長性確保を強化する」だけです。
3GPPは関係ない。そっちは別に問題ない。問題なのはIPベースのspモード。それにおけるユーザ、つまりMSISDNとか加入者との紐付け、ようは認証機構のお話。
今回ドコモがなにやらかしたカといえば、認証キーにIPアドレス使ったこと。たしかに詐称は難しいし、ルータやDHCPに相当するような部分を認証機構に組み入れてしっかり管理していれば強い部分もあるけれど、問題なのはキーの範囲が狭くて再利用されること。セッションキーなど認証などのキーは十分に広く、通常使い捨てで、推測困難な物をつかう。普通にある程度の長さのランダムキー使ってれば、メール送れないとか遅延とかで済んでたはず。そういうのをIPアドレスと組み合わせても良いし。
あとメールアドレスの事だけ書いている所が多いけれど、IPアドレスで認証してたのはspモードとしてなので、spモード全てのサービスに影響してた。http://japan.cnet.com/news/service/35012398/ [cnet.com]
コンテンツの誤課金などの可能性は？それも論理的には可能性がある。
> そういうのをIPアドレスと組み合わせても良いし。
セッションキーで万全なんだから、組み合わせなんていらない。どうしてそういう半端な発想をするんだろうね。
>セッションキーで万全なんだから、組み合わせなんていらない。ほう、どう「万全」なのか、説明してみな。きっとおっさん達が叩きのめしてくれるぞ。
>今回ドコモがなにやらかしたカといえば、認証キーにIPアドレス使ったこと。
たとえば将来的な話として3GPPの網から3GPP2の網にセッションを維持しつつハンドオーバーする、もっと言えば公衆WIFI(ただし回線の上流は自社回線のSGWに接続)にセッションを維持しつつハンドオーバーする、という観点が存在することは理解できますか？これはドコモがどうのこうのではなく3GPPの定義における今後の方向性です。
この場合、たとえばMIPv6やDSMIPv4/v6などで付与されるIPアドレスはハンドオーバーしても使いまわしされることになります(そうしないとセッションが維持できません)。
ですの
いや、全然詳しくないけども。IPアドレス死守するのは良いけれど、実際問題死守出来てないし、その書き方だと現状すでに完成されたものでもなさそうだし、現実に電源ON/OFFでIPアドレス変わるし。そんな状況で、さらに接続切れて回収されたIPアドレスが簡単に別機に再割り当てされる状況で、IPアドレスだけで認証しているのは間違いだと思うけど。特に前のコメントでも書いたけど、問題なのはキーの範囲が狭くて再利用されること。だから、セッションキーの様になにかキーをチョロッと付けるか、別のコメントにあるけどIPv6でもっと広い空間を持った物を使うとか。まあ、キー付けるって簡単に言っても、それだけでも確実に負荷上がるわけで、それはそれでネックになりかねないとは思うけれど、セッション死守できなければ殺すのが正しい方法です。
メールが届いたときには、端末に特殊なSMSを送って、それをトリガーにして端末側からPOP3Sで受信動作をする、という流れになってます。 Technology Reports [nttdocomo.co.jp] （PDF）
・POP3S、SMTPSで使うユーザーIDとパスワードは、サーバー側から期限付で払い出す。（ここがおかしくなった）・POP3S、SMTPSで端末からサーバーにアクセスがあった際には、これに加えてIPアドレスも認証に使う。
端末がSMTPSでメール送信をしようとした時に、サーバーがIPアドレスだけをたよりにメールアカウント情報を送りつけたために今回のようなことになった、ということかな。もし端末に固
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生の大半の問題はスルー力で解決する -- スルー力研究専門家
代替策 (スコア:1)
代替策はどういうのがあるんでしょうか?
・MACアドレス
・端末固有番号
・SIMのシリアル番号
詳しくないので漏れや不都合があったらぶら下げてください
Re:代替策 (スコア:2)
・SPモードを廃止する
だめ？
一人以外は全員敗者
それでもあきらめるより熱くなれ
Re: (スコア:0)
これってiモードのときはどうしてたの？
Re: (スコア:0)
#2070782 でも書きましたが、
将来的な汎用性を持たせたキャリアサービス、のために
SPモード(not iモード)から設備自体が変化していると思います(あくまでも想像)。
※ 一般にAPN設定によりその辺を変更させることができます。
既存のiモードのような「SIMが刺さってる前提」なら、
それこそ電話番号(というかMSISDN)一本槍でかまいません。
ショートメール時代には本当にそれが前提というか必須でしたし。
今後の話としては将来のiモード端末も(今で言う)SPモードの設備に収容されていくでしょうが、
今のところは「SPモードの設備を使うiモード端末というのは存在していなかった」くらいでしょう。
Re: (スコア:0)
廃止して土管屋になれば可能
iモードの資産を有効活用しようとして、スケーラブルでないシステムを無理矢理導入したのが原因
きっと無茶な要求を受けて、その場しのぎの対応したんだろうけど・・・
増強しても、同じような問題は今後も起こるでしょう。
増強しすぎると無駄だし、かといってアクセスは増えるし・・・
Re: (スコア:0)
いいんじゃない。
WiFi使わないとネットに繋がらない、けどスマートフォンとして販売される電話つきミニタブレットが見たければ。
Re: (スコア:0)
電話番号でいいだろ
Re: (スコア:0)
Re: (スコア:0)
>電話番号でいいだろ
電話番号「だけ」でやろうとすると、
電話番号を持たないデバイスからの利用が不可能になります。
これは、たとえばLTE以降のアーキテクチャのひとつの主眼である
「自社SIMを挿入したプロパー端末”以外”での利用」
(3GPP/3GPP2規格での他方式経由の場合もあれば、WIFIなど完全に他インフラ経由の場合もあり)
を見越した場合には大きな制約ですので、
キャリアがこれを取り払いたいと意識するのは前向きと思います。
また、仮にダミーの電話番号を都度発行して接続させるとすると、
利用者電話番号の現在ステータスを登録するDBに
電話番号でない架空の値をぶち込んでしまえ、
なんてことになり現実的ではありません
(さすがにこれはキャリアは絶対やりません)し、
またそれでもズレが発生しうるということに変わりはありません。
その先では、「将来的な汎用性を取るか、取らせないか」を織り込まないと
有意義な話は進まないでしょうね。
Re: (スコア:0)
「IPアドレスと電話番号の関連付けに不整合が生じたのだという。」という件とは何の関係のないオフトピックな下らない話をされても、全然言い訳にならないぜ。
バカだろお前 (スコア:0)
spモードはデータ通信専用プランでも使えるようになってるんだよ、音声通話をサポートしないタブレット端末などのためにな。
Re:バカだろお前 (スコア:2, 参考になる)
データ専用プランでも電話番号は割当てられますよ。
ドコモがやってるプランなら、その番号でSMS受信も可能です。
イオンの980円SIMですら割当てだけはされています（こちらはSMSも不可なので、電話番号を利用可能なシーンはありません）。
Re: (スコア:0)
「バカと言ってる奴がバカ」のひどい実例を見た。データ専用プランでも電話番号があることを知らないとか…。
Re: (スコア:0)
番号の枯渇が危惧されているなか、電話番号が不要なデータ端末に番号が付番されているのはちょっと勿体ないと思います。規格上仕方ないんでしょうけどね。
Re: (スコア:0)
データ専用端末でも回線的にはあくまで「携帯電話」ですからね。
ちなみに規格上「携帯電話」ではないWiMAXの場合電話番号はありませんしユニバーサル使用料も払う必要がありません。
Re: (スコア:0)
>「IPアドレスと電話番号の関連付けに不整合が生じたのだという。」
>という件とは何の関係のないオフトピックな下らない話をされても、全然言い訳にならないぜ。
「電話番号一発でやったら？」という解決案に対しての反論ですよ。
言い訳とかそういうものではないのですが。
あなたの思考が
「ドコモを叩く。叩くのに都合が悪いのは全部言い訳に決まってる」
に凝り固まりすぎてるだけじゃないですかね。
Re: (スコア:0)
>IPアドレスとメアドを結びつけるなんて、どんだけ腐った設計なのか [sonorilo.net]
他の方も触れていることですが、
IPアドレスと加入者情報を紐付けるのはLTE/SAE世代での普通の設計です
(というかそれ以前からも普通の設計です)。
たとえばPCRF/PCEFとか言われて即座にその仕組みを理解できますか？
できないならまずあなたに必要なのは勉強です。
その上で、これまた触れられていることとして
「腐っているんだ」というなら、
LTE/SAE世代のアーキテクチャそのものを、全世界の関連業界・業者に向けてでどうぞ。
それなら別に止めはしませんよ。
Re: (スコア:0)
通りすがりですけどあなたの認識がかなり変にしか見えませんけど。
元ACはLTE/SAE世代のアーキテクチャつまり次世代の話をしているのであってLTE全体の話をしているのではないと思いますけど。
つまり元ACは「これからは加入者情報とIPアドレスを紐付ける事が常識になる」という話をしているわけですからそれに対して「LTEではなく3Gのユーザーでも今回の障害に巻き込まれているし」という反論は筋違いも甚だしいと思いますけど。
Re: (スコア:0)
サーバー側で動いているプログラムは、自分に接続してきている端末の電話番号をどうやって知るのですか？
端末側のアプリから送られてきた電話番号を信用して認証するということでしたら、電話番号を知られると、送信者詐称や他人のメールを受け取ることが可能になるという問題が発生します(これは端末固有番号など他の情報を使っていても同じ)。
その問題を避けたければ、TCP/IPコネクションと電話番号を対応付けるシステムが必要ということになり、結局、IPアドレス(+ポート番号)から、電話番号を引いてくることになってしまいます。今回の障害はその電話番号を引くところの問題なので、解決になりません。
Re: (スコア:0)
Xi(LTE）に関して言えば、通話ももはやVoIPなんで、
紐付けはできていますよ。
Re: (スコア:0)
>Xi(LTE）に関して言えば、通話ももはやVoIPなんで、
基地局設備側がオールIP化はされていますが、
VoIPという観点(=端末～無線区間まで完全にIP化。つまり端末からすでにIP電話化)は行われていません。
今のところ、音声通話に関しては端末は回線交換で行っています。
データ通信(=完全IP化済)とのやりくりは、たとえばCSフォールバックなどで対処しています。
完全なVoIP通話になるのはまだまだ先ですね。
Re: (スコア:0)
> Xi(LTE）に関して言えば、通話ももはやVoIPなんで、
なってません。現在のXi音声通話は、FOMA音声網を利用する仕様です。
Re: (スコア:0)
> 自分に接続してきている端末の電話番号をどうやって知るのですか？
Simカードから送られてくる情報で識別します。
> 電話番号を知られると、送信者詐称や他人のメールを受け取ることが可能になるという問題が発生します(これは端末固有番号など他の情報を使っていても同じ)。
すげぇデマだな。Simカードのセキュリティの仕組みについて、勉強した方がいいよ。
Re: (スコア:0)
すげぇデマだな。
デマではないですね。「端末側のアプリから送られてきた電話番号を信用して認証する」という仮定が成立したら、送信者詐称や他人のメールを受け取ることが可能になるのは本当でしょう。もちろん、アプリが電話番号やSimカードの情報を送るような実装はしないので、そういう問題は発生しないわけですが。
で、Simカードの情報はアプリが送るわけではなく、「このコネクションを張ってきた端末はこれ」という対応関係をキャリアが保証するからわかるわけです。今回の障害はその対応関係の保証が崩壊したのが問題なので、Simカードから送られてくる情報で識別することは解決になりません。
Re: (スコア:0)
> Simカードから送られてくる情報で識別することは解決になりません。
じゃ、ドコモが発表した回避策「電源のOFF/ONという再起動で回避できる」という話は嘘なのか？
お前がでたらめ言っているのか、それともドコモが嘘をついているのか、どっちが正しいのかね？
Re: (スコア:0)
それは「他人が送信者に設定されてしまう人は、一回切断して再起動すれば正しい対応関係が設定できる状況になった」と言っているだけ。ドコモの発表で、プロトコルの改善はこれから取り組むと言っていることからわかるとおり、障害の原因はまだ取り除かれていません。再起動で正常化するのは、現在輻輳が発生していないからうまくいくだけです。プロトコルの改善が完了する前に同じ状況が再度発生すれば、同じ障害が発生します。
お前がでたらめ言っているのか、それともドコモが嘘をついているのか、どっちが正しいのかね？
正解は、「両方正しい。あなたが技術を理解していないだけ」でしょう。
Re: (スコア:0)
代替策はありません。
MSISDN(=今回電話番号と表現されているもの)で管理するのは
3GPPの規格ですので、
やるとしたら「同じことが起きないよう設備増強や冗長性確保を強化する」だけです。
Re:代替策 (スコア:2)
3GPPは関係ない。そっちは別に問題ない。
問題なのはIPベースのspモード。それにおけるユーザ、つまりMSISDNとか加入者との紐付け、ようは認証機構のお話。
今回ドコモがなにやらかしたカといえば、認証キーにIPアドレス使ったこと。
たしかに詐称は難しいし、ルータやDHCPに相当するような部分を認証機構に組み入れてしっかり管理していれば強い部分もあるけれど、
問題なのはキーの範囲が狭くて再利用されること。
セッションキーなど認証などのキーは十分に広く、通常使い捨てで、推測困難な物をつかう。
普通にある程度の長さのランダムキー使ってれば、メール送れないとか遅延とかで済んでたはず。
そういうのをIPアドレスと組み合わせても良いし。
あとメールアドレスの事だけ書いている所が多いけれど、IPアドレスで認証してたのはspモードとしてなので、spモード全てのサービスに影響してた。
http://japan.cnet.com/news/service/35012398/ [cnet.com]
コンテンツの誤課金などの可能性は？
それも論理的には可能性がある。
Re: (スコア:0)
> そういうのをIPアドレスと組み合わせても良いし。
セッションキーで万全なんだから、組み合わせなんていらない。
どうしてそういう半端な発想をするんだろうね。
Re: (スコア:0)
>セッションキーで万全なんだから、組み合わせなんていらない。
ほう、どう「万全」なのか、説明してみな。
きっとおっさん達が叩きのめしてくれるぞ。
Re: (スコア:0)
>今回ドコモがなにやらかしたカといえば、認証キーにIPアドレス使ったこと。
たとえば将来的な話として
3GPPの網から3GPP2の網にセッションを維持しつつハンドオーバーする、
もっと言えば公衆WIFI(ただし回線の上流は自社回線のSGWに接続)にセッションを維持しつつハンドオーバーする、
という観点が存在することは理解できますか？
これはドコモがどうのこうのではなく3GPPの定義における今後の方向性です。
この場合、たとえばMIPv6やDSMIPv4/v6などで付与されるIPアドレスは
ハンドオーバーしても使いまわしされることになります
(そうしないとセッションが維持できません)。
ですの
Re:代替策 (スコア:1)
いや、全然詳しくないけども。
IPアドレス死守するのは良いけれど、実際問題死守出来てないし、その書き方だと現状すでに完成されたものでもなさそうだし、現実に電源ON/OFFでIPアドレス変わるし。
そんな状況で、さらに接続切れて回収されたIPアドレスが簡単に別機に再割り当てされる状況で、IPアドレスだけで認証しているのは間違いだと思うけど。
特に前のコメントでも書いたけど、問題なのはキーの範囲が狭くて再利用されること。
だから、セッションキーの様になにかキーをチョロッと付けるか、別のコメントにあるけどIPv6でもっと広い空間を持った物を使うとか。
まあ、キー付けるって簡単に言っても、それだけでも確実に負荷上がるわけで、それはそれでネックになりかねないとは思うけれど、
セッション死守できなければ殺すのが正しい方法です。
Re: (スコア:0)
メールが届いたときには、端末に特殊なSMSを送って、それをトリガーにして端末側からPOP3Sで受信動作をする、という流れになってます。
Technology Reports [nttdocomo.co.jp] （PDF）
・POP3S、SMTPSで使うユーザーIDとパスワードは、サーバー側から期限付で払い出す。（ここがおかしくなった）
・POP3S、SMTPSで端末からサーバーにアクセスがあった際には、これに加えてIPアドレスも認証に使う。
端末がSMTPSでメール送信をしようとした時に、サーバーがIPアドレスだけをたよりにメールアカウント情報を送りつけたために今回のようなことになった、ということかな。
もし端末に固