NVR-500のPPTP接続に使われるMS-CHAPv2の認証情報漏えい対策

JPCERTから「MS-CHAP v2 の認証情報漏えいの問題に関する注意喚起」が広報された。
nvr-500とiPhoneでpptp vpnを設定していたのを止めた。
nvr-500には、IPsec機能が無い。困った。。。

IPv6対応のためcf-y4(panasonic)のOSをWindows7にしてみた

Windows XPでは、nslookupなどでIPv6関連の確認に不都合が発生していた。
panasonicのcf-y4にWindows 7 professionalを搭載してみた。
ついでに、1Gbのメモリ追加、64GbのSSD（IDEタイプ）に交換した。約25,000円の投資だ。

比較的快適に使える。Windows XPの時とほぼ同じ感覚で使えるが若干メモリ不足感がある。
しかし、もう少し投資してDual Core CPUのノートブックを買った方が良い。。。
---2012/08/23 追記

NVR-500のrtadv send機能動作と制限について

NVR-500でIPv6PPPoEインターネット接続とIPv6フレッツ網への同時接続設定で要となる「ipv6 interface rtadv send」コマンドについて、「NVR500でIPv6利用の問題点」で幾つか掲げた(Rev.11.00.19)。
(1)2つ以上のproxy定義prefixを設定できない
(2)DNSサーバやサーチリスト情報をDHCPv6での提供が動作しない場合がある
(3)mtu値の広告オプション設定値に疑問がある
これらの詳細について少し確認したので、以下にメモしておく
（2012年7月30日 Rev.11.00.20がリリースされている）
------------------------------------------------------

(1)2つ以上のproxy定義prefixを設定できない
PR-S300SEからDHCPv6で得られたprefix(a)を
ipv6 prefix 1 dhcp-prefix@lan2::/64

IPv6PPPoE接続から得られるprefix(b)を
ipv6 prefix 2 dhcp-prefix@pp2::/64

PR-S300SEのlan側に広告されたprefix(c)を
ipv6 prefix 3 ra-prefix@lan2::/64

(a)のprefix値と同じprefixを静的に定義
ipv6 prefix 10 2408:XXXX:YYYY:110::/64

(b)のprefix値と同じprefixを静的に定義
ipv6 prefix 20 2400:AAAA:BBBB:4c00::/64

とすると下記の通り二つ以上のproxy定義のprefix広告が出来ない。
proxy定義のprefix一つと静的定義のprefix（複数可）を同時に広告することはできる（ヤマハ確認済み）
×　ipv6 lan1 rtadv send 1 2 o_flag=on
×　ipv6 lan1 rtadv send 2 3 o_flag=on
○ ipv6 lan1 rtadv send 1 20 o_flag=on
○ ipv6 lan1 rtadv send 2 10 o_flag=on
○ ipv6 lan1 rtadv send 3 20 o_flag=on
○ ipv6 lan1 rtadv send 10 20 o_flag=on
実際にこのコマンドを変更してlan1側に広告されるprefixを確認してみると広告されたり、されなかったりする。よくよく調べてみると設定通りのprefix値内容で広告されるまで「時間」がかかることが判った。
下記例では、1時間ちょっとであるが、条件によって2時間近くかかる場合がある。
広告するprefix値を変化させた後、広告されるまで十分な時間を置く必要がある。テストでprefix設定を変化させる場合に注意が必要である。

図(1)-1 ipv6 lan1 rtadv send 1 20 o_flag=on（広告されるまで1時間31分）


図(1)-2 ipv6 lan1 rtadv send 2 10 o_flag=on（広告されるまで1時間12分）


図(1)-3 ipv6 lan1 rtadv send 3 20 o_flag=on（広告されるまで11分）


proxy設定されたprefixがどのようなタイミングで広告されるのか調査が必要（ヤマハ問合せ中---2012/9/9 調査完了）

