Subject: [Megaco] H.248.37 - Latch versus Relatch

From: Juergen Stoetzer <[email-masked]>
Date: Tue, 11 Jul 2006 10:40:00 +0200

Hello Christian and Christer,

Below are some questions to H.248.37. Guess you as former editor/main
contributors may have the best insights in the package design and
background information.

Thanks a lot in advance for any ideas and clarifications you may give!
Best regards,
Juergen Stoetzer

--------------------------------------

The package H.248.37 introduces the signal ipnapt/latch with parameter napt.
This parameter napt may have the values OFF, LATCH and RELATCH.
The parameter value LATCH is defined as

"When the NAPT processing signal with the NAPT parameter on a termination/stream
is set to LATCH, then this results in the MG ignoring the addresses received in
the RemoteDescriptor. Instead the MG will use the source address and source port
from the incoming media stream (i.e., from the other terminations) as the
destination address and destination port of the outgoing application data."

The value RELATCH is defined to imply a similar gateway behaviour as the value
LATCH with the difference

"... that the MG will check for a change of source IP address/port
on the incoming media stream. If/when a new source IP address and/or port are
detected, then they will be used as the destination address and port for future
outgoing packets. After re-latching, any packets received on the old source
address and port combination will be considered as malicious and will be treated
accordingly (discarded and counted)."

Thus, the RELATCH case emphasizes the change of source IP address/port.
Does this mean that RELATCHing is only possible/allowed after a first
LATCHing was already performed and thus the used destination IP address/port
for outgoing packets are in fact already different from the ones in the
Remote descriptor?

In case the stream mode of the corresponding termination equals SendReceive
it seems to be clear that the signal ipnapt/latch{napt=LATCH} completes
(generates the g/sc event if requested by the MGC) at the moment the next
IP packet is received by the corresponding termination. From that moment
onwards the source address/port of that received packet will then be used as
destination address/port for outgoing packets.

In case a Remote descriptor is already specified, is this behaviour independent
of whether the source address/port of received IP packet is equal to or
unqual to the IP address/port specified in this Remote descriptor?
That is, if the source address/port of received packet is equal to
the address/port in the Remote descriptor, does the signal
ipnapt/latch{napt=LATCH} complete nevertheless?

Is this also the case if the stream mode is equal to ReceiveOnly?
Or does the signal ipnapt/latch{napt=LATCH} in this case only complete
at the moment the first IP packet is received _after_ the stream mode
was changed to SendReceive?
In other words, does the reception of the new address trigger
the signal completion event or is it the first packet which is actually sent
to the new address?

When does the signal ipnapt/latch{napt=RELATCH} complete?

Does it make sense to generate an IP termination with a Signals descriptor
containing the signal ipnapt/latch{napt=RELATCH}, i.e. with RELATCH parameter?
That is to say, can the very first IP packet received by corresponding
termination be considered to have a 'new'/'different' source IP address/port?

Let's assume an IP termination (Ia profile terminology) is created only
with a Local descriptor and ipnapt/latch signal:

Add = ip/<group>/<interface>/$ {
   Signals{ipnapt/latch{napt=LATCH}},
   Media {
     LocalControl {
       Mode = SendReceive
     },
     Local {
       ....
     }
   }
}

Is this IP termination then allowed to start sending out IP packets after having
received the first incoming packet (and after having performed latching with the
received source address/port) since the Stream Mode equals SendReceive but
before having received a Remote descriptor?

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

---

From: "B Venkat S.R Swamy" <[email-masked]>
Date: Tue, 11 Jul 2006 19:39:10 +0530

Hi

I rather have a totally different query on this issue, why the latch item has been declared as a signal, rather than a property of the localcontrol descriptor as

done in NAT traversal package of the gate control(ETSI TS 102 333) defined by TISPAN. This way, MGC should not bother to send RELATCH parameter

to MG and there are no issues of reporting signal completion to MGC.

Once property is set on stream, MG would always look into incoming stream's source address to send the packets to the peer entity. Although this

might have a little impact on performance to check every incoming packet source address.

regards

B Venkat S.R Swamy

