headers
Jonathan Rosenberg | 3 Mar 2003 16:47

Re: STUN ietf-draft 05

Thanks for the feedback. I will get it changed to 0x01. Thanks for 
catching this!

-Jonathan R.

Kristoffer Gronowski wrote:
> We have been testing STUN clients and servers on SipIt in Stockholm this week.
> The majority used 0x01 for IPv4 so Rohan Mahy suggested that we should report this as
> a typo. I believe that it would be more people out there that feels the same way.
> It's not a big problem since one have to redo and check the current implementation when STUN
> becomes a RFC.
> But my vote is to change it back to 0x01.
> 
> //Regards Stoffe!
> 
> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen <at> dynamicsoft.com]
> Sent: den 28 februari 2003 02:29
> To: Panayiotis A. Thermos
> Cc: midcom <at> ietf.org; petrovic <at> corp.earthlink.net
> Subject: Re: [midcom] STUN ietf-draft 05
> 
> 
> I wish I had a better answer, but I have no idea why this changed. It 
> could be that it was a copy-paste error that got snuck in when that 
> paragraph was rewritten.
> 
> STUN is now in auth48, so it is conceivable to change it back, although 
> I am not sure that is the right thing. Can people let me know which 
> value they are using in their implementations today?
(Continue reading)

Permalink | Reply | 501 comments |
headers
Juergen Quittek | 5 Mar 2003 19:04
Picon

I-D ACTION:draft-stiemerling-midcom-simco-03.txt (fwd)

Dear all,

In parallel to the new version of the semantics, we submitted
a new verison of our experimental SIMCO protocol that implements
the updated semantics.

    Juergen

---------- Forwarded Message ----------
Date: 05 March 2003 06:30 -0500
From: Internet-Drafts <at> ietf.org
To: IETF-Announce
Subject: I-D ACTION:draft-stiemerling-midcom-simco-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Simple Middlebox Configuration (SIMCO) Protocol
                          Version 2.0
	Author(s)	: M. Stiemerling, J. Quittek
	Filename	: draft-stiemerling-midcom-simco-03.txt
	Pages		: 20
	Date		: 2003-3-4
	
This memo specifies the Simple Middlebox Configuration (SIMCO)
protocol for configuring Network Address Translators (NATs) and
firewalls dynamically to create address bindings and open pinholes.
NATs and firewalls are a problem for applications using voice and
video streaming, such as IP telephony, because they need to establish
voice or video channels dynamically. The SIMCO protocol allows
clients to send requests for this purpose to serving NATs and/or
(Continue reading)

Permalink | Reply | 0 comments |
headers
Melinda Shore | 10 Mar 2003 18:08
Picon
Favicon

Semantics document

You may have noticed the announcement of a revision of the
semantics document.  The URL is
http://www.ietf.org/internet-drafts/draft-ietf-midcom-semantics-01.txt.
Please have a look at it, particularly section 8, and bring
any discussion you may have to the mailing list.  We'd like
to get this document through WG last call in May.

The identified open issues are:

     - Is IP wildcarding required? What would be application sceanrios
       for IP wildcarding?

     - Further elaborate the capability information sent from the
       middlebox to the agent at session setup.  What further capability
       information should be sent?

     - Is there a need to support enabling ICMP, IGMP, RSVP, ...?

     - In case of a failure of the SE transaction because the encryption
       method suggested by the agent is not supported by the middlebox:
       Should the middlebox reply with a list of supported encryption
       methods?

     - Further elaborate section on security considerations.

     - Shall the agent be able to specify parameters for protection
       against denial of service attacks? Examples are
          - maximum total number of TCP connection setups allowed
          - maximum number of TCP connection setups per minute
          - maximum number of UDP packets per minute
(Continue reading)

Permalink | Reply | 0 comments |
headers
Harrington, David | 11 Mar 2003 01:11
Favicon

firewall mib/ipsec policy config mib

Hi,

The IPSec Policy Configuration MIB (and related non-mib documents) are likely to advance to Proposed
Standard status soon. Some of this mib's objects may apply to firewall and ACL configuration. 

It would be good if the WG could review the mib design and comment about its applicability in the MIDCOM
environment. Note that an implementation has already been done to work with NET-SNMP.

Here's the mib: 
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-ipsp-ipsec-conf-mib-06.txt

Thanks,
dbh

