Minutes of the midcom session at IETF59
---------------------------------------

Seoul, Korea, Tuesday, March 2nd, 2004, 14:15 h - 15:15

AGENDA:
            
Agenda bashing/note-taker/blue sheets
            
- Administrivia:
  - Agenda accepted as proposed. Rohan Mahy / Brian Stucker taking notes.
  - Mary Barnes acting chair in absence of Melinda Shore.

AGENDA ITEM: Status update - Mary Barnes (Chair)
 
       
draft-ietf-midcom-protocol-eval-06.txt
       draft-ietf-midcom-semantics-07.txt
         
   - MIDCOM protocol evaluation: updated references, now blocking on 
publication of NAT MIB.
   - MIDCOM semantics: IESG review.
            
            
AGENDA ITEM: STUN futures - Jonathan Rosenberg
            
   - Jonathan Rosenberg: Cullen did an analysis of NATs and found that
                 STUN may not apply correctly to the reality of what NATs 
are actually out there doing.
   - Time to revise STUN?
       - NAT detection algorithm is brittle
            - The NAT detection algorithm doesn't fully describe 
implemented NATs. We've now found lots of non-standard behavior, much of it 
documented in 
draft-jennings-midcom-stun-results.
            - Remove from STUN
            - Produce diagnostics document on ideas for using STUN.
       - Introduce XOR-based protection of mapped address
       - Discussion:    
            - Jonathan Rosenberg: Trying to do a generic ALG, which is a bad 
idea. In order to protect us from ALGs, garble the IP addresses 
embedded in the message such that they will be ignored by the ALG 
(hopefully they won't try to figure out what we're doing and get around 
it).
            - Rohan Mahy: Had we made the change at the beginning, I could 
have gone either way, as it is we have a backwards compatability 
problem.
            - Jonathan Rosenberg: Would need to add a new tag 
(NEW_CHANGED_ADDRESS) to deal with this problem (basically ignore the old 
addresses, and not the new one), if both are present, look at old 
addresses. Not many NATs with this problem and they are tending to go 
away.
            - Rohan Mahy: Let sleeping dogs lie, and try to get rid of the 
small number of broken NATs. Not opposed to this work.
            - Jonathan Rosenberg: Worried about future revisions of 
hardware starting to behave badly. Client sends a STUN request, and the 
response includes both a new XORed address and the old one so it's 
backwards compatible (icky that the data is duplicated but oh well).
            - Francois Audet: There's parts of this that are extremely 
useful, so I don't think we want to remove everything from the 
diagnostic side of things. 
            - Jonathan Rosenberg: This is more of an ICE discussion, where 
the only way that you know you're not on a NAT is to test.
            - Francois Audet: I still think we need to revise the 
diagnostic to know that they're accurate, and not ditch it entirely.
            - Jonathan Rosenberg: They'll always not be current because 
NATs will change their behavior in the future and we'll always be 
behind.
            - Francois Audet: I don't buy that, the type of really nasty 
things we're seeing is getting rarer.
            - Jonathan Rosenberg: The technique for figuring out that a 
STUN allocated address is correct is brittle/random because of 
misclassified NATs in which case you think you don't need a relay when you 
do.
            - Francois Audet: You may discover that there's no NAT at all. 
That information is useful, so let's not ditch it.
            - Jonathan Rosenberg: That's handy, but you may still be wrong in 
the STUN assessment.
            - Francois Audet: It allows you to figure out in an 
enterprise environment that there's no NAT, so we can eliminate extra 
steps.
            - Jonathan Rosenberg: If they're behind a symmetric NAT, with 
ICE, you still won't need a relay.
            - Francois Audet: The entity that knows the two 
endpoints, may be able to figure out from access to the diagnostic 
information may allow you to know both ends are not behind a NAT. We 
should qualify what it tells us.
            - Jonathan Rosenberg: I don't want to continue solutions that 
require me to keep having to revise this STUN draft all the time. You may 
think you're not behind a NAT but you are (both sides use the same IP 
address space).
            - Unknown speaker at microphone: You don't separate them, you 
