headers
David Blacka | 8 Sep 2003 20:18

ANNOUNCE: Net::BeepLite 0.01

I have released Net::BeepLite 0.01.  From the README:

  Net::BeepLite is a lightweight implementation of a BEEP (RFC 3080, RFC
  3081) client/server framework.  This package is intended for
  implementing fairly simple BEEP clients and servers.  It does not
  attempt to be the last word on using BEEP in Perl.  Or to put this
  another way, this package does not make an attempt to support every
  feature or mode of operation possible within the BEEP specification.

  It does not use threading, and thus cannot directly handle multiple
  ansynchronous channels.  It does not directly support peer-to-peer
  operations.  Or at least not yet.

Even though this is a 0.01 release, the code is pretty complete and 
somewhat tested.  For now, the main webpage for it is 
<http://iris.verisignlabs.com> (this is shared by a few other projects 
supporting IRIS, which is a proposal in the IETF crisp working group).  It 
can be fetched from

<http://iris.verisignlabs.com/software/netbeeplite/Net-BeepLite-0.01.tar.gz>.

I have uploaded it to PAUSE, so hopefully it will be on CPAN at some point 
in the relatively near future.

--

-- 
David Blacka    <davidb <at> verisignlabs.com> 
Sr. Engineer    Verisign Applied Research
Permalink | Reply | 0 comments |
headers
David Blacka | 9 Sep 2003 18:37

ANNOUNCE: Net::BeepLite 0.01

I have released Net::BeepLite 0.01.  From the README:

  Net::BeepLite is a lightweight implementation of a BEEP (RFC 3080, RFC
  3081) client/server framework.  This package is intended for
  implementing fairly simple BEEP clients and servers.  It does not
  attempt to be the last word on using BEEP in Perl.  Or to put this
  another way, this package does not make an attempt to support every
  feature or mode of operation possible within the BEEP specification.

  It does not use threading, and thus cannot directly handle multiple
  ansynchronous channels.  It does not directly support peer-to-peer
  operations.  Or at least not yet.

Even though this is a 0.01 release, the code is pretty complete and 
somewhat tested.  For now, the main webpage for it is 
<http://iris.verisignlabs.com> (this is shared by a few other projects 
supporting IRIS, which is a proposal in the IETF crisp working group).  It 
can be fetched from

<http://iris.verisignlabs.com/software/netbeeplite/Net-BeepLite-0.01.tar.gz>.

I have uploaded it to PAUSE, so hopefully it will be on CPAN at some point 
in the relatively near future.

--

-- 
David Blacka    <davidb <at> verisignlabs.com> 
Sr. Engineer    Verisign Applied Research
Permalink | Reply | 0 comments |
headers
David Blacka | 12 Sep 2003 16:39

[ANNOUNCE] Net::BEEP::Lite 0.02

This is both a minor name change to the module (as suggested by one of the 
CPAN modules list maintainers), plus a few modifications for the TLS 
profile.

<http://iris.verisignlabs.com/software/netbeeplite/Net-BEEP-Lite-0.02.tar.gz>

or it can be fetched from CPAN.

--

-- 
David Blacka    <davidb <at> verisignlabs.com> 
Sr. Engineer    Verisign Applied Research
Permalink | Reply | 0 comments |
headers
David Blacka | 12 Sep 2003 16:43

[ANNOUNCE] Net::BEEP::Lite::TLSProfile 0.01

This is the first release of the TLS profile for the Net::BEEP::Lite 
module.

<http://iris.verisignlabs.com/software/netbeeplite/Net-BEEP-Lite-TLSProfile-0.01.tar.gz>
--

-- 
David Blacka    <davidb <at> verisignlabs.com> 
Sr. Engineer    Verisign Applied Research
Permalink | Reply | 0 comments |
headers
Rainer Gerhards | 15 Sep 2003 17:12
Gravatar

RFC3080 MSG/RPY Window

Hello WG,

I am implementing BEEP-Based
Permalink | Reply | 0 comments |
headers
Rainer Gerhards | 15 Sep 2003 17:18
Gravatar

RFC3080 MSG/RPY Window

Hello WG,

sorry for the duplicate - hit enter accidently...

I am implementing BEEP-based RFC 3195 (reliable syslog via BEEP). RFC
3195 uses MSG/RPY for message transfer. As I have seen and verified,
MSG/RPY is full-duplex that is there can be more than one MSG send
without an RPY.