David Harrington
Network Management Architect
Office of the CTO
Enterasys Networks
Permalink | Reply | 1 comment |
headers
Melinda Shore | 11 Mar 2003 20:14
Picon
Favicon

Meeting agenda

I've appended the current version of the agenda for next
week's meeting.  Please let me know of any glaring
admissions, etc.  

Again, we'd like to get the semantics document into WG last
call as soon as it's ready, so let's try to get those open
issues wrapped up.

Thanks,

Melinda

Middlebox Communication WG (midcom)

Tuesday, March 18 at 15:45-16:45
================================

CHAIR: Melinda Shore <mshore <at> cisco.com>

Agenda-bashing

Status update
    STUN
    Protocol evaluation 

midcom mib

Semantics document
    draft-ietf-midcom-semantics-01.txt
(Continue reading)

Permalink | Reply | 0 comments |
headers
Melinda Shore | 12 Mar 2003 00:52
Picon
Favicon

Semantics document in Palm DOC format

Can be found at http://www.employees.org/~shore/palmdocs.html

Melinda
Permalink | Reply | 0 comments |
headers
Rohit Rohit | 12 Mar 2003 06:37

proposed changes for the new nat-mib draft

Hi, 

  Here are the list of changes, we are planning for the next version 
  of the NAT MIB draft.

  1. NAT MIB will be basically focused on TCP and UDP protocols. 

  2. Incorporate David's comments which include renaming of 
     natConfAddrMapIndex to natConfAddrMapPrecedenceIndex.

  3. Add a section to explain Address-map direction and 
     BIND direction for different flavors of NAT.

  4. Add description for the RowStatus objects modification.

  5. Fix the threshold naming inconsistency and other
     typo errors.

  Let us know of any other comments, which should be addressed in the
  next version of the NAT-MIB.

  Thanks
  Rohit
Permalink | Reply | 0 comments |
headers
Martin Stiemerling | 17 Mar 2003 18:52
Picon

Changes in the semantics I-D

Hi,

as posted earlier on this list a new version of the MIDCOM semantics I-D 
is available. The major changes in this version are:

- Complete reworked group behaviour:
As agreed the groups are not created explicitly by the Group 
Establishment (GE) transaction anymore, but they are created implicit 
through a PER or PRR transactions type. A group is deleted after the 
last policy rule of this pariticular group has been deleted. There is no 
lifetime of a group anymore. The lifetime a group is equal to the 
maximum of all policy rule lifetimes. So the GE transaction is dropped, 
as well as the AGD notification.

- reworked the draft regarding wildcarding, address and transport 
address in order to provide a more clear view on this topic

- adapted the examples to latest changes

Martin

--

-- 
Martin Stiemerling

NEC Europe Ltd. -- Network Laboratories  Stiemerling <at> ccrle.nec.de
IPv4: http://www.ccrle.nec.de  IPv6: http://www.ipv6.ccrle.nec.de
Permalink | Reply | 18 comments |
headers
Scott Bradner | 18 Mar 2003 19:15
Picon
Favicon

stun


its out

3489 STUN - Simple Traversal of User Datagram Protocol (UDP) Through
     Network Address Translators (NATs). J. Rosenberg, J. Weinberger, C.
     Huitema, R. Mahy. March 2003. (Format: TXT=117562 bytes) (Status:
     PROPOSED STANDARD)

congrats to all!

Scott
Permalink | Reply | 0 comments |
headers
Bob Penfield | 18 Mar 2003 20:16
Favicon

semantics does not allow agent to specify middlebox function

In section 2.3.6 the document states:

      When receiving the request, the middlebox determines how many
      address (and port) reservations are required based on its
      configuration.

I believe that section 2.2.2 of RFC 3304 requires that the agent be able to
indicate to the middlebox the desired function.

   The Midcom protocol must support the ability of an agent to install a
   ruleset that governs multiple types of middlebox actions (e.g.
   firewall and NAT).

   This states that a the protocol must support rules and actions for a
   variety of types of middleboxes.  A Midcom agent ought to be able to
   have a single Midcom session with a middlebox and use the Midcom
   interface on the middlebox to interface with different middlebox
   functions on the same middlebox interface.

This clearly states that the protocol must support a scenario where a given
middlebox provides multiple functions and that the agent can specify which
of those functions it wants for a given ruleset basis.

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
(Continue reading)

Permalink | Reply | 12 comments |

Gmane