keep it up to date as much as you can.
            - Jonathan Rosenberg: Still need STUN because you MAY get an 
address you can use, where ICE will prove you have an address you can use. 
Most implementations of STUN is to do the diagnostics, and then 
allocate the address. Splitting the document apart makes it clear that this 
is not what STUN is about.
            - Rohan Mahy: Several of the sort of broken cases have to do 
with multiple devices behind the same NAT. You can really detect those 
without having two IP address on the same device. That said, I would be 
happy to have that documented somewhere even if it used a single IP 
address.
            - Jonathan Rosenberg: Scope needs to be very clearly defined as 
to what it doesn't do and what it does.
            - Mary Barnes (Chair): So what you're proposing is to split the 
two into a diagnostics and allocation draft.
            - Rohan Mahy: Will take on the diagnostics draft, may 
delegate to Cullen if he wants to do it.
            - Jon Peterson (Area Director): The charter is getting thin, 
we're winding down.

         - HUM VOTE ON SPLITTING THE DOCUMENT (not a WG item): 
            - Rohan Mahy: Clairifying question, document is updated to say 
these sections are non-normative.
            - Jonathan Rosenberg: I can't do anything about the RFC. The new 
one will replace the old one with a missing chunk of text.
            - Rohan Mahy: You can use updates RFC.
            - Jonathan Rosenberg: Problem is that we don't want to 
include the diagnostics.
            - Eric Burger: Melinda preferred it's a WG or not.
            - Jon Peterson: Let's ask if anyone objects to this plan or 
not.
            - Francois Audet/Cedric Aoun: First document includes 
protocol and XOR, other document would be informational around the 
diagnostics.
         - NO HUM VOTE TAKEN. Was deemed not necessary, we're past that 
point.
            


AGENDA ITEM: What do we do with 
draft-ietf-midcom-mib-analysis-01.txt? (Mary Barnes)

  - We had two MIBs, now we have one.

  - WG MIB analysis document updated prior to IETF-58 to reflect the 
current status (2 MIBs) and additional detailed analysis of the 
applicability of the MIDCOM semantics to the NAT mib:
      - 
Draft-ietf-midcom-mib-analysis-01.txt

  - Progress since IETF-58:
    -NATMIB under IESG review
    -FW config split from IPSEC policy config MIB
    -Single MIB document
            
  - Proposal: do some clean up, and combine the two as one document going 
forward.

  - Discussion:
            
    - Juergen Quittek: I think the there is some relationship with NAT 
MIB...
            
    - Mary Barnes (Chair): We didn't get a lot of reusability of the other 
MIB.
            
    - Result of brief discussion: No objections.

            
AGENDA ITEM: MIB document 
draft-ietf-midcom-mib-00.txt (Juergen Quittek)

  - What we did was to take the three individual MIBs and integrate them 
into one big MIB.
  - The general approach was to start from the MIDCOM semantics.
    - Tried to map the semantics to a MIB module.
    - Added:
       - Means for firewall configuration
       - Resource usage information
       - Statistics
    - Structured into tables
       - The major means provided by SMI (Structure of Management 
Information)
    - MIB Module Overview:
       - Session Tbale, Rule table, group table, capabilities table (IP 
interface configuration) filed uder implementing MIDCOM semantics.
   - Summary of the basics:
     - A MIDCOM entry needs to insert it's own entry in the session table 
before opening a session. Without this entry, MIDCOM agent cannot act on 
policy rules.
     - Rule table has one entry for each policy rule. Indexed by session 
owner, groupindex, rule index. Objects in entry cover all parameters of PER 
and PRR transactions. Explains that if a NAT is involved, what the 
interface is. Added a max idle time to describe how long the NAT session 
will be left idle before closing. Added rule storage time to allow rules to 
expire out of the table (they're left in there, but inactive after expiry 
for a period of time).
     - Group table: one entry per policy rule group, just a shortcut for the 
rule table.
     - Notifications: Informing the MIDCOM agnet about state changes at the 
middlebox. Session termination, policy rule event (lifetime change, 
etc)....
     - Interface Config table: provides middlebox capability 
