Subject: [midcom] MIDCOM Semantics: Open Issues

From: Martin Stiemerling <[email-masked]>
Date: Tue, 28 Jan 2003 14:49:26 +0100

Hi,

during end of november of last year, right after the midcom session in 
Atlanta, I've posted a list of open issues on the list. Only Tom 
responded to the question and some other people.
Here again is the list of issues, compiled into one email.

Martin

####
#1 PRR behaviour
The semantics propose currently that PRR does

- outside address/port allocation for a traditional NAT
- outside and inside address/port allocation for a twice NAT.

But it is really needed to allocate both sides of a twice NAT during a 
PRR transaction or is it sufficient enough to just allocate the outside 
address/port?

The semantics could be simplified if only the outside address/port  is 
allocated (indepent of middlebox type). Or do you see a scenario where 
both sides must be allocated during the PRR transaction?

####
#2 Group transaction
- Currently: Groups are created explicitly
- New proposal: Groups are created implicitly by PRR or PER transaction
- Impact on group transaction
   - GE and AGD can be dropped
   - GLC, GL and GS are kept
   - Default group can be dropped
   - No group liftime
   - Group state machine can be dropped

The whole group control can be simplified with dropping the explicity 
group establishment, so that groups are established during a PRR or PER 
transaction. The GLC transaction would than delete all policy rules 
belonging to the group when the lifetime is set to zero or change the 
lifetime of each policy rule (lifetime > 0)

####
#3 Wildcarding
Wildcarding is, due to several middlebox types and protocol types, a 
very tough topic. However, I'll but some thoughts on the list later.

####
#4 Return values in PER
What to return in PER transaction reply if inside and/or outside 
address/port are not allocated?
Examples: middlebox is packet filter (no inside or outside address/port) 
or traditional NAT (only outside address/port).

First choice: Return emtpy/none marker. This has the impact that the 
middlebox type is no longer transparent to the agent, i.e. the agent has 
to care what type of middlebox it is using

Second choice: Return external and/or internal endpoint addresses/port 
if appropriate.

####
#5 Split PER transaction
Currently the state transitions in the policy rule state machine from
- PRID UNUSED to ENABLED
- RESERVED to ENABLED
'using' the same PER transaction.
If you take a look into the semantics draft you will recognize that the 
PER for the RESERVED to ENABLED transition doesn't need all the 
parameters as the PER for UNUSED to ENABLED does need.
So it would make sense to separate them both into two different 
transactions:
PER1 for RESERVED to ENABLED
PER2 for PRID UNUSED to ENABLED
(The names PER1 and PER2 are just for the first clarification!)

This would significantly simplify the semantics for the PER transaction.

####
#6 Message Queuing
Is it required to add a 'first come first serve' message processing 
statement into section 2.1.2 "Atomicity" or is the text about 'atomic 
operation' sufficient enough?

####
#7 Capability exchange on Session Establishment
Currently the semantics document proposes these capabilitiy information:
- Type of middlebox
- IP address wildcard support
- Port wildcard support
- supported IP versions
- supported optional transactions
- policy rule persistency
- maximum policy rule lifetime
- name of the default group

Do you see any other capabilities that should be announced?

####
#8 Other open issues
Here is a list of minor issues:
- Separate IP protocol version and transport protocol type in PRR/PER 
transaction? Currently these are defined: IP4/IP6/UDP4/UDP6/TCP4/TCP6

- Need to support ICMP, IGMP, RSVP,... as protocol types?

- Encryption method in SE transaction. Should SE failure reply convey 
supported encryption methods? Curently a 'don't understand your 
encryption' is returned.

- The security considerations need some further elaboration

_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: "Christopher A. Martin" <[email-masked]>
Date: Tue, 28 Jan 2003 13:38:53 -0600

Inline

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Martin Stiemerling
Sent: Tuesday, January 28, 2003 7:49 AM
To: [email-masked]
Subject: [midcom] MIDCOM Semantics: Open Issues

Hi,

Martin

####
#1 PRR behaviour

<CM> I think that both sides must both be allocated, as Twice NAT
addresses a very specific scenario where not allocating it can cause
potential address conflict or incorrect packet routing, as described in
RFC 2663 in the Twice NAT section, pages 13 and 14. The bindings must be
reserved in both directions concurrently to insure the integrity of the
nat bindings during communication.
</CM>

####
#2 Group transaction

<CM>This seems acceptable at first read, will need to dwell on this
more, initial reaction is that this is an acceptable change</CM>

####
#3 Wildcarding

####
#4 Return values in PER

Second choice: Return external and/or internal endpoint addresses/port 
if appropriate.
<CM>Second choice would be preferable in my opinion if there is a need
to map this information for some sort of state, or for redundant
solutions that may require mirroring this state between other
middleboxes, but that is probably not what you are asking about
here</CM>

<CM>This is all I have for now due to time limitations Will try to
address the rest/and or clarify my thoughts on the above later today or
in the morning.</CM>

####
#5 Split PER transaction

####
#6 Message Queuing

####

####
#8 Other open issues

---

From: "Juergen Quittek" <[email-masked]>
Date: Tue, 28 Jan 2003 22:26:36 +0100

Christopher,

Thanks a lot for commenting. Please see replies inline.

-- Christopher A. Martin wrote on 28 January 2003 13:38 -0600:

># 1 PRR behaviour

Completely agreed, but this is not the issue. Maybe Martin's 
phrasing is a bit misleading, but the question is about whether 
or not the reservation needs to be for both sides IN ADVANCE. 

The PRR transaction does not establish a binding or pinhole, 
but it just reserves IP addresses to be used for bindings by 
later PER transactions.

This strage transaction became necessary after we found a scenario 
(see section 4.2) where for one side ADVANCED reservation of 
adresses was required BEFORE sufficient information was available 
for establishing an address binding.

The reason why Martin asks is that we only found a scenario where 
such a reservation is required on one side of the (twice-) NAT.

However, being conservative, we designed te PRR transactions to 
perform reservations on both sides, because we cannot (at least 
not yet) exclude that on some day someone runs into a scenario 
where advance reservation on both sides is required. 

Now we are asking the working group whether to be conservative 
and prepared for a scenario that might never occur, or to just 
cover scenarios we know already today. In the latter case, we 
could reduce the PRR transaction to reserve addresses on only 
one side of the NAT.

># 2 Group transaction

It is also what the authors of the document agree on and already
started to work on.

    Juergen
-- 
Juergen Quittek        [email-masked]        Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.ccrle.nec.de
_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom