Subject: [tsvwg] Fwd: Review: draft-manner-tsvwg-gut-00

From: Bob Briscoe <[email-masked]>
Date: Wed, 03 Feb 2010 18:15:31 +0000

Jukka, Nuutti,

[ignore previous email]
I missed a couple of nits. Added inline at the end...

>Date: Wed, 03 Feb 2010 12:23:31 +0000
>To: Jukka MJ Manner <[email-masked]>, [email-masked]
>From: Bob Briscoe <[email-masked]>
>Subject: Review: draft-manner-tsvwg-gut-00
>Cc: "tsvwg IETF list" <[email-masked]>
>
>Jukka, Nuutti,
>
>I've done a detailed review of gut-00 below:
>
>==1. It's worth stating goal(s) more explicitly==
>E.g.
>a) mitigating problem of existing NATs, while still allowing 
>middleboxes that deliberately want to block to do so (see previous 
>email in response to Pasi)
>
>==2. No magic number?==
>
>I would prefer GUT without the magic number. Here's the trade-off:
>* Magic number wastes header space always
>* No magic number wastes receiver processing very occasionally
>
>If the magic number closed a DoS vulnerability, it would be worth 
>it. But as you say in the draft, DoS datagrams can just include the 
>magic no. So we might as well let the inner protocol throw away 
>junk, and just leave GUT completely transparent.
>
>==3. Same source port?==
>"  The source port MAY be chosen freely, although
>    if the encapsulated protocol had a notion of port numners, the sender
>    MAY choose the same source port."
>
>What reason would there ever be for not using the same port?
>
>I think this ought to be a SHOULD. If the two are reliably always 
>the same, it gives information when they are not (e.g. a NAT has intervened).
>
>==4. Missing sender & receiver operations?==
>
>Need to say that the GUT daemon both on sending & receiving do 
>checksum creation & verification respectively, as normal for UDP. 
>You say (S.3.2) that the receiving GUT daemon recomputes the 
>checksum when it rebuilds a new IP packet, but you must also say it 
>verifies the original checksum before it does this (otherwise GUT 
>will hide bit errors by always recomputing a correct checksum!).
>
>Need to say whether the GUT daemon is considered as an IP hop 
>(requiring the IP TTL/hop-limit to be decremented).
>
>BTW, all the stuff about ECN in deployment considerations could just 
>be said simply as all IP headers are preserved when the UDP & GUT 
>shims are inserted or removed (which preserves all ECN functions).
>
>==5. Stateless GUT daemon?==
>
>A stateful GUT daemon is to be avoided if at all possible. Otherwise 
>a programmer has to timeout state, and it becomes vulnerable to 
>additional DOS attacks, so you start needing GUT cookies, etc.
>
>Also, if you have a GUT daemon on a middlebox (as mentioned in 
>deployment considerations), you want to avoid GUT state, otherwise 
>it breaks for:
>- asymmetric routes
>- route changes
>I.e GUT state breaks the 'shared fate' design principle.
>
>The receiving GUT daemon doesn't need to store the following items 
>of state, that S.3.2 of the draft says it should:
>- source IP
>- protocol number
>- source port (if it's the same as the inner transport source port)
>
>Rationale:
>    ===Source IP===
>    The source IP still in the IP packet that a receiving GUT daemon 
> re-presents to the IP layer of the stack. So the inner protocol 
> (e.g. SCTP, DCCP) can store the source IP if it needs to, then it 
> will turn it round back to the sending GUT as normal. So a sending 
> GUT can always be told the IP address to use by the process sending 
> to it, which will effectively send GUT an IP packet, to have the 
> UDP & GUT shims inserted.
>
>    ===Protocol number===
>    As with the source IP argument above, a GUT daemon can be told 
> what protocol number to use whenever it is given a packet to 'shim'.
>
>    ===Source port===
>    If a GUT daemon notices the source port is the same as the inner 
> transport protocol, it doesn't need to store any state. Then when 
> the GUT daemon gets a packet to 'shim' before sending, if it 
> doesn't hold any state, it uses the same source port as the 
> protocol it encapsulates.
>
>This just leaves a need for state when the inner & outer source 
>ports are different. This still leaves a DoS vulnerability, because 
>an attacker can make the inner & outer source ports different. So we 
>still need to think harder whether we can avoid the need for this 
>state... Effectively, the reason we are having to do this is because 
>NAT-PTs create state for their port mapping, so the GUT daemon has 
>to hold the same port mapping in reverse to negate it.
>
>Whatever, once you require state, the draft needs to discuss managing it:
>- timeouts
>- what to do if a packet needs to be sent but the necessary state 
>isn't there, yada yada.
>
>[If you change what you've said based on the above, you will also 
>need to change the comment about line 10 of Fig 3.]
>
>==6. Firewall above or below?==
>
>I suspect firewalls will want to look at incoming packets before the 
>GUT daemon on incoming and after it on outgoing. There's no need to 
>say firewalls have to sit higher in the stack than GUT. Putting 
>firewalls above GUT would certainly be a way to ensure GUT isn't 
>used to bypass firewalls that don't know about it. But once they do, 
>they will want to be below it.
>
>==7. Missing main incremental deployment consideration===
>
>A little story:
>
>Sender sends a DCCP packet, but gets no reply. Why?
>
>It may have been black-holed by a NAT because it doesn't recognise 
>DCCP. Or perhaps because it used ECN as well? Or perhaps the packet 
>got through but the response was black-holed for another reason? Or 
>perhaps either the outgoing or the response was just dropped due to 
>congestion? Or due to security policy for some different reason?
>
>Assume the code takes the most likely cases at this current time 
>(somehow the code understands its place in the history of the 
>Internet): it first assumes congestion and retries. Still no reply. 
>So it starts to suspect DCCP was the problem. So after backoff 
>timers expire it resends DCCP encapsulated in GUT.
>
>Still no reply. What's the most likely cause?: Maybe the receiver 
>doesn't yet support GUT. What next? Ug.
>
>My point is, the draft says nothing about:
>- incentives to be the first to deploy GUT when no-one else has
>- whether it matters that the sender cannot determine if the rcvr supports GUT
>
>A non-GUT receiver might send an ICMP Destination Unreachable (code 
>3: Port unreachable) error, but with so much port-scanning, these 
>days what's the chance of a port unreachable being sent, let alone 
>getting back to the source through a minefield of ICMP filters?
>
>
>Nits
>====
>* S.2. Intro
>"IP-in-IP encapsulation is also one potential solution. [...] if 
>NATs and firewalls probe deeper...
>they will encounter potentially an unknown transport protocol and 
>drop the packet"
>
>GUT is no different (but it doesn't matter if you are only trying to 
>meet goal (a) above and not trying to bypass firewalls).
>* S.2. Intro
>"...
>and original protocol type
>"
>The meaning of the word 'original' isn't obvious on first pass.
>* S.2. Intro
>s/meant to be/intended to be/
>s/informations/information/
>
>* S.3.1 Sender operation
>s/numners/numbers/
>
>* S.3.2. Receiver operation
>s/player/layer/
>s/flow source/connection originator/
>
>"...will receive upstream packets...": not clear what 'upstream' means here.
>
>* S.4. Deployment Considerations
>s/protocol Y's/protocol's/
>
>* S.6. Security Considerations
>
>"...when there are no listening sockets open that require GUT."
>Surely any listening socket may require GUT?

* S.6. Security Considerations
"  i.e., if a packet it received through GUT, after GUT processing, the
    packet MUST be forward through..."
This sentence seems garbled.

* S.6. Security Considerations
Probably worth mentioning how IPsec transport mode will work with 
GUT, both encap & decap. My quick thought is that the verification of 
the signature will be done on receiving the packet before the GUT 
daemon, so it should all 'just work'. Clearly IPsec will have to 
already have been got out of the way before the GUT daemon at the 
receiver creates a second IP packet to reinsert into the IP stack.

* S.6. Security Considerations
s/GUT enables hosts to payloads through firewalls that would 
otherwise we dropped./GUT enables hosts to pass payloads through 
firewalls that would otherwise be dropped./

Bob

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design