Senior Technical Leader

Flextronics Software Systems

Phone: +91-124- 4176213

Fax: +91-124-4300247

web: www.flextronicssoftware.com

Juergen Stoetzer <[email-masked]>

background information.

Best regards,

Juergen Stoetzer

Remote descriptor?

to the new address?

Media {

LocalControl {

Mode = SendReceive

},

Local {

....

}

}

}

Megaco mailing list

[email-masked]

*********************** FSS-Restricted ***********************

"DISCLAIMER: This message is proprietary to Flextronics Software

Systems Limited (FSS) and is intended solely for the use of the

individual to whom it is addressed. It may contain privileged or

confidential information and should not be circulated or used for

any purpose other than for what it is intended. If you have received

this message in error, please notify the originator immediately.

If you are not the intended recipient, you are notified that you are

strictly prohibited from using, copying, altering, or disclosing

the contents of this message. FSS accepts no responsibility for

loss or damage arising from the use of the information transmitted

by this email including damage from virus."

---

From: "Maridi Raju Makaraju\(Raju\)" <[email-masked]>
Date: Tue, 11 Jul 2006 09:38:46 -0500

Hi,
  Hi

  I rather have a totally different query on this issue, why the latch item
has been declared as a signal, rather than a property of the localcontrol
descriptor as
  done in NAT traversal package of the gate control(ETSI TS 102 333) defined
by TISPAN. This way, MGC should not bother to send RELATCH parameter
  to MG and there are no issues of reporting signal completion to MGC.

This probably was done this way to make sure that a single "rouge spoof
packet" from some hacker to redirect all
packets to a wrong ip/port. If the user really wants to change the ip/port
then the session layer would know
this (via re-INVITE in case of IMS) and it issues a relatch. Without this
control it's not safe to "latch always" using
a property parameter rather than a "signal".

-Raju

  Once property is set on stream, MG would always look into incoming
stream's source address to send the packets to the peer entity. Although
this
  might have a little impact on performance to check every incoming packet
source address.

  regards
  B Venkat S.R Swamy
  Senior Technical Leader

  The package H.248.37 introduces the signal ipnapt/latch with parameter
napt.
  This parameter napt may have the values OFF, LATCH and RELATCH.
  The parameter value LATCH is defined as

  "When the NAPT processing signal with the NAPT parameter on a
termination/stream
  is set to LATCH, then this results in the MG ignoring the addresses
received in
  the RemoteDescriptor. Instead the MG will use the source address and
source port
  from the incoming media stream (i.e., from the other terminations) as the
  destination address and destination port of the outgoing application
data."

  The value RELATCH is defined to imply a similar gateway behaviour as the
value
  LATCH with the difference

  "... that the MG will check for a change of source IP address/port
  on the incoming media stream. If/when a new source IP address and/or port
are
  detected, then they will be used as the destination address and port for
future
  outgoing packets. After re-latching, any packets received on the old
source
  address and port combination will be considered as malicious and will be
treated
  accordingly (discarded and counted)."

  Thus, the RELATCH case emphasizes the change of source IP address/port.
  Does this mean that RELATCHing is only possible/allowed after a first
  LATCHing was already performed and thus the used destination IP
address/port
  for outgoing packets are in fact already different from the ones in the
  Remote descriptor?

  In case the stream mode of the corresponding termination equals
SendReceive
  it seems to be clear that the signal ipnapt/latch{napt=LATCH} completes
  (generates the g/sc event if requested by the MGC) at the moment the next
  IP packet is received by the corresponding termination. From that moment
  onwards the source address/port of that received packet will then be used
as
  destination address/port for outgoing packets.

  In case a Remote descriptor is already specified, is this behaviour
independent

  the signal completion event or is it the first packet which is actually
sent
  to the new address?

  Does it make sense to generate an IP termination with a Signals descriptor
  containing the signal ipnapt/latch{napt=RELATCH}, i.e. with RELATCH
parameter?
  That is to say, can the very first IP packet received by corresponding
  termination be considered to have a 'new'/'different' source IP
address/port?

  Is this IP termination then allowed to start sending out IP packets after