This is a sample:

I: MSG 1
I: MSG 2
I: MSG 3
L: RPY 2
L: RPY 1
L: RPY 3

The sample is the exact sequence of what and when was send be initiator
(I:) and listener (L:). I see the value of having this ability,
especially in high-latency environments.

However, I did not see any window size mentioned for this. So it falls
back to a window of 2^32, which I think is a bit large.

Although this probably is not a big issue, I suggest that a window is
defined in the case RFC 3080 is revised some time.

If I am wrong with my comment, I would obviously like to get some
correction ;)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Huston | 15 Sep 2003 18:02
Picon

Re: RFC3080 MSG/RPY Window

Rainer,

The default window size for a channel on TCP is 4096. I believe this is
specified in RFC 3081.

One side note on your example, the RPY messages have to be sent in the same
order as the MSG messages. ANS messages are the only type that can be sent
interleaved/out of order.

--Huston

----- Original Message ----- 
From: "Rainer Gerhards" <rgerhards <at> hq.adiscon.com>
To: <beepwg <at> lists.beepcore.org>
Sent: Monday, September 15, 2003 9:18 AM
Subject: [BEEPwg] RFC3080 MSG/RPY Window

> Hello WG,
>
> sorry for the duplicate - hit enter accidently...
>
> I am implementing BEEP-based RFC 3195 (reliable syslog via BEEP). RFC
> 3195 uses MSG/RPY for message transfer. As I have seen and verified,
> MSG/RPY is full-duplex that is there can be more than one MSG send
> without an RPY.
>
> This is a sample:
>
> I: MSG 1
> I: MSG 2
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rainer Gerhards | 15 Sep 2003 18:27
Gravatar

RE: RFC3080 MSG/RPY Window

Hi Huston,

thanks for getting back to me. I have to say that I initially read 3080
so that a MSG should be acknowledged immediately but some discussion on
the syslog-sec WG list now makes me think different. Its just two
messages, so you may want to have a quick look:

http://www.mail-archive.com/syslog-sec%40employees.org/msg01285.html
http://www.mail-archive.com/syslog-sec%40employees.org/msg01286.html

I am a bit persistent here because not doing/understanding it right can
not only cause interop issue but also security issues - doing it wrongly
will certainly increase the risk for DoS attacks.

> The default window size for a channel on TCP is 4096. I 
> believe this is
> specified in RFC 3081.

Actually, I am talking about a *different window*. RFC 3081 deals with
the (advancing) seqno, not with msgno. There is no direct realtionship
between these two (or I did not get this from the RFC). I think I can
advance the seqno Window be sending a 3081 SEQ even when there are
unacknowledged msgnos. In fact, I even need to do so when the message
filling up the window is fragmented or even LARGER than the current 3081
windows. So I  believe the 3081 window applies to seqno but not to
msgno.

If so, that means the two are independent. If not, it would mean that
the somewhat lower-level seqno would affect the msgno window, which
could result in at least some complexity...
(Continue reading)

Permalink | Reply | 4 comments |
headers
Marshall Rose | 15 Sep 2003 18:41
Picon
Picon

Re: RFC3080 MSG/RPY Window

two things:

1. there is no relationship between msgno and seqno.

2. on a single channel, RPYs must come back in the same order that the
MSGs were received. look at the section called "Asynchrony" and "Within
a Single Channel".

/mtr
Permalink | Reply | 3 comments |
headers
Rainer Gerhards | 15 Sep 2003 18:51
Gravatar

RE: RFC3080 MSG/RPY Window

> two things:
>     
> 1. there is no relationship between msgno and seqno.
>     
> 2. on a single channel, RPYs must come back in the same order that the
> MSGs were received. look at the section called "Asynchrony" 
> and "Within
> a Single Channel".

argghh... I overlooked this. Sure, this clarifies greatly. However, I
still do not get if there is a windowing mechanism for msgno. I assume
even if there is none, a client should be clever enough not to send
10,000 messages without any reply - but this is not explicitely
outruled. My apologies if I am again missing the obvious, but I will
make sure I understand things crystal-clear as in my experience only
this helps to avoid (at least some) later security and interop issues.

I appreciate your help very much!

Rainer
Permalink | Reply | 1 comment |

Gmane