information per IP interface (IP version, wildcarding support, 
firewall, NAT).
     - Firewall config table: config of the enforcement of policy rules 
into firewalls.
        - Group ID and priority of FW rules derived from MIDCOM policy 
rules.
        - Should be read-only for MIDCOM agents.
        - Would be writable for middlebox admin.
     - Resource Table: links MIDCOM policy rules in the rules table to 
resources in the NAT MIB.
     - MIDCOM statistics: session statistics: rejected, current, total 
sessions. Policy rule stats, etc..

   - Open Issues:
      - Security considerations not complete!
      - Firewall config and resource usage indication is  generic 
(waiting for input form firewall community,  eager to hear back). Don't 
know if this is  representative of what's out there. Need to have  
firewall community to speak up, currently generic.
      - Explain use of USM and its relation to  
midcomSessionOwner and clarify that the MIDCOM agent  
authenticates, not the SNMP manager. How SNMP  security is exploited will be 
improved in next version.
      - Is MaxIdleTime an input parameter to PRR? Question  was raised by 
Suresh, not present, so it's left open.


  - Questions:
     - Rohan Mahy: What was the overall.. what was the reaction from the 
firewall community, are they interested?
     - Juergen Quittek: yes. Suvesh is from the NAT community. Do you mean 
the manufacturers or standards?
     - Rohan Mahy: Manufacturers.
     - Cedric Aoun: In which context is this thing targeted for, 
management or monitoring, perhaps they're not clear on what this is for?
     - Jurgen Quittek: People with NATs want something like this, but 
perhaps not a MIDCOM MIB. Couldn't tell.
     - Mary Barnes (Chair): Please take a look at this, even if you're not a 
MIB expert. Look at the data model. If you wanted to implement it could you 
do what you need to do for MIDCOM.

                           
AGENDA ITEM: Way forward (Mary Barnes)

  - Completing the MIB will complete the MIDCOM charter at this time. We 
need people to look at it, might want to wait for next rev before the 
review due to security considerations. (Dave Harrington volunteers)
  - I will contact folks to read it on the long plane ride back. 
Probably will be finished up in May.

 Discussion:
  - Mary Barnes: Any other business?       
  - Rohan Mahy: I think there are a number of folks that are 
interested in non-MIB MIDCOM like protocols. I was planning something in 
after talking with a couple of folks. Procedurally, should I bother or not? 
Are others interested?
  - Jurgen Quittek: Maybe how many have seen the SIMCO draft (complete 
implementation of the MIDCOM semantics), so maybe we're interested.
  - Jon Peterson (Area Director): Procedurally speaking, charter and 
criteria were extraordinarily well documented. Probably does not fit. 
However, at such time the IESG has reviewed the the MIDCOM MIB, then we can 
look at alternative approaches. I don't think we should put an 
alternative approach at this time.
  - Eric Burger: Exactly when is this cut-off be able to happen.
  - Mary Barnes (Chair): Propose that you must contribute to the MIB 
before you can contribute to an alternative.
  - Jon Peterson (Area Director): Wishes he could authorize that 
proposal. RFC editor has to have published the MIB before an 
alternative could become a WG document. Individual contributions could 
proceed in parallel, but RFC editor isn't going to want to see two things at 
the same time.
  - Jurgen Quittek: We'll submit something next week (SIMCO).
  - Jon Peterson (Area Director): It's not that I can't stop you, even if I 
wanted to. Not appropriate to charter non-MIB approaches, however after MIB 
is approved, may be reasonable to request individual publication of other 
approaches.
  - Mary Barnes (Chair): Final plea, please look at this document.
  - Jonathan Rosenberg: While on subject of controvertial 
activities, can someone send references to ITU-T activities for NAT/FW 
traversal.
  - Eric Burger: As well, ETSI is looking at this for H.248.
  - Roni Even: It may be that they end with BCP document, but may also be 
that it specifies solutions around H.323, H.245 signalling that SIP 
doesn't have. New question in SG.16, still very early.
            
--- MEETING CONCLUDES ---