Draft Minutes of MIDCOM IETF-59 Session - Part 1

Below is part 1 of the combined minutes of Brian Stucker and Rohan Mahy from
the meeting (with a few minor updates and formatting).  Thanks to Brian and
Rohan for taking minutes. As well, thanks to Eric Burger for serving as the
Jabber scribe, so our WG chair could participate in the meeting.  Please
direct any comments to the list.

Regards,
Mary H. Barnes
[email protected]


Part 1: 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. 
             
--- End Part 1 minutes ---