QA@IT
«回答へ戻る

回答を投稿

一般にストリームの場合はヘッダのLengthフィールドでパケット境界を教えるか、パケットの区切りコードでパケット境界を示すかは、プロトコル設計者がどっちか片方を選択するんじゃないかと思います。いずれにせよ送信側は正しいものをセットすることがコミュニケーションの前提条件になると思います。ただ受信側はLengthフィールドを一応信用しつつもパケットのsanity checkを行ったほうがよいと思います。

RADIUS over TLS (RFC 6614)やRADIUS over TCP (RFC 6613)の場合は、ヘッダのLengthフィールドを使用します。

パケット境界の考え方についてはRFC 6614の下の箇所が参考になります。

3.4. RADIUS Datagram Considerations
(1) ...
Instead, packet boundaries of RADIUS packets that arrive in the
stream are calculated by evaluating the packet's Length field.
Special care needs to be taken on the packet sender side that
the value of the Length field is indeed correct before sending
it over the TLS tunnel, because incorrect packet lengths can no
longer be detected by a differing datagram boundary. See
Section 2.6.4 of [RFC6613] for more details.

パケットのsanity checkについては上で言及されているRFC 6613の下記の箇所が参考になります。Lengthフィールドが誤っていたような場合、パケット境界を厳密に決定することはできないと思いますが、あからさまな間違いは検出できると思います。また「1個前の」パケットがmalformedで「次の」パケットが切り出せないときは、コネクションを切断すべきであるようです。

2.6.4. Malformed Packets and Unknown Clients
...
When TCP is used as a transport, decoding the "next" packet on a
connection depends on the proper decoding of the previous packet. As
a result, the behavior with respect to discarded packets has to
change.
...

RADIUSの場合は、ヘッダの固定長部分とAttributeのリストからなる可変長部分がありますが、AttributeはTLVの形式で、個々のAttributeがL(ength)を持つので、リストを舐めながらその和をとって固定長部分と足せば、パケット全体長がわかるはずと思います。それとヘッダ内のLengthを比較すれば、ヘッダとボディ部分とで辻褄が合っているかどうかを確認できるのではないかと思いますので、ヘッダ内のLengthの間違いはある程度は検出できそうな気がします。

一般にストリームの場合はヘッダのLengthフィールドでパケット境界を教えるか、パケットの区切りコードでパケット境界を示すかは、プロトコル設計者がどっちか片方を選択するんじゃないかと思います。いずれにせよ送信側は正しいものをセットすることがコミュニケーションの前提条件になると思います。ただ受信側はLengthフィールドを一応信用しつつもパケットのsanity checkを行ったほうがよいと思います。

RADIUS over TLS (RFC 6614)やRADIUS over TCP (RFC 6613)の場合は、ヘッダのLengthフィールドを使用します。

パケット境界の考え方についてはRFC 6614の下の箇所が参考になります。

> 3.4. RADIUS Datagram Considerations
> (1) ...
> Instead, packet boundaries of RADIUS packets that arrive in the
> stream are calculated by evaluating the packet's Length field.
> Special care needs to be taken on the packet sender side that
> the value of the Length field is indeed correct before sending
> it over the TLS tunnel, because incorrect packet lengths can no
> longer be detected by a differing datagram boundary.  See
> Section 2.6.4 of [RFC6613] for more details.

パケットのsanity checkについては上で言及されているRFC 6613の下記の箇所が参考になります。Lengthフィールドが誤っていたような場合、パケット境界を厳密に決定することはできないと思いますが、あからさまな間違いは検出できると思います。また「1個前の」パケットがmalformedで「次の」パケットが切り出せないときは、コネクションを切断すべきであるようです。

> 2.6.4. Malformed Packets and Unknown Clients
> ...
> When TCP is used as a transport, decoding the "next" packet on a
> connection depends on the proper decoding of the previous packet.  As
> a result, the behavior with respect to discarded packets has to
> change.
> ...

RADIUSの場合は、ヘッダの固定長部分とAttributeのリストからなる可変長部分がありますが、AttributeはTLVの形式で、個々のAttributeがL(ength)を持つので、リストを舐めながらその和をとって固定長部分と足せば、パケット全体長がわかるはずと思います。それとヘッダ内のLengthを比較すれば、ヘッダとボディ部分とで辻褄が合っているかどうかを確認できるのではないかと思いますので、ヘッダ内のLengthの間違いはある程度は検出できそうな気がします。