（２）DNSサーバやドメイン情報をDHCPv6での提供が動作しない場合がある
NVR-500のDHCPv6サーバ機能では、IPv6PPPoE接続のDHCPで取得した情報やPR-S300SEからDHCPv6で取得した情報を広告しているときだけ、広告中prefixと同時に取得した情報をDHCPv6サーバ機能で提供することができる。NVR-500に設定したリカーシブDNSをDHCPv6サーバ機能で提供することができない（ヤマハ確認済み）
「ipv6 interface rtadv send」の「o_flag=on」オプションを設定して下記広告時に取得できるdhcpv6情報を確認してみた
ipv6 lan1 rtadv send 1 20 o_flag=on（フレッツ接続されたPR-S300SEからDHCPで得たprefix情報を広告）

フレッツのドメイン・サーチリストが得られている。DNSアドレスは、PR-S300SEのアドレスになるはずであるが、NVR-500のIPv6PPPoE接続に使われるアドレスが設定されている。結果的に、NVR-500のリカーシブサーバ機能が提供されていることになる（ヤマハ確認中）

ipv6 lan1 rtadv send 2 10 o_flag=on（IPv6PPPoE接続のDHCPで得たprefix情報を広告）

IPv6PPPoE接続では、DNSサーチリストが提供されていないためDNSサーバアドレスだけが返されるはずだが、NVR-500のIPv6PPPoE接続に使われるアドレスが設定されている。

ipv6 lan1 rtadv send 3 20 o_flag=on（PR-S300SEのRAから得たprefix情報を広告）

PR-S300SEのRAからは、prefix情報しか得ていない。o_flag=onが設定されているがNVR-500からDHCPv6 Requestの発生は無い。raで受けたprefix情報を「rtadv send」で広告する場合、mtu値オプション設定は動作しない。受けたraにmtuオプションが設定されている場合は、その値が引き継がれ広告される(ヤマハ確認済み）。
PR-S300SEのraにmtu値広告が含まれていない。この場合、NVR-500がmtu値をどのような値に設定するか不明である。コマンド仕様に従うなら「rtadv send」で指定したinterfaceのmtu値が使われる事になる。mtu=1500となっているので仕様通りと推定される。
また、このRAを受けたルータや端末は、DHCPv6でDNSなどの情報取得動作をしていない。結果、DNS情報を返さないはずであるが、NVR-500には、IPv6PPPoE接続に使われるアドレスが設定されている。不思議（ヤマハ確認中）。

ipv6 lan1 rtadv send 10 20 o_flag=on（静的に定義されたprefix情報を広告）
この場合は、DHCPv6 Requestを行ってもNVR-500は、DHCPv6 Replyを返さない。静的に定義されたprefix情報を広告しているときでも、NVR-500のリカーシブDNSサーバ用アドレス情報をo_flag=onオプションに従ってReplyして欲しい。

(3)mtu値の広告オプション設定値に疑問がある
「ipv6 interface rtadv send」でmtuオプションを設定しない場合、mtu=autoとなり、インターフェースのmtu値が適応されるとコマンド仕様に記載されている。

図(1)-1、図(1)-2、図(1)-3でNVR-500から広告するmtu値を確認するとそれぞれmtu=1280、mtu=1280、mtu=1500となっている。
広告するinterfaceのmtuであれば、NVR-500のlan1なのでmtu=1500となるはず。IPv6PPPoE接続やPR-S300SEからDHCPv6で得た接続先interfaceのmtuであれば、図(1)-1ではmtu=1500（lan2のmtu）、図(1)-2ではmtu=1454（pp02のmtu）、図(1)-3ではmtu=1500（lan2のmtu）が予測される。詳細なmtu設定基準を確認する必要がある（ヤマハ確認中--- 2012/9/9 確認済み）。
raでprefixを受け「rtadv send」でそのraを広告する場合（ 図(1)-3 ）は、mtu値の変更が出来ない仕様であることを確認している（ヤマハ確認済み）