having
  received the first incoming packet (and after having performed latching
with the
  received source address/port) since the Stream Mode equals SendReceive but
  before having received a Remote descriptor?

---

From: [email-masked]
Date: Wed, 12 Jul 2006 08:30:52 +0200

Background: "Signal vs Property"
   The initial design of the ipnapt package was based on a property, but
   later changed to a signal.

   See  T05-SG16-050726-D-0132 "Proposed changes for an IP NAT Traversal
   Package in draft new H.248.37"
   http://www.itu.int/md/meetingdoc.asp?lang=en&parent=T05-SG16-050726-D-0132

   2.2      Change of NAPT Property to a Signal

   The NAPT property contains the value RELATCH. This enables the MGC to
   order the MG to latch when the incoming media indicates a remote address
   changes. This could happen several times in the duration of a call. The
   problem is that when a subsequent RELATCH is sent to the MG, it will
   ignore this according to current H.248 rules. In order work around this
   behaviour the MGC could send a MOD.req with NAPT=OFF and then a
   subsequent MOD.req with NAPT=RELATCH. However this would actually turn
   off latching and the MG would loose the original address so the MG may
   actual RELATCH to this original address. Therefore it is proposed that
   the NAPT processing is implemented as a brief signal. This fits better
   as latching is a "single shot" behaviour. It has the benefit of only
   requiring a single command to achieve the required behaviour. The use of
   a signal is seen as appropriate as signals as H.248.1 section 7.11
   indicates that signals may be bearer related e.g."Signals are
   MG-generated media such as tones and announcements as well as
   bearer-related signals such as hookswitch". Latching is associated with
   media bearers. H.248.9 also uses signals to perform procedural calls for
   example "Delete Persistent".

- Albrecht

                      "Maridi Raju                                                                                                
                      Makaraju\(Raju\)         To:      "B Venkat S.R Swamy" <[email-masked]>,                   
                      "                        <[email-masked]>, <[email-masked]>                  
                      <[email-masked]         cc:      Albrecht SCHWARZ/DE/ALCATEL@ALCATEL, [email-masked],               
                      om>                      [email-masked]                                                                    
                                               Subject: RE: [Megaco] H.248.37 - Latch versus Relatch                              
                      11.07.2006 16:38                                                                                            

Hi,

 Hi

-Raju

 regards
 B Venkat S.R Swamy
 Senior Technical Leader

 (Embedded image moved to file: pic27220.gif)Juergen Stoetzer
 <[email-masked]>

---

From: Christian Groves <[email-masked]>
Date: Mon, 17 Jul 2006 12:12:06 +1000

Hello Juergen,

Please see my replies below marked CNG. As I'm no longer with Ericsson, 
Christer may have a seperate view.

Regards, Christian

> Thanks a lot in advance for any ideas and clarifications you may give!

[CNG] Not necessarily. RELTACH enables the MG to keep receiving packets 
and then immediately LATCH to packets from a new source address.  If the 
MGC sends LATCH it immediately latches to the next packet. However I 
think the most likely use case is LATCH followed by RELATCH.

> ipnapt/latch{napt=LATCH} complete nevertheless?

[CNG] Yes I would say the signal complete would be returned irrespective 
of the address in the remote descriptor.

> the signal completion event or is it the first packet which is 

[CNG] Signals are usually independent of stream mode. The signal 
completion would be when packets are received as that is what drives the 
latching process.

> When does the signal ipnapt/latch{napt=RELATCH} complete?

[CNG] When the MG detects a packet coming from a different address for 
the particular stream.

> before having received a Remote descriptor?

[CNG] Yes and no. The MG has the remote addresses at this stage but no 
description of the media type etc that is usually contained in the 
Remote Descriptor. Latching means you ignore the addresses but not the 
whole remote descriptor contents.

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 20 Jul 2006 09:42:59 -0400

I agree that LATCH/RELATCH would have the nature of brief signals. They 
are effectively remote procedure calls, like many of the signals in the 
Advance Media Server Packages (H.248.9).

>    example "Delete Persistent".
...